微信小程式如果想要優化效能，有關鍵性的兩點：
- 提高載入效能
- 提高渲染效能
接下來分別來介紹一下：
提高載入效能
首先，問一個問題，當使用者點選小程式後發生了什麼？
上圖中的三個狀態，我們經常遇到，它們分別對應小程式的下面三個狀態：
有三個點的白屏（左側）： 下載程式碼包的階段
沒有三個點的白屏（中間）： 業務程式碼注入和渲染的階段
載入中（右邊）： 業務程式碼中非同步請求資料
總的來說，小程式呈現到使用者面前，實際上經歷了下面兩個階段：
- 執行環境的載入
- 下載程式碼包
下面具體介紹這兩個階段：
執行環境預載入
這步是微信做的。微信會在使用者開啟小程式之前就已經準備好環境，使用者點選小程式入口後，直接下載小程式的程式碼包即可。
下載程式碼包啟動小程式
小程式程式碼包裡面的程式碼，不是小程式的原始碼，而是編譯、壓縮、打包之後的程式碼包。
下圖中，左側的“預載入”對應的是執行環境的預載入，右側的“小程式啟動” 對應的是下載程式碼包啟動小程式。
小程式提供的執行環境，分為邏輯層（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呼叫
優化心得
相比於上面的優化策略，最重要的是找出小程式中的效能瓶頸。在自己的優化實踐中，遇到了下面的問題：
- 下拉載入更多，特別特別卡，通過列表區域性更新的技巧，發現效能改善不大。
後來發現，是因為首頁需要監聽scroll事件，導致scroll事件被頻繁的觸發，回撥函式中有耗時操作，導致onreachBottom事件被阻塞了，也就是說，要等大概1~2秒才會去發起下一頁的請求。
取消掉scroll事件的監聽，原本>4s的載入時間，控制在1s之內。
一些坑
- 在微信開發者工具沒有辦法復現某些效能問題，是因為從邏輯層到webview的通訊，開發者工具底層是通過onpostMessage, 微信ios好像是微信自己實現的橋接。所以強烈建議使用真機進行除錯
- 微信開發者工具，沒有辦法在【network】裡面看到圖片資源的載入，通過【trace】皮膚連線安卓真機也沒有辦法看到。如果想測試懶載入的效果，就比較麻煩，需要通過設定微信開發者工具的代理到127.0.0.1，通過charles可以抓包看到（截止2018年11月1日是這樣的）
一些迷茫
搞微信小程式遇到的這些坑，雖然可以收穫滿滿的填坑經驗，但是這些填坑經驗並不算是真正的計算機知識，因為這些知識的並不是基於對本質底層的理解，而是依靠經驗，而經驗是很快就會過時，可能下一次小程式api來一次大的升級，小程式優化手段馬上就會換成另外一種。