對微信小程序進(jìn)行性能優(yōu)化，主要可以從兩大方面進(jìn)行分析：性能掃描工具和代碼優(yōu)化。

一、使用性能掃描工具

微信小程序提供了一個“體驗評分”的工具插件，可以使用它獲得微信小程序的一些性能數(shù)據(jù)和明顯的缺陷，進(jìn)而根據(jù)報告進(jìn)行相應(yīng)的優(yōu)化。

同時，為了方便開發(fā)者能夠及時發(fā)現(xiàn)小程序的體驗問題，從開發(fā)者工具 1.02.1811150 版本起支持體驗評分的 “自動運(yùn)行” 功能。一旦發(fā)現(xiàn)體驗分?jǐn)?shù)低于 70 分時，系統(tǒng)會在 console 面板打印一個 warning 信息提示開發(fā)者。

然后，根據(jù)效果圖的分析報告，查看需要優(yōu)化的細(xì)項，并根據(jù)說明一一進(jìn)行優(yōu)化。常見的優(yōu)化點包括：

• 應(yīng)避免出現(xiàn)任何 JavaScript 異常：因為出現(xiàn)JavaScript異?？赡軐?dǎo)致小程序的交互無法進(jìn)行下去；
• 所有請求的耗時不應(yīng)太久：因為請求耗時太長會讓用戶一直等待甚至離開，應(yīng)當(dāng)優(yōu)化好服務(wù)器處理時間、減小回包大小，讓請求快速響應(yīng)；
• 避免將未綁定在 WXML 的變量傳入setData：因為setData操作會引起框架處理一些渲染界面相關(guān)的工作，而一個未綁定的變量意味著與界面渲染無關(guān)，傳入setData會造成不必要的性能消耗；
• 避免渲染界面的耗時過長：因為渲染界面的耗時過長會讓用戶覺得卡頓，體驗較差；
• 避免執(zhí)行腳本的耗時過長：因為執(zhí)行腳本的耗時過長會讓用戶覺得卡頓，體驗較差，出現(xiàn)這一情況時，需要確認(rèn)并優(yōu)化腳本的邏輯；
• 網(wǎng)絡(luò)請求使用 HTTPS：因為使用 HTTPS，可以讓你的小程序更加安全，而 HTTP 是明文傳輸?shù)?#xff0c;存在可能被篡改內(nèi)容的風(fēng)險；
• 避免過大的 WXML 節(jié)點數(shù)目：建議一個頁面使用少于 1000 個 WXML 節(jié)點，節(jié)點樹深度少于 30 層，子節(jié)點數(shù)不大于 60 個。一個太大的 WXML 節(jié)點樹會增加內(nèi)存的使用，樣式重排時間也會更長；
• 及時回收定時器：因為定時器是全局的，并不是跟頁面綁定的，所以當(dāng)頁面因后退被銷毀時，定時器應(yīng)注意手動回收；

除此之外，微信小程序官方還給出了如下一些要求：

• 代碼包不包含插件大小超過 1.5 M：小程序代碼包單個包大小限制為2M。因此我們建議開發(fā)者在開發(fā)時，如果遇到單包體積大于1.5M的情況，可以采取分包的方式，把部分代碼拆分到分包去，降低單個包的體積，提升小程序的加載速度
• 引用插件大小超過 200 K：小程序插件的大小是會算進(jìn)小程序代碼包2M體積限制中的。因此當(dāng)我們發(fā)現(xiàn)開發(fā)者引用的插件體積大于200K時，會對開發(fā)者予以提示，避免出現(xiàn)上傳階段提示代碼包體積超限。
• 圖片和音頻資源大小超過 200 K：小程序代碼包里可以存放一些必要的靜態(tài)資源（例如tabbar的icon等），不過靜態(tài)資源體積過大也會影響小程序代碼包加載速度。因此我們建議圖片、音頻等靜態(tài)資源體積大小超過200K時，將它們上傳到CDN，用URL引入會是個更好的選擇。
• 主包存在僅被其他分包依賴的JS：當(dāng)主包里存在一些JS文件只會被分包使用（而主包自己不使用）時，我們建議把這些JS文件從主包中拆分出去，放到對應(yīng)的分包里，從而優(yōu)化主包的加載速度。
• 主包存在僅被其他分包依賴的組件：當(dāng)主包里存在一些組件只會被分包使用（而主包自己不使用）時，我們建議把這些組件從主包拆分出去，并且可以使用 分包異步化 這個特性加載這些組件，從而優(yōu)化主包的加載速度。
• 存在無使用的插件：如果有無使用的插件，請將其從 app.json 中去除。不然它會占用代碼包體積，也會延遲代碼包加載的時間。
• 存在無使用的組件：如果在對應(yīng)頁面JSON的 usingComponents 里聲明的組件但是沒有使用，請將其從 usingComponents 里去除。

二、其他常見優(yōu)化

2.1 啟動優(yōu)化

針對啟動性能優(yōu)化，可以從以下幾個方面著手：
控制代碼包大小

• 開啟開發(fā)者工具中"上傳代碼時自動壓縮"；
• 及時清理無用代碼和資源文件；
• 減少代碼包中的圖片等資源文件的大小和數(shù)量；

分包加載

