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

提高加載性能

提高渲染性能

分別為大家介紹一下：

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

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

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

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

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

下載代碼包

  下面具體介紹這兩個(gè)階段：

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

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

下載代碼包啟動(dòng)小程序

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

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

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

控制包的大小

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

控制包的大小的措施：

壓縮代碼，清理無(wú)用的代碼

圖片放在cdn

采用分包策略

分包預(yù)加載

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

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

對(duì)異步請(qǐng)求的優(yōu)化

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

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

請(qǐng)求中可以先展示骨架圖

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

提升渲染性能

setData 干了啥

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

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

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

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

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

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

列表的局部更新

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

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

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

盡可能使用小程序組件

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

優(yōu)化心得

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

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

后來(lái)發(fā)現(xiàn)，是因?yàn)槭醉?yè)需要監(jiān)聽(tīng)scroll事件，導(dǎo)致scroll事件被頻繁的觸發(fā)，回調(diào)函數(shù)中有耗時(shí)操作，導(dǎo)致onreachBottom事件被阻塞了，也就是說(shuō)，要等大概1~2秒才會(huì)去發(fā)起下一頁(yè)的請(qǐng)求。

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

一些總結(jié)

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