How to optimize small programs? This article will summarize the mini program optimization practice and take a look at the mini program optimization items. I hope it will be helpful to you!

The running process of the mini program

Let’s first sort out the operating principle of the mini program, so that you can chop wood without missing a beat.

A picture is worth a thousand words:

It is recommended that you carefully understand the content in the picture. It has strong theoretical support for small program development and optimization directions. .

Optimization items

1. Proper use of subcontracting

The main points of WeChat mini program It is characterized by fast startup. For this feature, the official has limited the size of the package, with an upper limit of 2M.

Subcontracting is the first priority for mini program optimization, which can effectively improve the startup speed of mini programs and the speed of page opening.

The package is divided into [main package] [ordinary subcontract] [independent subcontract].

[Main package] should only place the startup page or the TabBar page.

[Normal sub-package] Place other pages that are not TabBar pages. It is recommended to divide multiple sub-packages according to the number of pages or modules to reduce the size of the sub-package. When the user enters the corresponding sub-package page This package will be downloaded only when required, which also enables on-demand loading of packages and avoids waste of resources. When the mini program is started from a page in a normal sub-package, it needs to download the main package first, and then download the sub-package.

[Independent sub-package] Place some pages with high independence. When the mini program is started from the page in the independent sub-package, only the independent sub-package will be downloaded, thus greatly improving the startup speed of the mini program. When the user Enter the TabBar page or other ordinary subpackaging pages before going back to download the corresponding package.

There cannot be any global things in independent sub-packages, including components, logins, etc., and introducing any resources from other packages will cause errors.

The author recommendssort out the pages and functions before subcontracting. The limit of subcontracting is not that the size of the package exceeds 2M, but that it must be flexible Divide according to business and function. Under today's normal network conditions, the user may not perceive a particularly large difference between the download of 2M subpackage and 500KB subpackage. However, if it is in a weak network environment, the two Otherwise, there will be a big gap in the time the user has a blank screen (personal experience, it can be said that it is heartbreaking).

For example, I will put those secondary pages that can be directly accessed from the TabBar page and have a high frequency into a sub-package, and then other deeper pages Or those pages that are not so important are divided into a package, or the pages of the entire order business module are divided into a package.

Now that the package is divided, [subpackage pre-download] is naturally indispensable. It can be configured according to the rules of the official website. When the user enters a certain page, the package is downloaded in advance.

2. Inject on demand

After the applet downloads the package, it will open all the JS## of the package where the page is located. #Merge injection, some unvisited pages and unused custom components will also be injected into the running environment. Affects injection time and memory usage. What we hope is that when the package download is completed, only the code for the page we are about to open will be injected.

This is also the point where starting the mini program or jumping to the subcontracting page affects the white screen time.

{
    "lazyCodeLoading" : "requiredComponents"
}

3. Clarify several calling principles of setData<span style="font-size: 18px;"></span>

The mini program is run on the WeChat client, that is,

wxml, wxs, wxss are all run on the client, and the operating environment It is divided into two threads, a rendering thread and a logic thread. The rendering layer uses WebView for rendering, and the logic layer uses JSCore to run the JS code. wxml and wxss work on the rendering thread, while wxs works on the logical thread. How to communicate between two threads?

• Communicate through the client as a transfer station

The rendering layer triggers events and responds to the client, and the logic layer passes setData transmits data to the client. The data on both sides will be converted into strings and then transmitted. The client will respond separately, and the response is not real-time. This means that the page that triggers

setData in the logic layer will not be updated immediately, and there will be some delay before the rendering layer is updated.

The model is as shown in the figure:

Native is the client.

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

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

綜上原理，我們調(diào)用setData應(yīng)該遵循幾個原則：

