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

一、使用性能掃描工具

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

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

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

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

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

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

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

2.1 啟動(dòng)優(yōu)化

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

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

分包加載

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

獨(dú)立分包

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

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

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

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

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

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

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

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

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)建成一個(gè)vdom虛擬數(shù)。

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

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

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

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

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

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

總結(jié)

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

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