微信小程序性能優化方案——讓你的小程序如此絲滑

微信小程序若是想要優化性能，有關鍵性的兩點：

1. 提升加載性能
2. 提升渲染性能

接下來分別來介紹一下：

提升加載性能

首先，問一個問題，當用戶點擊小程序後發生了什麼？

上圖中的三個狀態，咱們常常遇到，它們分別對應小程序的下面三個狀態：

有三個點的白屏（左側）： 下載代碼包的階段

沒有三個點的白屏（中間）： 業務代碼注入和渲染的階段

加載中（右邊）： 業務代碼中異步請求數據

總的來講，小程序呈現到用戶面前，實際上經歷了下面兩個階段：

1. 運行環境的加載
2. 下載代碼包

下面具體介紹這兩個階段：

運行環境預加載

這步是微信作的。微信會在用戶打開小程序以前就已經準備好環境，用戶點擊小程序入口後，直接下載小程序的代碼包便可。

下載代碼包啓動小程序

小程序代碼包裏面的代碼，不是小程序的源代碼，而是編譯、壓縮、打包以後的代碼包。

下圖中，左側的「預加載」對應的是運行環境的預加載，右側的「小程序啓動」 對應的是下載代碼包啓動小程序。

小程序提供的運行環境，分爲邏輯層（AppService）和 視圖層（webView），邏輯層是執行javascript的地方，視圖層是渲染頁面的地方。當小程序的代碼包下載完畢後，業務代碼分別注入邏輯層和渲染層。

提高加載性能的最最最關鍵性一點是，控制包的大小，這個也是微信官方的說法。

控制包的大小

提高體驗最直接的方法是控制小程序包的大小，基本上能夠說，1M的代碼包，下載耗時1秒左右。

控制包的大小的措施

• 壓縮代碼，清理無用的代碼
• 圖片放在cdn
• 採用分包策略
  • 分包預加載
  • 獨立分包（版本要求有點高）

除了上面講的控制包的大小，對異步請求的優化也很重要。

對異步請求的優化

• onLoad 階段就能夠發起請求，不用等ready
• 請求結果放在緩存中, 下次接着用
• 請求中能夠先展現骨架圖
• 先反饋，再請求。好比說，點讚的按鈕，能夠先改變按鈕的樣式，再 發起異步請求。

提高渲染性能

setData 幹了啥

每調用一次setData, 都是邏輯層向渲染層的一次通信，這個通訊還不是直接傳給webView, 而是經過走了native層，通信的開銷很大。

渲染層收到通信後，還須要從新渲染出來，因此，emmm, 一次setData帶來兩次開銷：通訊的開銷 + webview更新的開銷。

在數據傳輸時，邏輯層會執行一次JSON.stringify來去除掉setData數據中不可傳輸的部分，以後將數據發送給視圖層。同時，邏輯層還會將setData所設置的數據字段與data合併，使開發者能夠用this.data讀取到變動後的數據。

減小setData的數據量

若是一個數據不能會影響渲染層，則不用放在setData裏面

合併setData的請求，減小通信的次數

這個很好理解吧

列表的局部更新

在一個列表中，有n條數據，採用上拉加載更多的方式，假如這個時候想對其中某一個數據進行點贊操做，還能及時看到點讚的效果

此時，能夠採用setData全局刷新，點贊完成以後，從新獲取數據，再次進行全局從新渲染，這樣作的優勢是：方便，快捷！缺點是：用戶體驗極其很差，當用戶刷量100多條數據後，從新渲染量大會出現空白期（沒有渲染過來）

若是採用佈局刷新，將點讚的id傳過去，知道點的是那一條數據, 將點讚的id傳過去，知道點的是那一條數據。

從新獲取數據，查找相對應id的那條數據的下標（index是不會改變的），用setData進行局部刷新

this.setData({
    list[index] = newList[index]
})
複製代碼

當心後臺頁面的js

小程序中可能有n個頁面，全部的這些頁面，雖然都擁有本身的webview(渲染層)， 可是卻共享同一個js運行環境。也就是說，當你跳到了另一個頁面（假設是B頁面），本頁面（假設是A頁面）的定時器等js操做仍在進行，而且不會被銷燬，而且會搶佔B頁面的資源。

