前言

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

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

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

工作原理 （官方說明）

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

性能關鍵點（官方說明）

1. 頻繁的去 setData 
   在我們分析過的一些案例里，部分小程序會非常頻繁（毫秒級）的去setData，其導致了兩個后果：

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

1. 每次 setData 都傳遞大量新數據 
   由setData的底層實現可知，我們的數據傳輸實際是一次 evaluateJavascript 腳本過程，當數據量過大時會增加腳本的編譯執行時間，占用 WebView JS 線程，
2. 后臺態頁面進行 setData 
   當頁面進入后臺態（用戶不可見），不應該繼續去進行setData，后臺態頁面的渲染用戶是無法感受的，另外后臺態頁面去setData也會搶占前臺頁面的執行。

度量性能指標

我們在優化性能時，指標是非常重要的，沒有指標，你沒法知道優化的點是否有效。不能單憑感覺去優化，要根據指標反饋，明確優化的成果。同時，優化就像個無底洞，要注意投入產出比。 
用戶反饋的卡頓，要么就是js執行消耗資源過多導致處理器沒響應，要么是UI渲染消耗資源過多，導致UI沒法響應用戶操作。 
通過查看代碼，我們并沒有消耗大量計算資源的業務邏輯，但是出現了UI反復操作和搶占資源的現象。

如何度量

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

1. let startTime = Date.now()
2. this.setData(data, () => {
3. let endTime = Data.now()
4. console.log(endTime - startTime, '渲染時長')
5. })

案例分析  1、檢查點：是否頻繁去setData  檢查結果：存在  產生原因：redux中監聽的是整個store，只要store變化，就會執行setData操作，這就意味著頁面無關的數據改變，也會觸發該頁面執行setData操作，但是這個操作是無意義的。  問題代碼：

1. // libs/redux-wechat/connect.js
2.  
3. // 對整個store進行subscribe。變化就執行handleChange
4. this.unsubscribe = this.store.subscribe(handleChange.bind(this, options));
5.  
6. function handleChange(options) {
7. ...省略代碼
8. const state = this.store.getState()
9. const mappedState = mapState(state, options);
10. this.setData(mappedState)
11. }

解決方案：

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

代碼實現：

1. // libs/redux-wechat/connect.js
2. // 如果更新的數據和頁面數據相同，不做操作。
3. function handleChange(options) {
4. ...省略代碼
5. const state = this.store.getState()
6. const mappedState = mapState(state, options);
7. // 如果更新的數據和頁面數據相同，不做操作。
8. if (mappedState === this.prevState) return // 新加入代碼
9. this.setData(mappedState)
10. // 保存上一次數據
11. this.prevState = mappedState // 新加入代碼
12. }

另外一個優化：如果store數據毫秒級變化怎么辦，例如更新購物車的同時，還更新了購物數量，能不能把兩次變化合并起來？因為store的數據是共享的，最后一次的更新就是最新的數據，可以采用節流器對請求進行合并。

1. clearTimeout(this.setDataTMO)
2. this.setDataTMO = setTimeout(() => {
3. this.setData(mappedState)
4. }, 50); // 時間可以看情況調整

2、檢查點：每次 setData 都傳遞大量新數據  檢查結果：存在  產生原因：

頁面存在引用沒用到的store數據。  后端返回數據直接進入store，后端接口返回冗余字段。

問題代碼：

1. /pages/user/index.js
2. connect(state => ({
3. member: state.member,
4. mycoupon: state.mycoupon,
5. guessLikeList: state.recommend.guessLikeList,
6. locationInfo: state.common && state.common.locationInfo, //可刪除
7. selectedseller: state.home.selectedseller,//可刪除
8. carts: state.carts.carts,//可刪除
9. ...state.common
10. }))

解決方案：

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

3、檢查點：后臺態頁面進行 setData  檢查結果：存在  產生原因：redux connect設計與小程序有差異  問題代碼：

1. // libs/redux-wechat/connect.js
2. function onLoad(options) {
3. ...省略部分代碼
4. if(shouldSubscribe){
5. this.unsubscribe = this.store.subscribe(handleChange.bind(this, options));
6. handleChange.call(this, options)
7. }
8. }
9. function onUnload() {
10. ...省略部分代碼
11. // 頁面onUnload時，才解除監聽
12. typeof this.unsubscribe === 'function' && this.unsubscribe()
13. }

小程序生命周期中，onUnload會在頁面銷毀時執行，例如A->B->C->D 的跳轉，A頁面一直在監聽store的變化，如果D頁面修改數據，會造成A,B,C頁面也執行setData操作，搶占了D的資源，因此造成卡頓。  解決方案：

后臺狀態的頁面在setData時直接return（目前采用該方法）  當頁面隱藏時，移除監聽。

代碼實現：

1. // 因為在后臺的頁面setData會搶占前臺資源，所以在后臺的頁面不要執行setData操作
2. if (this.route !== _getActivePage().route) return

但是由于在后臺的頁面數據沒法更新，如果D頁面修改A引用的數據，就會出現A引用舊數據問題，所以在onShow的時候做一次同步。

1. // 后臺的頁面切換到前臺的時候，做一次數據同步
2. function onShow(options) {
3. if(shouldSubscribe){
4. handleChange.call(this, options)
5. }
6. if (typeof _onShow === 'function') {
7. _onShow.call(this, options)
8. }
9. }

指標測試  做了這么多，到底有沒用，拿出來溜一溜就清楚了。  測試平臺：iphone7、三星s7 、小程序開發工具  測試流程：首頁 -> 配送到家 -> 加入購物車 -> 結算 ->查看訂單  測試指標：調用setData次數，渲染總耗時，平均單次渲染耗時

未優化指標：

優化后指標：

差異對比：

總結：

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