小程序的性能優化

微盟小程序性能優化要分享的內容分爲三部分，啓動性能加載、首屏加載的體驗建議和渲染性能優化。

 

先講啓動性能加載的性能優化實踐，先看啓動加載過程的流程：

 

 

· 公共庫注入

· 資源準備（基礎UI建立，代碼包下載）

· 業務代碼注入和渲染

· 渲染首屏

· 異步請求

 

 

優化方案

 

一、控制代碼包大小

 

· 開啓開發者工具中的 「 上傳代碼時自動壓縮 」

· 及時清理無用代碼和資源文件

· 減小代碼包中的圖片等資源文件的大小和數量

· 將圖片等資源文件放到CND中

· 提取公共樣式

· 代碼壓縮，圖片格式，壓縮，或者外聯

· 公共組件提取，代碼複用

 

二、 分包加載

 

分包加載過程流程

 

 

在開發小程序分包項目時，會有一個或者多個分包，其中沒有分包小程序必須包含一個主包，即放置啓動頁面或者tabBar頁面，以及一些分包都須要用到的公共資源腳本。

 

在小程序啓動時，默認會下載主包而且啓動主包內頁面，若是用戶打開分包內的頁面，客戶端會把分包下載下來，下載完以後再進行展現。

 

· 分包加載流程

 

使用分包加載的優勢：

 

· 可以增長小程序更大的代碼體積，開發更多的功能

· 對於用戶，能夠更快地打開小程序，同時不影響啓動速度

 

使用分包加載有哪些限制：

 

· 整個小程序全部分包不能超過8M

· 單個主包/分包不能超過2M

 

三、 運行機制優化

 

· 代碼中減小當即執行的代碼數量

· 避免高開銷和長時間阻塞代碼

· 業務代碼都寫入頁面的生命週期中

· 作好緩存策略

 

四、 數據管理優化

 

 

· 首屏請求數量儘可能不能超過5個，超過的能夠作接口合併（node層，服務端均可以處理）

· 對屢次提交的數據能夠作合併處理

 

接下來和你們聊一聊首屏加載的體驗建議和渲染性能優化。

 

2、首屏加載的體驗建議

 

· 提早請求  

  異步數據請求不須要等待頁面渲染完成。

 

· 利用緩存

  利用storage API對異步請求數據進行緩存，二次渲染頁面，再進行後臺更新。

 

· 避免白屏

  先展現頁面骨架和基礎內容。

 

3、渲染性能優化

 

·  每次 setData 的調用都是一次進程間通訊過程，通訊開銷與 setData 的數據量正相關

·  setData 會引起視圖層頁面內容的更新，這一耗時操做必定時間中會阻塞用戶交互

·  setData 是小程序開發使用最頻繁，也是最容易引起性能問題的

·  在頁面列表中使用懶加載+動態移除非可視區域範圍內的內容，讓dom小下去

·  耗時比較長的js作到異步，不要阻塞進程（js屬於單線程）

·  少使用scroll-view,這個組件對性能的影響太大，單純的只是須要一塊區域滾動，可使用view+css的方式實現

·  在頁面頻繁滾動觸發回調函數，會致使頁面卡頓，這時必須和防抖動函數或者節流函數相結合作一些處理

·  頁面中的圖片可使用懶加載的方式（添加lazy-load屬性，只針對page與scroll-view下的image有效）

·  頁面跳轉要作一下限制，若是頁面快速點擊會出現跳轉屢次的狀況

 

 避免不正當的使用setData

 

· 使用data在方法間共享數據，可能增長setData傳輸的數據量。data 應該僅僅包含與頁面渲染相關的數據

· 使用setData 傳輸大量的數據，通信耗時與數據量成正比，致使頁面更新延遲 可能形成頁面更新開銷增長。因此setData 僅傳輸頁面須要的數據,使用setData 的特殊Key 實現局部更新

· 短期內頻繁調用setData  (操做卡頓、交互延遲   阻塞通訊、頁面渲染延遲)，對連續的setData 調用進行合併

· 後臺進行頁面setData  (搶佔前臺頁面的渲染資源) 例如 活動定時器 再頁面切入後臺時應該將關閉

 

避免不正當的使用onPageScroll

 

· 只在必要的時候監聽pageScroll 事件

· 避免在onPageScroll 中執行復雜的邏輯

· 避免在onPageScroll 中頻繁調用setData

· 避免頻繁查詢節點信息(SelectQuery) 部分場景建議使用節點佈局相交狀態

·  監聽( IntersectionObserver) 替代

 

使用自定義組件

在須要頻繁更新的場景下，自定義組件的更新只在組件內部進行，不受頁面部份內容的複雜性的影響。