文章結構

文章基本思路：“目的 => 方案 => 驗證 => 總結啟發”

一，圖片懶載入實現
二，預期效果
三，A/BTest驗證
四，總結

一，圖片懶載入實現

方案選擇

圖片懶載入的本質是將某一圖片的載入推遲到使用者看到或即將看到該圖片的時候。實現圖片懶載入目前有三種方案：

補充：
①除了方案一，方案二三都同時支援小程式和H5，這裡僅以小程式為例。
②如有別的方案歡迎分享補充^_

基於上面的方案分析和當前使用者系統佔用率分佈（IntersectionObserver API支援率大於80%），我決定採用

方案實現

參考效能更優越的小程式圖片懶載入方式，感謝分享！注意：原文章方案存在Android快速滾動到底部沒有觸發載入 的問題。

從前面的視訊我們可以看到，優化的物件是商品詳情圖片列表，考慮到複用性，我把圖片列表封裝成lazyload-list元件，原始碼如下：

/**
 * lazyload-list
 * imgs: 圖片連結陣列，
 * lazyload: 是否開啟lazyload功能，預設開啟
 * <lazyload-list imgs="{{intros}}"></lazyload-list>
 */
 

Component({
  properties: {
	  imgs: {
		type: Array,
		value: [],
	  },
	  lazyload: {
		type: Boolean,
		value: true,
	  }
  },
  data: {
	lazyImgs: [],
	classNote: 'lazy-img-'
  },
  ready: function() {
	  // 介面相容性判斷，不支援新特性則回退到即時載入的方案
	  if (!this.createIntersectionObserver) {
		  // @TODO 可以改用基於滾動檢測 & 高度判斷的實現方案
		  this.setData({ lazyload: false });
	  } else {
		  var lazyImgs = [];
		  this.data.imgs.forEach(function(img) {
			  lazyImgs.push({
				  url: img,
				  loaded: false
			  })
		  });
		  this.setData({ lazyImgs: lazyImgs });
		  this.lazyloadImg();
	  }
  },
  methods: {
	  // 說明：原方案用同一個observer監聽第一張圖片載入，然後再監聽下一張圖片載入，
	  // 但在安卓系統下極快速滑動會出現第二張圖片沒有觸發載入就跳到後面的圖片的情況，導致後面的圖片都載入不出來。
	  // 因此為了穩妥起見，給每一張圖片設定單獨的observer。
	  lazyloadImg: function () {
		  var that = this;
		  this.data.lazyImgs.forEach(function(img, i) {
			  var intersectionObserver = that.createIntersectionObserver();
			  var observeSelector = '.' + that.data.classNote + i; // css選擇器
			  // bottom:300 指距離底部以下300px即會觸發事件
			  intersectionObserver.relativeToViewport({bottom: 300}).observe(observeSelector, function(res) {
				  intersectionObserver.disconnect();
				  img.loaded = true;
				  that.setData({
					  ['lazyImgs['+ i +']']: img
				  })
			  })
		  });
	  }
  }
})

<view>
	<view wx:for="{{lazyImgs}}" wx:key="{{item}}" class="{{classNote + index}}">
		<image class="img" mode="widthFix" src="{{lazyload && !item.loaded ? '' : item.url}}"/>
	</view>
</view>

.img {
	width: 100%;
	display: block;
}

實現過程：

1. 根據傳入的圖片連結陣列渲染image標籤：
   1. 設定src為空；
   2. 設定唯一的class（用於查詢到唯一的標籤，新增監聽）；
2. 在DOM渲染完成後（ready事件），新增IntersectionObserver監聽：
   1. 介面相容性判斷，向後相容；
   2. 根據上面設定的唯一class找到DOM節點，給所有圖片DOM節點新增IntersectionObserver監聽；
3. 使用者滾動（或者一進到頁面就看到了圖片）觸發新增IntersectionObserver回撥，載入圖片
   1. 設定當前圖片連結，載入圖片；
   2. 刪除當前節點監聽；

補充-體驗相關：圖片應設定預設寬高（小程式本身有設定），圖片載入前後高度變化儘可能小一些，對頁面結構影響相對小，給使用者觀感會好很多。

