| ylbtech-小程序：性能 |
性能
目前，我們提供了兩種性能分析工具，和幾個性能優化上的建議，開發者可以參考使用。
| 1. 分析工具返回頂部 |
性能 Trace 工具
微信 Andoid 6.5.10 開始，我們提供了 Trace 導出工具，開發者可以在開發者工具 Trace Panel 中使用該功能。
使用方法
- PC 上需要先安裝
adb工具，可以參考一些主流教程進行安裝，Mac 上可使用 brew 直接安裝。 - 確定
adb工具已成功安裝后，在開發者工具上打開 Trace Panel，將 Android 手機通過 USB 連接上 PC，點擊「Choose Devices」，此時手機上可能彈出連接授權框，請點擊「允許」。 - 選擇設備后，在手機上打開你需要調試的開發版小程序，通過右上角菜單，打開性能監控面板，重啟小程序；
- 重啟后，在小程序上進行操作，完成操作后，通過右上角菜單，導出 Trace 數據；
- 此時開發者工具 Trace Panel 上會自動拉取 Trace 文件，選擇你要分析的 Trace 文件即可；
可以通過
adb devices命令確定設備是否已和 PC 建立起連接
性能面板
從微信 6.5.8 開始，我們提供了性能面板讓開發者了解小程序的性能。開發者可以在開發版小程序下打開性能面板，打開方法：進入開發版小程序，進入右上角更多按鈕，點擊「顯示性能窗口」。
性能面板指標說明
| 指標 | 說明 |
|---|---|
| CPU | 小程序進程的 CPU 占用率，僅 Android 下提供 |
| 內存 | 小程序進程的內存占用（Total Pss)，僅 Android 下提供 |
| 啟動耗時 | 小程序啟動總耗時 |
| 下載耗時 | 小程序包下載耗時，首次打開或資源包需更新時會進行下載 |
| 頁面切換耗時 | 小程序頁面切換的耗時 |
| 幀率/FPS | |
| 首次渲染耗時 | 頁面首次渲染的耗時 |
| 再次渲染耗時 | 頁面再次渲染的耗時（通常由開發者的 setData 操作觸發） |
| 數據緩存 | 小程序通過 Storage 接口儲存的緩存大小 |
| 2. 優化建議返回頂部 |
setData
setData 是小程序開發中使用最頻繁的接口，也是最容易引發性能問題的接口。在介紹常見的錯誤用法前，先簡單介紹一下 setData 背后的工作原理。
工作原理
小程序的視圖層目前使用 WebView 作為渲染載體，而邏輯層是由獨立的 JavascriptCore 作為運行環境。在架構上，WebView 和 JavascriptCore 都是獨立的模塊，並不具備數據直接共享的通道。當前，視圖層和邏輯層的數據傳輸，實際上通過兩邊提供的 evaluateJavascript 所實現。即用戶傳輸的數據，需要將其轉換為字符串形式傳遞，同時把轉換后的數據內容拼接成一份 JS 腳本，再通過執行 JS 腳本的形式傳遞到兩邊獨立環境。
而 evaluateJavascript 的執行會受很多方面的影響，數據到達視圖層並不是實時的。同一進程內的 WebView 實際上會共享一個 JS VM，如果 WebView 內 JS 線程正在執行渲染或其他邏輯，會影響 evaluateJavascript 腳本的實際執行時間，另外多個 WebView 也會搶占 JS VM 的執行權限；另外還有 JS 本身的編譯執行耗時，都是影響數據傳輸速度的因素。
常見的 setData 操作錯誤
1. 頻繁的去 setData
在我們分析過的一些案例里，部分小程序會非常頻繁（毫秒級）的去setData，其導致了兩個后果：
- Android 下用戶在滑動時會感覺到卡頓，操作反饋延遲嚴重，因為 JS 線程一直在編譯執行渲染，未能及時將用戶操作事件傳遞到邏輯層，邏輯層亦無法及時將操作處理結果及時傳遞到視圖層；
- 渲染有出現延時，由於 WebView 的 JS 線程一直處於忙碌狀態，邏輯層到頁面層的通信耗時上升，視圖層收到的數據消息時距離發出時間已經過去了幾百毫秒，渲染的結果並不實時；
2. 每次 setData 都傳遞大量新數據
由setData的底層實現可知，我們的數據傳輸實際是一次 evaluateJavascript 腳本過程，當數據量過大時會增加腳本的編譯執行時間，占用 WebView JS 線程，
3. 后台態頁面進行 setData
當頁面進入后台態（用戶不可見），不應該繼續去進行setData，后台態頁面的渲染用戶是無法感受的，另外后台態頁面去setData也會搶占前台頁面的執行。
圖片資源
目前圖片資源的主要性能問題在於大圖片和長列表圖片上，這兩種情況都有可能導致 iOS 客戶端內存占用上升，從而觸發系統回收小程序頁面。
圖片對內存的影響
在 iOS 上，小程序的頁面是由多個 WKWebView 組成的，在系統內存緊張時，會回收掉一部分 WKWebView。從過去我們分析的案例來看，大圖片和長列表圖片的使用會引起 WKWebView 的回收。
圖片對頁面切換的影響
除了內存問題外，大圖片也會造成頁面切換的卡頓。我們分析過的案例中，有一部分小程序會在頁面中引用大圖片，在頁面后退切換中會出現掉幀卡頓的情況。
當前我們建議開發者盡量減少使用大圖片資源。
代碼包大小的優化
小程序一開始時代碼包限制為 1MB，但我們收到了很多反饋說代碼包大小不夠用，經過評估后我們放開了這個限制，增加到 2MB 。代碼包上限的增加對於開發者來說，能夠實現更豐富的功能，但對於用戶來說，也增加了下載流量和本地空間的占用。
開發者在實現業務邏輯同時也有必要盡量減少代碼包的大小，因為代碼包大小直接影響到下載速度，從而影響用戶的首次打開體驗。除了代碼自身的重構優化外，還可以從這兩方面着手優化代碼大小：
控制代碼包內圖片資源
小程序代碼包經過編譯后，會放在微信的 CDN 上供用戶下載，CDN 開啟了 GZIP 壓縮，所以用戶下載的是壓縮后的 GZIP 包，其大小比代碼包原體積會更小。 但我們分析數據發現，不同小程序之間的代碼包壓縮比差異也挺大的，部分可以達到 30%，而部分只有 80%，而造成這部分差異的一個原因，就是圖片資源的使用。GZIP 對基於文本資源的壓縮效果最好，在壓縮較大文件時往往可高達 70%-80% 的壓縮率，而如果對已經壓縮的資源（例如大多數的圖片格式）則效果甚微。
及時清理沒有使用到的代碼和資源
在日常開發的時候，我們可能引入了一些新的庫文件，而過了一段時間后，由於各種原因又不再使用這個庫了，我們常常會只是去掉了代碼里的引用，而忘記刪掉這類庫文件了。目前小程序打包是會將工程下所有文件都打入代碼包內，也就是說，這些沒有被實際使用到的庫文件和資源也會被打入到代碼包里，從而影響到整體代碼包的大小。
| 3.返回頂部 |
| 4.返回頂部 |
| 5.返回頂部 |
| 6.返回頂部 |
 |
作者：ylbtech 出處：http://ylbtech.cnblogs.com/ 本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。 |