在h5的環境中，當咱們跳轉到其餘頁面，老頁面的js環境會被自動銷燬，定時器什麼都被銷燬掉了，所以咱們不須要關心老頁面中，還有哪些js代碼可能還會執行。可是在小程序中，咱們必須手動的「清理」掉這樣的代碼。

當心onPageScroll

pageScroll 事件，也是一次通信，是webview層向js邏輯層的通信。此次通信也是開銷較大，若是考慮到這個事件被頻繁的調用，回調函數若是有複雜的setData的話，emmmmm， 性能就會不好了。

當心獲取節點位置

在h5 中的環境中，爲了實現懶加載、下拉加載，咱們不得不去獲取節點的位置。

爲啥說不得不，是由於咱們本能夠用新的api ——intersectionObject去輕鬆實現（google等主流瀏覽器都已經支持了），可是微信的內置X5瀏覽器很遺憾的不支持。

沒想到，在小程序的環境中，微信居然良心發現，支持intersectionObject api, 所以獲取節點的信息，儘可能仍是用這api 吧。

儘量使用小程序組件

自定義組件的更新只在組件內部進行，不受頁面其餘不能份內容的影響；好比一些運營活動的定時模塊能夠單獨抽出來，作成一個定時組件，定時組件的更新並不會影響頁面上其餘元素的更新；各個組件也將具備各自獨立的邏輯空間。每一個組件都分別擁有本身的獨立的數據、setData調用

記錄優化後的數據，和優化前進行對比

若是咱們記錄下每個頁面的優化先後的首屏渲染數據，而且對比，能夠很好的分析每個頁面的性能提高有多少，從而判斷本身有沒有在作無用功。

能夠先簡單約定一下，首屏渲染時間的含義爲：從小程序頁面onload事件算起，頁面發起異步請求，請求回來後，把數據經過setData 渲染到頁面後，上述一整個流程所花費的時間。

可是，一個小程序項目每每會有不少個頁面，手動記錄每個小程序的首屏渲染時間，很麻煩。

咱們能夠改造this.setData 方法以下：

this._startTime = new Date().getTime();
let fn = this.setData;
this.setData = (obj = {}, handle = '') => {
	let now = new Date().getTime();
    // 上報渲染所須要的時間
	log(now - this._startTime)
	fn.apply(this, [obj, handle]);
};
複製代碼

上面的僞代碼改寫了 this.setData 方法，簡單的加入了上報時間點邏輯，你們能夠根據自身的需求進行改造

優化心得

相比於上面的優化策略，最重要的是找出小程序中的性能瓶頸。在本身的優化實踐中，遇到了下面的問題：

1. 下拉加載更多，特別特別卡，經過列表局部更新的技巧，發現性能改善不大。 後來發現，是由於首頁須要監聽scroll事件，致使scroll事件被頻繁的觸發，回調函數中有耗時操做，致使onreachBottom事件被阻塞了，也就是說，要等大概1~2秒纔會去發起下一頁的請求。 取消掉scroll事件的監聽，本來>4s的加載時間，控制在1s以內。

一些坑

1. 在微信開發者工具沒有辦法復現某些性能問題，是由於從邏輯層到webview的通信，開發者工具底層是經過onpostMessage, 微信ios好像是微信本身實現的橋接。因此強烈建議使用真機進行調試
2. 微信開發者工具，沒有辦法在【network】裏面看到圖片資源的加載，經過【trace】面板鏈接安卓真機也沒有辦法看到。若是想測試懶加載的效果，就比較麻煩，須要經過設置微信開發者工具的代理到127.0.0.1，經過charles能夠抓包看到（截止2018年11月1日是這樣的）

一些迷茫

搞微信小程序遇到的這些坑，雖然能夠收穫滿滿的填坑經驗，可是這些填坑經驗並不算是真正的計算機知識，由於這些知識的並非基於對本質底層的理解，而是依靠經驗，而經驗是很快就會過期，可能下一次小程序api來一次大的升級，小程序優化手段立刻就會換成另一種。