二，預期效果

圖片懶載入主要節省了使用者沒看到的圖片的載入流量，節省流量在邏輯上是可以預期的。

但不同業務，不同場景使用者的瀏覽情況不一樣，例如當用戶想買這個商品時，一般會認真瀏覽所有的商品圖片，這個時候是會載入完所有的圖片的，當然使用者也沒有浪費流量。而當用戶只是從列表頁點進來看看簡單的介紹時，使用者往往不會看商品詳情圖片，或者說不會看完所有的，那這部分沒有顯示圖片的流量就能被節省下來。

邏輯推匯出來的效果沒有問題，符合預期。下面我們來看看在線上產品中的效果如何：到底能為使用者節省多少流量？

三，A/BTest驗證

對比驗證

核心在於控制變數法。

為了知道使用圖片懶載入列表元件**“到底能為使用者節省多少流量”，我們需要對比優化策略上線前後平均每個使用者在商品詳情頁花費的流量多少**。

簡化到方便統計：

1. 平均每個使用者在商品詳情頁花費的流量
   ↓
2. 平均每個使用者在商品詳情頁瀏覽的圖片數量（假設每張圖片的大小一致，實際上是30k~150k/張）
   ↓
3. 平均每個使用者在商品詳情頁載入的圖片比例（抹平不同商品詳情頁圖片數量不一樣的差異）
   ↓
4. 結論推導：如果圖片載入比例在應用了優化策略後下降很多，說明圖片懶載入優化能節省使用者大量流量，如果下降不多，證明該業務該場景下實際優化意義不大。

傳統方法

先統計原來一週內“平均每個使用者在商品詳情頁載入的圖片比例”，再統計圖片載入優化策略上線後接下來一週內載入比例，進行對比，共耗時兩週。（取完整一週作為統計週期是為了排除時間因素帶來的影響）

實際統計過程如下：

1. 給所有image標籤繫結bindload事件，圖片載入完成後計數 + 1；
2. 離開頁面前（onUnload，onHide / 或別的觸發頁面跳走的事件），計算載入比例 = 圖片載入數量 / 圖片總數；
3. 上報該比例；
4. 後臺統計：平均圖片載入比例 = 所有上報載入比例之和 / 上報次數

高效的A/BTest

A/BTest相信大家都理解，A/BTest的核心優勢在於能在線上並行測試多個方案。例如上面為了獲取前後兩個圖片載入比率，我們需要耗時兩週，而如果採用A/BTest，隨機將使用者分成兩半，一半執行原有的圖片載入策略，一半執行優化後的圖片載入策略，我們只需要耗費一週就能得到我們想要的結果。

兩週 => 一週 是A/BTest給我們帶來最直觀的收益，畢竟時間先機對於網際網路公司的重要性不用再多說，而A/BTest因其並行性帶來測試環境更加相似的特點則能減少別的無關因素影響（例如這一週沒有搞活動，下一週確搞了運營活動，統計資料可能會產生誤差），A/BTest更多相關內容請參考資料分析領域的沉澱，我就不班門弄斧了。

** 真的需要A/BTest嗎？**看到這裡說不定有同學已經發現，上面這個優化對比，根本不需要測兩個圖片載入比例，因為優化前的圖片載入比例就是100%（全載入），因此根本用不上A/BTest，光測優化後的圖片載入比例就行。說得很對！這個優化比較簡單，理論上也能直觀推匯出結果。但如果是要在這個圖片方案上做調整，例如對比上面提到的方案二，我們就不能直觀推匯出結果了，此時A/BTest將能發揮重要作用！

統計過程和上面傳統方法的類似，就不贅述了，區別僅在於上報的時候加上引數來區分兩種圖片載入方案，下面重點說說：

簡單的A/BTest實現 - 隨機選取使用者開啟圖片載入優化：

1. 頁面載入時，Math.random() > 0.5將使用者隨機分成兩半；
2. 將該使用者型別記錄進cookie裡，避免下次進來再次被分組；
3. 一般使用者開啟lazyload；
4. 統計上報；

