2020-03-03 09:20:13
優化要點
首屏時間：指使用者開啟頁面到看到第一屏主要內容的時間 渲染時間：指資料首次渲染或引起頁面結構變化的渲染所花費的時間 請求耗時：請求耗時越長，使用者等待的時間越長 CPU 利用率：CPU 利用率達到飽和時容易導致頁面白屏或閃退 網路請求數：短時間發起太多請求會觸發小程式並行請求的數量限制
分析工具
1、Performance monitor 它是小程式開發工具內建的一個視覺化監控工具，能夠在 OS 級別上實時記錄系統資源的使用情況。
藉助這個工具，可以監控 cpu 和記憶體佔用量和波動情況，快速定位引起頁面卡頓、機器發燙的模組，進而進行優化
2、測試機
小程式效能分析工具較少，且開發工具的執行效果和真機差異較大，應儘量使用真機定位效能問題。
通常，他們使用 oppo r11 和 iphone 6s plus 等低檔機排查效能問題，再分別挑選使用者數佔比較大的低、中、高檔機器檢驗優化效果
- 監控系統
前端進行測速資料採集和上報，再通過監控系統分析頁面的各項指標健康度，瞭解頁面載入耗時情況，對效能優化有較大的參考價值。
實踐 - 效能優化歷程
一、自動分頁渲染
背景： 早期，為縮短白屏時間，購物車使用了分屏渲染技術，把資料分為首屏和非首屏兩部分，首屏渲染完成後再渲染非首屏資料。
分屏渲染最大問題在於，一旦非首屏資料量過大，渲染耗時會很長，讓使用者等待很長時間，最糟的情況可能引起頁面假死，嚴重影響使用者體驗。
隨著業務增長，這個問題帶來的影響已經越來越明顯，因此我們開始考慮改用分頁技術
1、技術選型
難點：
業務複雜。短期內無法實現分頁請求資料，只能實現純前端分頁 資料量大。每個商品不僅包含主品的各項資訊，還可能附加與商品結構類似的贈品、換購商品等 商品列表順序動態改變。例如修改商品促銷，該商品可能由列表第一項變成最後一項，操作完成後還要定位到該商品
觸底載入： 優點：每次只載入一頁，需要時才載入下一頁 缺點：不適合資料結構複雜的場景；不適合列表項順序經常改變的場景。
分屏渲染： 優點：通過首屏渲染資料量的減少，提高首屏渲染的速度，首屏渲染完後緊接著渲染非首屏資料 缺點：當非首屏資料特別大的時候，可能會造成頁面的假死
自動分頁載入：通過raf實現自動分頁載入
2、基本思想
- 一次性請求全部資料
- 將資料分成若干頁，每次只渲染一頁
- 上一頁渲染完成後，自動迴圈渲染下一頁
3、迴圈渲染實現方案對比
- 通過 setData 遞迴。setData 的回撥函式觸發時立刻渲染下一頁。缺點是會導致 UI 執行緒一直忙碌，使用者操作響應變慢。
- 利用 setTimeout。setData 回撥函式觸發時，用 setTimeout 延遲一段時間再渲染下一頁。缺點是執行時間不可控。
- 利用時間分片。通過 requestAnimationFrame（簡稱 raf）實現。呼叫 raf 之後，瀏覽器在準備渲染下一幀前會呼叫你傳給 raf 的回撥函式。按照幀率為 60fps 來計算，每一幀的間隔在 16.6ms 左右。
4、示例
Demo: developers.weixin.qq.com/s/XJEDb3mP7…
原理: 用 raf 代替定時器，每次 setData 完成後，延遲 16.6ms 左右，再渲染下一頁
實現思路：每次 setData 時觸發 wxs 事件監聽器，在 wxs 事件處理函式中呼叫 raf，raf 回撥執行時呼叫邏輯層函式渲染下一頁 實現後左右聯動的滾動怎麼處理？ raf流程圖 第一步：AppService - setData觸發WxsPropObserve 第二步：webView - 觸發wxs函式進行初始化 第三步：webView - 執行wsx事件處理函式，呼叫requestAnimationFrame 第四步：webView - requestAnimationFrame回撥執行 第五步：AppService - setData下一頁資料