小程式redux效能優化，提升三倍渲染速度

蟹老闆愛寫程式碼發表於2018-08-06
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)
  }
}
複製程式碼

指標測試

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

測試平臺：iphone7、三星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。

相關文章