/**
 * lazyload-list
 * imgs: 圖片連結陣列，
 * lazyload: 是否開啟lazyload功能，預設開啟
 * preloadCount: 預載入圖片數量
 * <lazyload-list imgs="{{intros}}"></lazyload-list>
 */
Component({
  properties: {
	  imgs: {
		type: Array,
		value: [],
	  },
	  lazyload: {
		type: Boolean,
		value: true,
	  },
	  preloadCount: {
		  type: Number,
		  value: 1
	  }
  },
  data: {
	lazyImgs: [],
	classNote: 'lazy-img-',
	loadedCount: 0 // 圖片載入數量統計
  },
  ready: function() {
	  // A/BTest: 隨機選取使用者
	  var key = 'lazyloadUserType';
	  var userType = wx.getStorageSync(key);
	  if (!userType) {
		  // 設定使用者型別
		  var lazyloadOn = Math.random() > 0.5;
		  userType =  lazyloadOn ? 'lazy' : 'normal';
		  wx.setStorageSync(key, userType);
	  }
	  // 根據使用者型別啟用不同載入策略
	  if (userType === 'lazy') {
		  // 介面相容性判斷，不支援新特性則回退到即時載入的方案
		  if (!this.createIntersectionObserver) {
			  // @TODO 可以改用基於滾動檢測 & 高度判斷的實現方案
			  this.setData({ lazyload: false });
		  } else {
			  var lazyImgs = [];
			  this.data.imgs.forEach(function(img) {
				  lazyImgs.push({
					  url: img,
					  loaded: false
				  })
			  });
			  this.setData({ lazyImgs: lazyImgs });
			  this.lazyloadImg();
		  }
	  } else {
		  this.setData({ lazyload: false });
	  }
  },
  detached: function() {
	  // 圖片載入比例計算
	  var loadRate = (this.data.loadedCount/this.data.imgs.length).toFixed(4);
	  // console.log(loadRate);
	  // 資料上報
  },
  methods: {
	  // 說明：原方案用同一個observer監聽第一張圖片載入，然後再監聽下一張圖片載入，
	  // 但在安卓系統下極快速滑動會出現第二張圖片沒有觸發載入就跳到後面的圖片的情況，導致後面的圖片都載入不出來。
	  // 因此為了穩妥起見，給每一張圖片設定單獨的observer。
	  lazyloadImg: function () {
		  var that = this;
		  this.data.lazyImgs.forEach(function(img, i) {
			  var intersectionObserver = that.createIntersectionObserver();
			  var observeSelector = '.' + that.data.classNote + i; // css選擇器
			  // bottom:300 指距離底部以下300px即會觸發事件
			  intersectionObserver.relativeToViewport({bottom: 300}).observe(observeSelector, function(res) {
				  intersectionObserver.disconnect();
				  img.loaded = true;
				  that.setData({
					  ['lazyImgs['+ i +']']: img
				  })
			  })
		  });
	  },
	  onImgLoad: function (e) {
		  // 圖片載入數量統計
		  this.data.loadedCount += 1;
	  }
  }
})

四，總結啟發

經過一週的統計分析，使用圖片懶載入列表元件後，圖片載入比例：

// 2018-11-09~11-11線上資料

100% => 58% ↓42%

以上僅是特定專案特定頁面的統計資料，僅供大家參考。

總結

從結果資料可以看到圖片懶載入是web流量優化的基礎，尤其是在長圖片列表有明顯的差異。應該將列表圖片懶載入優化看做雪碧圖壓縮這種基礎優化，有助於提升web應用的整體表現。

優化雖不復雜，但“確定目標，方案分析選擇，預期推導，A/BTest驗證，決策”這個方法能穩妥地解決問題。

啟發

也叫TodoList，或者社群說法，挖坑。
需求繁忙，期待學有餘力的朋友們共同探索。

1. 採用方案二覆蓋低版本機型 - 開源社群以及有很多版本；
2. 封裝純js邏輯，方便swiper等元件實現圖片懶載入；
3. 學習現成的A/BTest系統：技術賦能產品做決策；