通常來說，微信小程序如果想要優(yōu)化性能，關(guān)鍵有兩方面：

提高加載性能

提高渲染性能

分別為大家介紹一下：

提高加載性能，模擬一個場景，當(dāng)用戶點(diǎn)擊小程序后，程序是如何運(yùn)作的？

上圖中的三個狀態(tài)，我們經(jīng)常遇到，它們分別對應(yīng)小程序的下面三個狀態(tài)：

  有三個點(diǎn)的白屏（左側(cè)）；下載代碼包的階段沒有三個點(diǎn)的白屏（中間）； 業(yè)務(wù)代碼注入和渲染的階段加載中（右邊）； 業(yè)務(wù)代碼中異步請求數(shù)據(jù)

  總的來說，小程序從點(diǎn)擊后到呈現(xiàn)內(nèi)容給用戶面前，實(shí)際上經(jīng)歷了兩個階段：

運(yùn)行環(huán)境的加載

下載代碼包

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

運(yùn)行環(huán)境預(yù)加載

  這步驟是微信提供的，微信會在用戶打開小程序之前就已經(jīng)準(zhǔn)備好環(huán)境，用戶點(diǎn)擊小程序入口后，直接下載小程序的代碼包即可。

下載代碼包啟動小程序

  小程序代碼包里面的代碼，不是小程序的源代碼，而是編譯、壓縮、打包之后的代碼包。

  小程序提供的運(yùn)行環(huán)境，分為邏輯層（AppService）和 視圖層（webView），邏輯層是執(zhí)行javascript的地方，視圖層是渲染頁面的地方。當(dāng)小程序的代碼包下載完畢后，業(yè)務(wù)代碼分別注入邏輯層和渲染層。

提升加載性能的最最最關(guān)鍵性一點(diǎn)是，控制包的大小，這個也是微信官方的說法。

控制包的大小

提升小程序性能優(yōu)化體驗(yàn)最直接的方法是控制小程序包的大小。

控制包的大小的措施：

壓縮代碼，清理無用的代碼

圖片放在cdn

采用分包策略

分包預(yù)加載

獨(dú)立分包（版本要求有點(diǎn)高）

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

對異步請求的優(yōu)化

onLoad 階段就可以發(fā)起請求，不用等ready

請求結(jié)果放在緩存中, 下次接著用

請求中可以先展示骨架圖

先反饋，再請求。比如說，點(diǎn)贊的按鈕，可以先改變按鈕的樣式，再 發(fā)起異步請求。

提升渲染性能

setData 干了啥

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

渲染層收到通訊后，還需要重新渲染出來，所以，emmm, 一次setData帶來兩次開銷：通信的開銷 + webview更新的開銷。

  在數(shù)據(jù)傳輸時，邏輯層會執(zhí)行一次JSON.stringify來去除掉setData數(shù)據(jù)中不可傳輸?shù)牟糠?，之后將?shù)據(jù)發(fā)送給視圖層。同時，邏輯層還會將setData所設(shè)置的數(shù)據(jù)字段與data合并，使開發(fā)者可以用this.data讀取到變更后的數(shù)據(jù)。

減少setData的數(shù)據(jù)量

如果一個數(shù)據(jù)不會影響渲染層，則不用放在setData里面

合并setData的請求，減少通訊的次數(shù)

列表的局部更新

  在一個列表中，有n條數(shù)據(jù)，采用上拉加載更多的方式，假如這個時候想對其中某一個數(shù)據(jù)進(jìn)行點(diǎn)贊操作，還能及時看到點(diǎn)贊的效果

此時，可以采用setData全局刷新，點(diǎn)贊完成之后，重新獲取數(shù)據(jù)，再次進(jìn)行全局重新渲染，這樣做的優(yōu)點(diǎn)是：方便，快捷！缺點(diǎn)是：用戶體驗(yàn)極其不好，當(dāng)用戶刷量100多條數(shù)據(jù)后，重新渲染量大會出現(xiàn)空白期（沒有渲染過來）

如果采用布局刷新，將點(diǎn)贊的id傳過去，知道點(diǎn)的是那一條數(shù)據(jù), 將點(diǎn)贊的id傳過去，知道點(diǎn)的是那一條數(shù)據(jù)。

盡可能使用小程序組件

  自定義組件的更新只在組件內(nèi)部進(jìn)行，不受頁面其他不能分內(nèi)容的影響；比如一些運(yùn)營活動的定時模塊可以單獨(dú)抽出來，做成一個定時組件，定時組件的更新并不會影響頁面上其他元素的更新；各個組件也將具有各自獨(dú)立的邏輯空間。每個組件都分別擁有自己的獨(dú)立的數(shù)據(jù)、setData調(diào)用

優(yōu)化心得

  相比于上面的優(yōu)化策略，最重要的是找出小程序中的性能瓶頸。在自己的優(yōu)化實(shí)踐中，遇到了下面的問題：

下拉加載更多，特別卡，通過列表局部更新的技巧，發(fā)現(xiàn)性能改善不大。

后來發(fā)現(xiàn)，是因?yàn)槭醉撔枰O(jiān)聽scroll事件，導(dǎo)致scroll事件被頻繁的觸發(fā)，回調(diào)函數(shù)中有耗時操作，導(dǎo)致onreachBottom事件被阻塞了，也就是說，要等大概1~2秒才會去發(fā)起下一頁的請求。

取消掉scroll事件的監(jiān)聽，原本>4s的加載時間，控制在1s之內(nèi)。

一些總結(jié)

  開發(fā)微信小程序遇到的這些問題，雖然可以收獲到不少經(jīng)驗(yàn)，但是這些經(jīng)驗(yàn)并不算是真正的計算機(jī)知識，因?yàn)檫@些知識的并不是基于對本質(zhì)底層的理解，而是依靠經(jīng)驗(yàn)，而經(jīng)驗(yàn)可能很快就會過時，可能下一次小程序api來一次大的升級，小程序優(yōu)化手段馬上就會換成另外一種，所以，作為開發(fā)人員需要不斷地了解行業(yè)內(nèi)的最新狀態(tài)，擴(kuò)大自己的知識面。