长图文加载优化

摘要：最近在开发一个长图文预览项目，主要用在手机端浏览主要在微信端。大概的实现是首屏开始显示接下来首屏后面的图片就全部扔给浏览器去加载了。

最近在开发一个长图文预览项目，主要用在手机端浏览（主要在微信端）。这项目其实就是一个手机网页，把数据中的文本和图片等元素渲染出来即可。这样的项目很常见，包括微信内公众号的文章etc.这个项目很简单，但非常头疼的一个问题是对图片的懒加载处理。（下面讨论的加载策略暂且都是针对图片）

前置条件：假定项目数据是一个数组，数组元素都是图片，并且指定了图片在屏幕中的left和top。

我们最开始想到的处理方式是：优先考虑首屏体验。
取得数据后，首屏先呈现Loading状态。通过屏幕的高度H和图片的top，得到首屏的图片，并对其每一个图片的onload和onerror事件绑定回调。当回调全都执行完成之后便将首屏Loading状态移除，呈现首屏的图片。大概的实现是：

    firstScreenPromises = firstScreenImgs.map((img) => {
      return new Promise((resolve, reject) => {
        let image = new Image()
        image.src = img.imgSrc
        image.onload = image.onerror = resolve
      })
    })
    Promise.all(firstScreenPromises).then(data => {
      // 首屏开始显示
    })

接下来首屏后面的图片就全部扔给浏览器去加载了。

上面首屏显示优化自然ok，不过对后面屏幕图片的显示策略自然是不太好的。于是考虑分屏加载，一屏一屏加载图片。

    // 分屏
    screenBox = {}
    H = screen.height
    
    for (let i = 0; i < imgs.length; i += 1) {
      screenNum = Math.floor(imgs.top / H)
      screenBox[screenNum] = screenBox[screenNum] || []
      screenBox[screenNum].push(imgs[i])
    }
    
    indexs = Object.keys(screenBox)
    ----------上边代码块 （X） 继续给下一块代码使用——------------
    loadNext()
    
    // 分屏按序加载
    function loadNext() {
      if (!indexs.length)
        return
    
      screenBox[indexs[0]].map(img=>{
        // 同首屏firstScreenPromises
    
      }).then(data=>{
        // load完后回调该函数继续load下一屏
        indexs.shift()
        loadNext()
      })
    }

上面优化点在于按序分屏加载图片，这适合用户慢慢往下看的情况，但是会有两个弊端。
一是：如果用户突然猛翻到页面较后的位置，此时如果还在加载前面某屏的图片，那用户需要等待。
二是：如果页面图片元素非常多，屏幕数很多，会消耗许多流量，也许用户不想看到最后咧。

于是考虑控制预加载的屏幕数，用户看屏幕所时处的屏幕数为N，预加载N+1，N+2....N+M,最多预加载M屏。同时监听屏幕滚动，通过滚动的高度算出用户所处的屏幕数。

    ....上边代码块（X）.....
    loadNext(0) // 初始化load首屏
    window.onscroll = ()=>{
      getViewScreenIndex = function() {
        // 滚动监听求出用户视野所处的屏幕数（若处在a,a+1，取a）
        return ...
      }
      loadNext(getViewScreenIndex())
    }
    // 加载第N屏，加载完继续加载到第N+M屏
    function loadNext(N) {
      hasLoad = 0
      function load() {
        if (hasLoad == M) {
          // 已经加载到N+M屏，停止预加载
          return
        }
    
        hasLoad++
    
        if (indexs.indexOf(N) > -1) {
          screenBox[indexs[0]].map(img=>{
            // 同首屏firstScreenPromises
    
          }).then(data=>{
            // load完后回调该函数继续load下一屏
            indexs.splice(indexs.indexOf(N), 1)
            load()
          })
        } else {
          load()
        }    
      }
    }
        

最后一个优化点：假设正在load第1屏（接下来会预加载第2，3屏），此时屏幕滚动到了第4屏（将会预加载第5，6屏）。此时是否还有必要继续去加载第2，3屏？我觉得是没必要的，用户更有可能会继续往后翻。所以此时我会取消掉2，3屏的预加载（当然，如果此时正在预加载第2屏，那只会取消掉第3屏的加载）。
这一块的代码，加上一些细节处理，可以到我的github lazyloader看看。

总结：目前能考虑到的上边策略为的是提升用户体验（预加载），同时不会去消耗太多流量（限制预加载的数目）。但我相信还会有更加优化的策略，希望能得到高人的指点，那就真的灰常感激啦！
同时，这里边还会遇到一些兼容上的坑。比如：此处我所用到的滚动监听是window.onscroll。这个监听事件在不同设备上的表现非常不一样，会使得这里的加载策略不一定能使所有的设备都体验不错。
android的（不确定是不是所有）window.onscroll会在手指按着屏幕拖动时触发，以及屏幕滚动停止的时候触发；而ios的则是只在屏幕停止滚动的时候才会触发。这两者，在松开手后屏幕滚动时都不会触发onscroll事件。
目前还没想到比较好的兼容策略，希望有人能提供好的资料和想法借鉴借鉴，感激涕零。