• 將小程序中不經(jīng)常使用的頁面放到多個分包內(nèi)，主包是保留最常用的核心頁面；啟動時只加載主包，使用時按需下載分包；
• 使用分包加載會出現(xiàn)用戶首次進(jìn)入分包頁面時需要進(jìn)行分包的下載和注入，造成頁面切換的延遲；開發(fā)者可使用分包預(yù)下載，預(yù)先配置頁面可能會跳轉(zhuǎn)到的分包，框架在進(jìn)入頁面后根據(jù)配置進(jìn)行預(yù)下載；

獨立分包

• 從分包頁面啟動時，必需要先依賴于主包的下載和注入，啟動速度受主包限制；使用獨立分包，從獨立分包頁面啟動，只下載和注入分包就可以打開頁面；

2.2 首屏加載的體驗優(yōu)化建議

• 提前請求：異步數(shù)據(jù)請求不需要等待頁面渲染完成（onLoad 階段就可以發(fā)起請求，不用等ready）；
• 利用緩存：利用storage API對異步請求數(shù)據(jù)進(jìn)行緩存，二次啟動時先利用緩存數(shù)據(jù)渲染頁面，而下拉刷新或者緩存過期才更新數(shù)據(jù)；
• 避免白屏：先展示頁面骨架和基礎(chǔ)內(nèi)容；
• 及時反饋：即時地對需要用戶等待的交互操作給出反饋，避免用戶以為小程序無響應(yīng)；

2.3 避免不當(dāng)使用setData

當(dāng)setData的數(shù)據(jù)過大時，通訊方面會帶來巨大的消耗，大部分人面對長列表滾動的時候，一開始的處理方式都是這樣的，如果數(shù)據(jù)不多，只有幾頁可能不會太暴露問題；但當(dāng)頁數(shù)過多，幾十頁甚至上百頁的情況，list的數(shù)據(jù)會越來越大，每次setData的數(shù)據(jù)就會越來越多，因而每次頁面重新渲染的節(jié)點就會越來越多，從而導(dǎo)致滾動到后面，加載越來越慢。另外，由于小程序的視圖渲染層和數(shù)據(jù)邏輯處理層是分開的，不是在同一個線程上面的，從用戶觸發(fā)頁面交互，到處理數(shù)據(jù)邏輯，最后呈現(xiàn)頁面，數(shù)據(jù)到視圖是需要傳輸?shù)?#xff0c;因而小程序本身對數(shù)據(jù)大小也有限制，不能超過1M。

2.4 存在短時間內(nèi)發(fā)起太多圖片請求

一次性發(fā)送了過多的圖片請求，導(dǎo)致了同一時間發(fā)起了過多的http請求，http連接是非常耗時的，尤其是一次性發(fā)起這么多，并且一次性發(fā)起的http鏈接也是有限制的，比如chrome瀏覽器就限制一次性最多6個。所以在渲染頁面時，不在視圖范圍內(nèi)的圖片不要不加載，只有元素出現(xiàn)在視圖范圍內(nèi)了才渲染。

要實現(xiàn)這一效果，我們可以通過 getBoundingClientRect() 獲取元素的位置，然后與頁面滾動位置進(jìn)行比較，如果出現(xiàn)在視圖內(nèi)就加載顯示圖片。具體實現(xiàn)上，我們可以失業(yè)微信提供的 IntersectionObserver 對象，IntersectionObserver 對象可以用于推斷某些節(jié)點是否可以被用戶看見、有多大比例可以被用戶看見，示例如下。

let data = list; <img class="img-{{index}}" wx:for="{{data}}"></img> data.forEach((item,index)=>{this.createIntersectionObserver().relativeToViewport.observe(`.img-${index}`,res=>{if (res.intersectionRatio > 0){this.setData({item.imgShow:true})}}) })

2.5 在列表渲染中巧用key值

在列表渲染過程中，巧用key值能夠提升列表渲染性能。在小程序開發(fā)中，頁面的渲染主要分為以下幾步：

將wxml結(jié)構(gòu)的文檔構(gòu)建成一個vdom虛擬數(shù)。

頁面有新的交互，產(chǎn)生新的vdom數(shù)，然后與舊數(shù)進(jìn)行比較，看哪里有變化了，做對應(yīng)的修改（刪除、移動、更新值）等操作。

最后再將vdom渲染成真實的頁面結(jié)構(gòu)。

key值的作用就在第二步，當(dāng)數(shù)據(jù)改變觸發(fā)渲染層重新渲染的時候，會校正帶有 key 的組件，框架會確保他們被重新排序，而不是重新創(chuàng)建，以確保使組件保持自身的狀態(tài)，并且提高列表渲染時的效率。

2.6 避免使用onPageScroll不當(dāng)

不正確的使用onPageScroll，可能會帶來重復(fù)渲染的問題。因此，使用onPageScroll時，應(yīng)注意以下幾點：

• 只在必要的時候監(jiān)聽pageScroll事件；
• 避免在onPageScroll中執(zhí)行復(fù)雜邏輯；
• 避免在onPageScroll中頻繁調(diào)用setData；
• 避免頻繁查詢節(jié)點信息（SelectQuery）；

總結(jié)

以上是生活随笔為你收集整理的微信小程序性能优化总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。