小程序redux性能優化，提高三倍渲染速度

前言

最近用戶反饋咱們的小程序很卡，打開商品列表須要四五秒時間，帶着這個疑問，我決定對小程序作個全面的性能優化，要作性能優化，必須先理清如下三個關鍵點。

1. 產生性能問題的關鍵點
2. 度量性能指標
3. 尋找解決方案

在閱讀案例分析前，建議能先了解小程序的工做原理和性能關鍵點。

工做原理 （官方說明）

小程序的視圖層目前使用 WebView 做爲渲染載體，而邏輯層是由獨立的 JavascriptCore 做爲運行環境。在架構上，WebView 和 JavascriptCore 都是獨立的模塊，並不具有數據直接共享的通道。當前，視圖層和邏輯層的數據傳輸，實際上經過兩邊提供的 evaluateJavascript 所實現。即用戶傳輸的數據，須要將其轉換爲字符串形式傳遞，同時把轉換後的數據內容拼接成一份 JS 腳本，再經過執行 JS 腳本的形式傳遞到兩邊獨立環境。

而 evaluateJavascript 的執行會受不少方面的影響，數據到達視圖層並非實時的。

性能關鍵點（官方說明）

1. 頻繁的去 setData

在咱們分析過的一些案例裏，部分小程序會很是頻繁（毫秒級）的去setData，其致使了兩個後果：

• Android 下用戶在滑動時會感受到卡頓，操做反饋延遲嚴重，由於 JS 線程一直在編譯執行渲染，未能及時將用戶操做事件傳遞到邏輯層，邏輯層亦沒法及時將操做處理結果及時傳遞到視圖層；
• 渲染有出現延時，因爲 WebView 的 JS 線程一直處於忙碌狀態，邏輯層到頁面層的通訊耗時上升，視圖層收到的數據消息時距離發出時間已通過去了幾百毫秒，渲染的結果並不實時；

2. 每次 setData 都傳遞大量新數據

由setData的底層實現可知，咱們的數據傳輸實際是一次 evaluateJavascript 腳本過程，當數據量過大時會增長腳本的編譯執行時間，佔用 WebView JS 線程，

3. 後臺態頁面進行 setData

當頁面進入後臺態（用戶不可見），不該該繼續去進行setData，後臺態頁面的渲染用戶是沒法感覺的，另外後臺態頁面去setData也會搶佔前臺頁面的執行。

度量性能指標

咱們在優化性能時，指標是很是重要的，沒有指標，你無法知道優化的點是否有效。不能單憑感受去優化，要根據指標反饋，明確優化的成果。同時，優化就像個無底洞，要注意投入產出比。

用戶反饋的卡頓，要麼就是js執行消耗資源過多致使處理器沒響應，要麼是UI渲染消耗資源過多，致使UI無法響應用戶操做。

經過查看代碼，咱們並無消耗大量計算資源的業務邏輯，可是出現了UI反覆操做和搶佔資源的現象。

如何度量

能夠利用setData的第二個參數，傳入callback函數，統計渲染時長。代碼以下

let startTime = Date.now()
this.setData(data, () => {
    let endTime = Data.now()
    console.log(endTime - startTime, '渲染時長')
})
複製代碼

案例分析

檢查點：是否頻繁去setData

檢查結果：存在

產生緣由：redux中監聽的是整個store，只要store變化，就會執行setData操做，這就意味着頁面無關的數據改變，也會觸發該頁面執行setData操做，可是這個操做是無心義的。

問題代碼：

// libs/redux-wechat/connect.js

// 對整個store進行subscribe。變化就執行handleChange
this.unsubscribe = this.store.subscribe(handleChange.bind(this, options));

function handleChange(options) {
    ...省略代碼
    const state = this.store.getState()
    const mappedState = mapState(state, options);
    this.setData(mappedState)
}

複製代碼

解決方案：

• 方法一：只監聽當前頁面用到的store中的部分數據，只有該部分數據變化，才setData。（store沒提供單個數據的監聽，若是本身修改redux實現，難度較大，同時修改太底層，容易出不可預料的異常。）
• 方法二：判斷頁面數據與須要更新數據是否相同，若是相同，不作操做。（這個方案成本比較低，就用它吧）

代碼實現：

