小程序怎么優化

這篇文章主要介紹了小程序怎么優化，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

優化項

1. 合理的使用分包

微信小程序的主要特點是啟動快速，為了這一特性，官方因此限制了包的大小，上限為 2M。

分包是小程序優化的第一要務，能有效提高小程序啟動速度，以及頁面打開速度。

包分為【主包】【普通分包】【獨立分包】。

【主包】應該只放置啟動頁或者TabBar頁面。

【普通分包】放置非TabBar頁面的其他頁面，推薦按照頁面數量或者模塊劃分多個分包，減少分包的大小，當用戶進入對應分包頁面的時候才會去下載這個包，這也實現了包的按需加載，避免了資源浪費。當小程序從普通分包中的某個頁面的時候啟動時，需要首先下載主包，然后在下載分包。

【獨立分包】放置一些獨立性較高的頁面，當小程序從獨立分包中的頁面啟動時，只會下載獨立分包，從而大大提高小程序啟動速度，當用戶進入TabBar頁面或者其他普通分包頁面才回去下載對應的包。

獨立分包中不能有任何全局的東西，包括組件，登錄等，引入任何其他包中的資源都會出錯。

作者建議梳理好頁面和功能再分包，分包的界限并不是包的大小超過了 2M，而是要靈活的根據業務和功能來進行劃分。在如今正常網絡情況下，2M 的分包和 500KB 的分包的下載可能用戶感知差距不會特別大，但是如果是在弱網環境下，這兩者會造成用戶白屏的時間上就有很大的差距（親身經歷，可以說是掏心掏肺了）。

比如，我會將那些可以由TabBar頁面直接進入且頻率較高的二級頁面放入一個分包，然后其他更深層次的頁面或者那些不是那么重要的頁面分成一個包，又或者將整個訂單業務模塊的頁面分成一個包。

包分好了，自然不能少了【分包預下載】。可以按照官網的規則進行配置，當用戶進入某個頁面時，提前下載包。

2. 按需注入

小程序下載完包之后，會將打開頁面所在包的全部JS合并注入，一些未訪問的頁面以及未用到的自定義組件也會被注入到運行環境當中。影響注入耗時和內存占用。我們希望的是當包下載完成后，只注入我們即將打開的頁面的代碼就行。

這也是小程序啟動或跳轉進入分包頁面影響白屏時間的一點。

{
    "lazyCodeLoading" : "requiredComponents"
}

3. 明確 setData 的幾個調用原則

小程序是以微信客戶端為宿主運行的，即wxml、wxs、wxss都是運行在客戶端的，運行環境又分成了兩個線程，一個渲染線程，一個邏輯線程。渲染層使用 WebView 進行渲染， 邏輯層使用JSCore運行JS代碼。wxml和wxss工作在渲染線程，而wxs工作在邏輯線程。那兩個線程之間怎么通信呢？

• 通過客戶端作為中轉站進行通信

渲染層觸發事件響應到客戶端，邏輯層通過setData傳送數據到客戶端，兩邊的數據都會被轉換成字符串之后進行傳輸，客戶端再分別做出響應，并且響應并非實時的。意味著在邏輯層觸發setData頁面并不會馬上更新，會有一些延遲渲染層才會更新。

回到問題，setData在邏輯層調用，讓渲染層快速響應取決于邏輯層到客戶端的數據傳輸效率，而這個傳輸效率又取決于你傳輸數據的大小，所以在調用setData的時候應該盡可能減少數據傳輸大小。

Native會將wxml轉換成 js對象，然后和setData傳進來的對象做差異化對比，將差異化渲染到視圖上。

綜上原理，我們調用setData應該遵循幾個原則：

• 盡可能減小需要 setData 數據的大小，JSON.stringify后不超過 256KB。

• 避免將不需要渲染的數據（不在wxml中綁定的數據）傳入setData，減少差異對比耗時。

• 避免過于頻繁調用setData，會導致邏輯層業務繁忙，一直在處理setData的傳輸隊列，而導致抽不開身去處理渲染層的響應，從而導致渲染阻塞，頁面出現卡頓，甚至setData無效。如果可以的話，可以采用節流等方式進行優化。

• 盡可能將多個需要更新的數據合并為一次setData，減少通信過程。

• 避免后臺頁面觸發setData，也會占用Js線程，有可能會造成阻塞，導致真正需要setData的數據沒有響應

減小setData的數據大小通常在列表場景中，通常只更新需要更新的下標：

const needRefresh = `list[${index}]`
// 寫法一
setData({
    [needRefresh]: '新值'
})

// 寫法二
setData({
    [`list[${index}]`]: '新值'
})

// 寫法三
setData({
    'list[0]': '新值'
})

// 寫法四
const needRefresh = `list[${index}].disabled`
setData({
    [needRefresh]: '新值'
})

// 寫法5 更新對象
setData({
    'personal.name':'xxx'
})

如果有變量，就需要放在[]內。

4. 控制圖片大小比例

圖片太大會增加下載時間和內存的消耗，并且為了用戶體驗，應該控制圖片的高寬比例，防止圖片變形或者被裁切（這個問題可以根據image的mode屬性進行調整）。

一個合格的圖片應該滿足以下兩點：

• 圖片寬高乘積 <= 實際顯示寬高乘積 * (設備像素比 ^ 2)。

