摘要：最近在開發(fā)一個長圖文預(yù)覽項目，主要用在手機端瀏覽主要在微信端。大概的實現(xiàn)是首屏開始顯示接下來首屏后面的圖片就全部扔給瀏覽器去加載了。

最近在開發(fā)一個長圖文預(yù)覽項目，主要用在手機端瀏覽（主要在微信端）。這項目其實就是一個手機網(wǎng)頁，把數(shù)據(jù)中的文本和圖片等元素渲染出來即可。這樣的項目很常見，包括微信內(nèi)公眾號的文章etc.這個項目很簡單，但非常頭疼的一個問題是對圖片的懶加載處理。（下面討論的加載策略暫且都是針對圖片）

前置條件：假定項目數(shù)據(jù)是一個數(shù)組，數(shù)組元素都是圖片，并且指定了圖片在屏幕中的left和top。

我們最開始想到的處理方式是：優(yōu)先考慮首屏體驗。
取得數(shù)據(jù)后，首屏先呈現(xiàn)Loading狀態(tài)。通過屏幕的高度H和圖片的top，得到首屏的圖片，并對其每一個圖片的onload和onerror事件綁定回調(diào)。當回調(diào)全都執(zhí)行完成之后便將首屏Loading狀態(tài)移除，呈現(xiàn)首屏的圖片。大概的實現(xiàn)是：

    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 => {
      // 首屏開始顯示
    })

接下來首屏后面的圖片就全部扔給瀏覽器去加載了。

上面首屏顯示優(yōu)化自然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） 繼續(xù)給下一塊代碼使用——------------
    loadNext()
    
    // 分屏按序加載
    function loadNext() {
      if (!indexs.length)
        return
    
      screenBox[indexs[0]].map(img=>{
        // 同首屏firstScreenPromises
    
      }).then(data=>{
        // load完后回調(diào)該函數(shù)繼續(xù)load下一屏
        indexs.shift()
        loadNext()
      })
    }

上面優(yōu)化點在于按序分屏加載圖片，這適合用戶慢慢往下看的情況，但是會有兩個弊端。
一是：如果用戶突然猛翻到頁面較后的位置，此時如果還在加載前面某屏的圖片，那用戶需要等待。
二是：如果頁面圖片元素非常多，屏幕數(shù)很多，會消耗許多流量，也許用戶不想看到最后咧。

于是考慮控制預(yù)加載的屏幕數(shù)，用戶看屏幕所時處的屏幕數(shù)為N，預(yù)加載N+1，N+2....N+M,最多預(yù)加載M屏。同時監(jiān)聽屏幕滾動，通過滾動的高度算出用戶所處的屏幕數(shù)。

    ....上邊代碼塊（X）.....
    loadNext(0) // 初始化load首屏
    window.onscroll = ()=>{
      getViewScreenIndex = function() {
        // 滾動監(jiān)聽求出用戶視野所處的屏幕數(shù)（若處在a,a+1，取a）
        return ...
      }
      loadNext(getViewScreenIndex())
    }
    // 加載第N屏，加載完繼續(xù)加載到第N+M屏
    function loadNext(N) {
      hasLoad = 0
      function load() {
        if (hasLoad == M) {
          // 已經(jīng)加載到N+M屏，停止預(yù)加載
          return
        }
    
        hasLoad++
    
        if (indexs.indexOf(N) > -1) {
          screenBox[indexs[0]].map(img=>{
            // 同首屏firstScreenPromises
    
          }).then(data=>{
            // load完后回調(diào)該函數(shù)繼續(xù)load下一屏
            indexs.splice(indexs.indexOf(N), 1)
            load()
          })
        } else {
          load()
        }    
      }
    }
        

最后一個優(yōu)化點：假設(shè)正在load第1屏（接下來會預(yù)加載第2，3屏），此時屏幕滾動到了第4屏（將會預(yù)加載第5，6屏）。此時是否還有必要繼續(xù)去加載第2，3屏？我覺得是沒必要的，用戶更有可能會繼續(xù)往后翻。所以此時我會取消掉2，3屏的預(yù)加載（當然，如果此時正在預(yù)加載第2屏，那只會取消掉第3屏的加載）。
這一塊的代碼，加上一些細節(jié)處理，可以到我的github lazyloader看看。

總結(jié)：目前能考慮到的上邊策略為的是提升用戶體驗（預(yù)加載），同時不會去消耗太多流量（限制預(yù)加載的數(shù)目）。但我相信還會有更加優(yōu)化的策略，希望能得到高人的指點，那就真的灰常感激啦！
同時，這里邊還會遇到一些兼容上的坑。比如：此處我所用到的滾動監(jiān)聽是window.onscroll。這個監(jiān)聽事件在不同設(shè)備上的表現(xiàn)非常不一樣，會使得這里的加載策略不一定能使所有的設(shè)備都體驗不錯。
android的（不確定是不是所有）window.onscroll會在手指按著屏幕拖動時觸發(fā)，以及屏幕滾動停止的時候觸發(fā)；而ios的則是只在屏幕停止?jié)L動的時候才會觸發(fā)。這兩者，在松開手后屏幕滾動時都不會觸發(fā)onscroll事件。
目前還沒想到比較好的兼容策略，希望有人能提供好的資料和想法借鑒借鑒，感激涕零。