// libs/redux-wechat/connect.js
// 若是更新的數據和頁面數據相同，不作操做。
function handleChange(options) {
    ...省略代碼
    const state = this.store.getState()
    const mappedState = mapState(state, options);
    // 若是更新的數據和頁面數據相同，不作操做。
    if (utils.deepEqual(mappedState, this.prevState)) return // 新加入代碼
    this.setData(mappedState)
    // 保存上一次數據
    this.prevState = mappedState // 新加入代碼
}
複製代碼

另一個優化：若是store數據毫秒級變化怎麼辦，例如更新購物車的同時，還更新了購物數量，能不能把兩次變化合並起來？由於store的數據是共享的，最後一次的更新就是最新的數據，能夠採用節流器對請求進行合併。

clearTimeout(this.setDataTMO)
      this.setDataTMO = setTimeout(() => {
        this.setData(mappedState)
  }, 50); // 時間能夠看狀況調整
複製代碼

檢查點：每次 setData 都傳遞大量新數據

檢查結果：存在

產生緣由：

1. 頁面存在引用沒用到的store數據。
2. 後端返回數據直接進入store，後端接口返回冗餘字段。

問題代碼：

/pages/user/index.js
connect(state => ({
    member: state.member,
    mycoupon: state.mycoupon,
    guessLikeList: state.recommend.guessLikeList,
    locationInfo: state.common && state.common.locationInfo, //可刪除
    selectedseller: state.home.selectedseller,//可刪除
    carts: state.carts.carts,//可刪除
    ...state.common
  }))
複製代碼

解決方案：

• 方法一：刪除頁面無用的connect （老業務在使用，修改存在風險，經過後續迭代優化）
• 方法二：請求後端接口後，拿到數據進行優化處理再把數據傳入store（成本較高）

檢查點：後臺態頁面進行 setData

檢查結果：存在

產生緣由：redux connect設計與小程序有差別

問題代碼：

// libs/redux-wechat/connect.js
    function onLoad(options) {
      ...省略部分代碼
      if(shouldSubscribe){
        this.unsubscribe = this.store.subscribe(handleChange.bind(this, options));
        handleChange.call(this, options)
      }
    }
    function onUnload() {
	  ...省略部分代碼
      // 頁面onUnload時，才解除監聽
      typeof this.unsubscribe === 'function' && this.unsubscribe()
    }
複製代碼

小程序生命週期中，onUnload會在頁面銷燬時執行，例如A->B->C->D 的跳轉，A頁面一直在監聽store的變化，若是D頁面修改數據，會形成A,B,C頁面也執行setData操做，搶佔了D的資源，所以形成卡頓。

解決方案：

• 方法一： 後臺狀態的頁面在setData時直接return（目前採用該方法）
• 方法二：當頁面隱藏時，移除監聽。

代碼實現：

// 由於在後臺的頁面setData會搶佔前臺資源，因此在後臺的頁面不要執行setData操做
if (this.route !== _getActivePage().route) return
複製代碼

可是因爲在後臺的頁面數據無法更新，若是D頁面修改A引用的數據，就會出現A引用舊數據問題，因此在onShow的時候作一次同步。

// 後臺的頁面切換到前臺的時候，作一次數據同步
function onShow(options) {
  if(shouldSubscribe){
    handleChange.call(this, options)
  }
  if (typeof _onShow === 'function') {
    _onShow.call(this, options)
  }
}
複製代碼

指標測試

作了這麼多，到底有沒用，拿出來溜一溜就清楚了。

測試平臺：iphone七、三星s7 、小程序開發工具

測試流程：首頁 -> 配送到家 -> 加入購物車 -> 結算 ->查看訂單

測試指標：調用setData次數，渲染總耗時，平均單次渲染耗時

未優化指標：

平臺	setData次數	渲染總耗時(ms)	平均單次渲染耗時(ms)
三星s7	204	250258	1226
iphone7	167	38260	229
小程序開發工具	193	36811	190

優化後指標：

平臺	setData次數	渲染總耗時(ms)	平均單次渲染耗時(ms)
三星s7	28	11227	400
iphone7	28	3971	141
小程序開發工具	31	2489	80

差別對比：

平臺	setData次數差	渲染總耗時差(ms)	平均單次渲染耗時差(ms)
三星s7	176	239031	826
iphone7	139	34289	88
小程序開發工具	162	34322	110

總結：

1. 優化後setData次數平均降低150次。
2. 渲染耗時越是卡頓的機器，收益越大，三星s7平均每次渲染耗時下降826ms。