• 顯示的高/寬與原圖的高/寬不超過 15%。

由于這些圖片都出自 UI，所以在這一條優化上你需要做的是：拿著這兩條指標去跟 UI battle。

good lucky ～

以上第一條就是和設備的【dpr】相關，移動端開發一定要理解【dpr】，這里就不多贅述了。

我們應該合理的采用圖片資源，例如在【dpr】為 2 的設備上，一個 60x60 的元素區域顯示的圖片為了兼顧清晰度與資源大小，圖片大小不應該超過 120x120， 同理，【dpr】為 3 設備，圖片應該不超過 180x180。

我們小程序的資源都放在cdn上，可以利用cdn的圖片云處理功能對資源請求進行控制，我司用的七牛云和又拍云，如下：

// 七牛云
`${_src}?imageMogr2/thumbnail/!${scaleRatio}p`

// 又拍云
`${_src}!/scale/${scaleRatio}`

更多云處理功能可以挪步官網：七牛云（https://developer.qiniu.com/dora/8255/the-zoom）  和又拍云（https://help.upyun.com/knowledge-base/image/）

我們在小程序內自定義了圖片組件 cus-image , 該組件會根據【dpr】對圖片進行云處理。并提供了 ratio 屬性靈活調整圖片大小（因為運營方上傳的圖片可能在不同尺寸的元素區域內引用，所以需要開發人員靈活控制）。

5. 避免短時間內發起太多請求

小程序中wx.request、wx.uploadFile、wx.downloadFile的發起的網絡請求短時間內最大并發限制是 10 個，超過 10 個就會導致請求阻塞。而圖片請求的并發最大數量為6。

那短時間怎么去界定呢？

• 【網絡請求】耗時超過 300ms 的請求并發數不超過 10 個（一般不會出現這個問題，如果有這個問題那可能該考慮拆分頁面、拆分業務或者合并接口了。）

• 【圖片請求】同域名耗時超過 100ms 的圖片請求并發數不超過 6 個

例如：300ms內發送了12個請求，其中10個請求在300ms內就請求完成了，只有2個請求超過300ms，這樣是沒有問題的。

【解決方案】

• 在接口請求上我們應該盡可能的減少請求數量。

• 圖片可以設置懶加載lazy-load。

• 圖標可以使用雪碧圖。

• 將圖片資源拆分在多個域名下。

• 自定義一個分片處理函數，將請求拆分成數個階段發出。

function interelTasks(task,wait){
    this.data.timer = setInterval(()=>{
        task()
    }, wait)
}

async function task(promiseList = []){
    const result = await promise.all(promiseList)
    // do something
}

叨擾一句：有些時候在請求數量限制范圍內，我們應該對沒有先后順序的接口進行并發處理，提高接口處理效率。

6. 請求耗時優化

這一點主要體現在兩個方面——【接口】和【靜態資源】。

【接口】基本上不應該超過1000ms，哪怕是幾百毫秒也可能需要做一些優化了，基本上正常速度在10-200ms，個別接口幾百也正常，大部分都應該不超過500ms(后端大佬請消消氣)。

【靜態資源】首先從資源的大小考慮出發，大部分資源是圖片，可以參考上面的圖片大小標準。其次考慮資源緩存，對于小程序而言，靜態資源基本上是存放在cdn上的，設置緩存可以有效的提高客戶端表現性能。

這邊給大家分享一個圖片壓縮網站：https://tinypng.com/

7. 避免使用過大的 WXML 節點數目

建議一個頁面使用少于 1000 個 WXML 節點，節點樹深度少于 30 層，子節點數不大于 60 個。一個太大的 WXML 節點樹會增加內存的使用，樣式重排時間也會更長，影響體驗。

頁面的節點數包含所有子節點數，需要注意的是子節點數，若一個子節點數大于60的時候，或許你就該考慮對組件或者頁面進行重新劃分了。

基本功！

8. 使用骨架屏

骨架屏相信大家都不陌生，如果我們的優化手段都用盡了，頁面需要加載的資源本身就比較多，那骨架屏也是我們退而求其次的最佳方案了，也算是“曲線救國“了。

實現骨架屏的方式有多種，你可以自己寫一個骨架組件，也可以用一些生成骨架屏的插件。除此之外，小程序還提供了白嫖方案，開發者工具提供了自動生成骨架屏代碼的能力。

詳情請訪問 https://developers.weixin.qq.com/miniprogram/dev/devtools/skeleton.html

9. 合理的進行組件拆分并減小data的大小

微信小程序的更新是基于組件的，自定義組件的更新只會在組件內部，這能減少差異比較帶來的耗時。

控制data的大小主要是為了減少內存消耗，比如在data中定義一些圖片路徑的變量，如果可以，我更推薦通過background的方式去加載一些圖片。

10. 滾動區域設置慣性滾動

慣性滾動會使滾動比較順暢，在安卓下默認有慣性滾動，而在 iOS 下需要額外設置 -webkit-overflow-scrolling: touch 的樣式。

11. 擴大點擊元素的可點擊區域

微信規定最小可點擊區域應該不小于 20x20 像素。這種樣式問題不多贅述了，八仙過海，各顯神通。

感謝你能夠認真閱讀完這篇文章，希望小編分享的“小程序怎么優化”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!