• 盡可能減小需要 setData 數(shù)據(jù)的大小，JSON.stringify后不超過 256KB。
• 避免將不需要渲染的數(shù)據(jù)（不在wxml中綁定的數(shù)據(jù)）傳入setData，減少差異對比耗時。
• 避免過于頻繁調(diào)用setData，會導(dǎo)致邏輯層業(yè)務(wù)繁忙，一直在處理setData的傳輸隊列，而導(dǎo)致抽不開身去處理渲染層的響應(yīng)，從而導(dǎo)致渲染阻塞，頁面出現(xiàn)卡頓，甚至setData無效。如果可以的話，可以采用節(jié)流等方式進行優(yōu)化。
• 盡可能將多個需要更新的數(shù)據(jù)合并為一次setData，減少通信過程。
• 避免后臺頁面觸發(fā)setData，也會占用Js線程，有可能會造成阻塞，導(dǎo)致真正需要setData的數(shù)據(jù)沒有響應(yīng)

減小setData的數(shù)據(jù)大小通常在列表場景中，通常只更新需要更新的下標(biāo)：

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

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

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

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

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

如果有變量，就需要放在[]內(nèi)。

4. 控制圖片大小比例

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

一個合格的圖片應(yīng)該滿足以下兩點：

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

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

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

good lucky ～

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

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

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

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

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

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

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

5. 避免短時間內(nèi)發(fā)起太多請求

小程序中wx.request、wx.uploadFile、wx.downloadFile的發(fā)起的網(wǎng)絡(luò)請求短時間內(nèi)最大并發(fā)限制是 10 個，超過 10 個就會導(dǎo)致請求阻塞。而圖片請求的并發(fā)最大數(shù)量為6。

那短時間怎么去界定呢？

• 【網(wǎng)絡(luò)請求】耗時超過 300ms 的請求并發(fā)數(shù)不超過 10 個（一般不會出現(xiàn)這個問題，如果有這個問題那可能該考慮拆分頁面、拆分業(yè)務(wù)或者合并接口了。）
• 【圖片請求】同域名耗時超過 100ms 的圖片請求并發(fā)數(shù)不超過 6 個

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

【解決方案】

• 在接口請求上我們應(yīng)該盡可能的減少請求數(shù)量。
• 圖片可以設(shè)置懶加載lazy-load。
• 圖標(biāo)可以使用雪碧圖。
• 將圖片資源拆分在多個域名下。
• 自定義一個分片處理函數(shù)，將請求拆分成數(shù)個階段發(fā)出。

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

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

叨擾一句：有些時候在請求數(shù)量限制范圍內(nèi)，我們應(yīng)該對沒有先后順序的接口進行并發(fā)處理，提高接口處理效率。

6. 請求耗時優(yōu)化

這一點主要體現(xiàn)在兩個方面——【接口】和【靜態(tài)資源】。

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

【靜態(tài)資源】首先從資源的大小考慮出發(fā)，大部分資源是圖片，可以參考上面的圖片大小標(biāo)準(zhǔn)。其次考慮資源緩存，對于小程序而言，靜態(tài)資源基本上是存放在cdn上的，設(shè)置緩存可以有效的提高客戶端表現(xiàn)性能。

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

7. 避免使用過大的 WXML 節(jié)點數(shù)目

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

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

基本功！

8. 使用骨架屏

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

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

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

9. 合理的進行組件拆分并減小<span style="font-size: 18px;">data</span>的大小

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

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

10. 滾動區(qū)域設(shè)置慣性滾動

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

11. 擴大點擊元素的可點擊區(qū)域

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

最后

性能優(yōu)化不是一個技術(shù)債務(wù)，而是需要我們在平時的迭代版本中去不斷的優(yōu)化或重構(gòu)，團隊中的成員都應(yīng)該明確這一點。

性能優(yōu)化不僅僅是前端的事情，是需要團隊中各個不同的職責(zé)相互配合才能做好的事情，所以，如果你發(fā)現(xiàn)接口慢，圖片大，請勇敢的提出來，并和你的同事溝通解決。事無巨細，都很重要。

還有一些更細節(jié)的優(yōu)化點可以參考官網(wǎng)地址：

• https://developers.weixin.qq.com/miniprogram/dev/framework/audits/audits.html
  

如果有什么問題歡迎留言指正。

【相關(guān)學(xué)習(xí)推薦：小程序開發(fā)教程】

The above is the detailed content of Let me show you step by step how to optimize the mini program? (Practice summary). For more information, please follow other related articles on the PHP Chinese website!