微信小程序如果想要優化性能，有關鍵性的兩點：提高加載性能和提高渲染性能。
一、提高加載性能
當用戶點擊小程序后發生了什么？
資源准備（代碼包下載） —— 業務代碼注入和渲染 —— 異步請求數據
上面的三個狀態，我們經常遇到，它們分別對應小程序的下面三個狀態：
- 有三個點的白屏階段： 下載代碼包的階段
- 沒有三個點的白屏： 業務代碼注入和渲染的階段
- 加載中： 業務代碼中異步請求數據
總的來說，小程序呈現到用戶面前，實際上經歷了下面兩個階段：運行環境的加載，下載代碼包啟動小程序。
運行環境預加載：這步是微信做的。微信會在用戶打開小程序之前就已經准備好環境，用戶點擊小程序入口后，直接下載小程序的代碼包即可。
下載代碼包啟動小程序，小程序代碼包里面的代碼，不是小程序的源代碼，而是編譯、壓縮、打包之后的代碼包。
小程序提供的運行環境，分為邏輯層（AppService）和 視圖層（webView），邏輯層是執行javascript的地方，視圖層是渲染頁面的地方。當小程序的代碼包下載完畢后，業務代碼分別注入邏輯層和渲染層。
提升加載性能的最最最關鍵性一點是，控制包的大小，這個也是微信官方的說法。
提升體驗最直接的方法是控制小程序包的大小，基本上可以說，1M的代碼包，下載耗時1秒左右。
控制包大小的措施：
- 壓縮代碼，清理無用的代碼
-
wxss 覆蓋率較高，較少或沒有引入未被使用的樣式。按需引入 wxss 資源，如果小程序中存在大量未使用的樣式，會增加小程序包體積大小，從而在一定程度上影響加載速度
- 圖片放在cdn
- 避免將不會被使用的文件打包進去
- 采用分包策略
- 分包預加載
- 獨立分包（版本要求有點高）
除了上面講的控制包的大小，對異步請求的優化也很重要。
對異步請求的優化
- onLoad 階段就可以發起請求，不用等ready
- 請求結果放在緩存中, 下次接着用
- 請求中可以先展示骨架圖
- 先反饋，再請求。比如說，點贊的按鈕，可以先改變按鈕的樣式，再發起異步請求。
setData 干了啥？每調用一次setData, 都是邏輯層向渲染層的一次通訊，這個通信還不是直接傳給webView, 而是通過走了native層，通訊的開銷很大。
渲染層收到通訊后，還需要重新渲染出來，所以，一次setData帶來兩次開銷：通信的開銷 + webview更新的開銷。
setData工作原理：
小程序的視圖層目前使用 WebView 作為渲染載體，而邏輯層是由獨立的 JavascriptCore 作為運行環境。在架構上，WebView 和 JavascriptCore 都是獨立的模塊，並不具備數據直接共享的通道。當前，視圖層和邏輯層的數據傳輸，實際上通過兩邊提供的 evaluateJavascript 所實現。即用戶傳輸的數據，需要將其轉換為字符串形式傳遞，同時把轉換后的數據內容拼接成一份 JS 腳本，再通過執行 JS 腳本的形式傳遞到兩邊獨立環境。
而 evaluateJavascript 的執行會受很多方面的影響，數據到達視圖層並不是實時的。
由於小程序運行邏輯線程與渲染線程之上，setData的調用會把數據從邏輯層傳到渲染層，數據太大會增加通信時間。
在數據傳輸時，邏輯層會執行一次JSON.stringify來去除掉setData數據中不可傳輸的部分，之后將數據發送給視圖層。
同時，邏輯層還會將setData所設置的數據字段與data合並，使開發者可以用this.data讀取到變更后的數據。
1、減少setData的數據量：如果一個數據不能會影響渲染層，則不用放在setData里面
2、合並setData的請求，減少通訊的次數
3、列表的局部更新
在一個列表中，有n條數據，采用上拉加載更多的方式，假如這個時候想對其中某一個數據進行點贊操作，還能及時看到點贊的效果。此時，可以采用setData全局刷新，點贊完成之后，重新獲取數據，再次進行全局重新渲染，這樣做的優點是：方便，快捷！缺點是：用戶體驗極其不好，當用戶刷量100多條數據后，重新渲染量大會出現空白期（沒有渲染過來）
如果采用局部刷新，將點贊的id傳過去，知道點的是那一條數據，重新獲取數據，查找相對應id的那條數據的下標（index是不會改變的），用setData進行局部刷新
this.setData({ list[index] = newList[index] })
小程序中可能有n個頁面，所有的這些頁面，雖然都擁有自己的webview(渲染層)， 但是卻共享同一個js運行環境。
也就是說，當你跳到了另外一個頁面（假設是B頁面），本頁面（假設是A頁面）的定時器等js操作仍在進行，並且不會被銷毀，並且會搶占B頁面的資源。
在h5的環境中，當我們跳轉到其他頁面，老頁面的js環境會被自動銷毀，定時器什么都被銷毀掉了，因此我們不需要關心老頁面中，還有哪些js代碼可能還會執行。但是在小程序中，我們必須手動的“清理”掉這樣的代碼。
4、小心onPageScroll
pageScroll 事件，也是一次通訊，是webview層向js邏輯層的通訊。這次通訊也是開銷較大，如果考慮到這個事件被頻繁的調用，回調函數如果有復雜的setData的話，性能就會很差了。
5、盡可能使用小程序組件
自定義組件的更新只在組件內部進行，不受頁面其他部分內容的影響；比如一些運營活動的定時模塊可以單獨抽出來，做成一個定時組件，定時組件的更新並不會影響頁面上其他元素的更新；各個組件也將具有各自獨立的邏輯空間。每個組件都分別擁有自己的獨立的數據、setData調用。