本文首發(fā)于公眾號(hào)「IT自學(xué)課堂」包晰。

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

1.1 啟動(dòng)流程

小程序在整個(gè)啟動(dòng)流程中，一般需要完成幾項(xiàng)工作：

1. 準(zhǔn)備運(yùn)行環(huán)境
2. 下載演侯，注入并執(zhí)行對(duì)應(yīng)小程序代碼包
3. 渲染小程序首頁(yè)

開(kāi)發(fā)者可以在第2姿染，3去優(yōu)化小程序的啟動(dòng)性能。

1.2 代碼包大小優(yōu)化

小程序在首次打開(kāi)時(shí)蚌本，會(huì)去下載并執(zhí)行代碼包盔粹，隨著代碼包大小的上升隘梨，耗時(shí)也會(huì)相應(yīng)增加程癌。開(kāi)發(fā)者可以采取以下方案：

• 使用分包技術(shù)
  • 優(yōu)勢(shì)：對(duì)開(kāi)發(fā)者而言，能使小程序有更大的代碼體積轴猎，承載更多的功能與服務(wù)嵌莉；而對(duì)用戶而言，可以更快地打開(kāi)小程序捻脖，同時(shí)在不影響啟動(dòng)速度前提下使用更多功能锐峭。
  • 建議開(kāi)發(fā)者按照功能的劃分，拆分成幾個(gè)分包可婶，當(dāng)需要用到某個(gè)功能時(shí)沿癞，才加載這個(gè)功能對(duì)應(yīng)的分包。
• 獨(dú)立分包
  • 優(yōu)勢(shì)：分包預(yù)下載是為了解決首次進(jìn)入分包頁(yè)面時(shí)的延遲問(wèn)題而設(shè)計(jì)的矛渴。如果能夠在用戶進(jìn)入分包頁(yè)面之前就預(yù)先將分包下載完畢椎扬，那么進(jìn)入分包頁(yè)面的延遲就能夠盡可能降低。
• 分包預(yù)加載
  • 優(yōu)勢(shì)：小程序中的某些場(chǎng)景（如廣告頁(yè)具温、活動(dòng)頁(yè)蚕涤、支付頁(yè)等），通常功能不是很復(fù)雜且相對(duì)獨(dú)立铣猩，對(duì)啟動(dòng)性能有很高的要求揖铜。使用獨(dú)立分包，可以獨(dú)立于主包和其他分包運(yùn)行达皿。從獨(dú)立分包中頁(yè)面進(jìn)入小程序時(shí)天吓，不需要下載主包。
  • 建議開(kāi)發(fā)者將部分對(duì)啟動(dòng)性能要求很高的頁(yè)面放到特殊的獨(dú)立分包中峦椰。
• 獨(dú)立分包與分包預(yù)下載使用教程

1.4 首屏渲染優(yōu)化

**提前首屏數(shù)據(jù)請(qǐng)求 **

大部分小程序在渲染首頁(yè)時(shí)龄寞，需要依賴服務(wù)端的接口數(shù)據(jù)，小程序?yàn)殚_(kāi)發(fā)者提供了提前發(fā)起數(shù)據(jù)請(qǐng)求的能力：

• 數(shù)據(jù)預(yù)拉取：能夠在小程序冷啟動(dòng)的時(shí)候通過(guò)微信后臺(tái)提前向第三方服務(wù)器拉取業(yè)務(wù)數(shù)據(jù)们何，當(dāng)代碼包加載完時(shí)可以更快地渲染頁(yè)面萄焦，減少用戶等待時(shí)間，從而提升小程序的打開(kāi)速度。
• 周期更新：在用戶未打開(kāi)小程序的情況下拂封，也能從服務(wù)器提前拉取數(shù)據(jù)茬射，當(dāng)用戶打開(kāi)小程序時(shí)可以更快地渲染頁(yè)面，減少用戶等待時(shí)間冒签。

**緩存請(qǐng)求數(shù)據(jù) **

小程序提供了wx.setStorageSync等異步讀寫(xiě)本地緩存的能力在抛，數(shù)據(jù)存儲(chǔ)在本地，返回的會(huì)比網(wǎng)絡(luò)請(qǐng)求快萧恕。如果開(kāi)發(fā)者基于某些原因無(wú)法采用數(shù)據(jù)預(yù)拉取與周期性更新刚梭，我們推薦優(yōu)先從緩存中獲取數(shù)據(jù)來(lái)渲染視圖，等待網(wǎng)絡(luò)請(qǐng)求返回后進(jìn)行更新票唆。

**精簡(jiǎn)首屏數(shù)據(jù) **

此外朴读，我們推薦開(kāi)發(fā)者延遲請(qǐng)求非關(guān)鍵渲染數(shù)據(jù)，縮短網(wǎng)絡(luò)請(qǐng)求時(shí)延走趋，與視圖層渲染無(wú)關(guān)的數(shù)據(jù)盡量不要放在 data 中衅金，加快首屏渲染完成時(shí)間。

避免阻塞渲染

在小程序啟動(dòng)流程中簿煌，會(huì)順序執(zhí)行app.onLaunch, app.onShow, page.onLoad, page.onShow, page.onReady氮唯，所以，盡量避免在這些生命周期中使用Sync結(jié)尾的同步API姨伟，如 wx.setStorageSync惩琉，wx.getSystemInfoSync 等。

2 渲染優(yōu)化

2.1 渲染時(shí)間優(yōu)化

渲染時(shí)間指的是首次渲染或因數(shù)據(jù)變化帶來(lái)的頁(yè)面結(jié)構(gòu)變化的渲染花費(fèi)的時(shí)間夺荒。

渲染界面的耗時(shí)過(guò)長(zhǎng)會(huì)讓用戶覺(jué)得卡頓瞒渠，體驗(yàn)較差，出現(xiàn)這一情況時(shí)般堆，需要校驗(yàn)下是否同時(shí)渲染的區(qū)域太大（例如列表過(guò)長(zhǎng)）在孝，或渲染依賴的計(jì)算是否過(guò)于復(fù)雜。

2.2 使用自定義組件

自定義組件的更新只在組件內(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)用晰搀。

3 邏輯層JS優(yōu)化

3.1 腳本執(zhí)行優(yōu)化

腳本執(zhí)行時(shí)間是指JS腳本在一次同步執(zhí)行中消耗的時(shí)間，比如生命周期回調(diào)办斑、事件處理函數(shù)的同步執(zhí)行時(shí)間外恕。

執(zhí)行腳本的耗時(shí)過(guò)長(zhǎng)會(huì)讓用戶覺(jué)得卡頓杆逗，體驗(yàn)較差，出現(xiàn)這一情況時(shí)鳞疲，需要確認(rèn)并優(yōu)化腳本的邏輯罪郊。

解決方案：一個(gè)執(zhí)行周期內(nèi)腳本運(yùn)行時(shí)間不超過(guò) 1 秒。

3.2 小心后臺(tái)頁(yè)面JS

小程序中可能有n個(gè)頁(yè)面尚洽，所有的這些頁(yè)面悔橄，雖然都擁有自己的webview(渲染層)， 但是卻共享同一個(gè)js運(yùn)行環(huán)境腺毫。也就是說(shuō)癣疟，當(dāng)你跳到了另外一個(gè)頁(yè)面（假設(shè)是B頁(yè)面），本頁(yè)面（假設(shè)是A頁(yè)面）的定時(shí)器等js操作仍在進(jìn)行潮酒，并且不會(huì)被銷毀睛挚，并且會(huì)搶占B頁(yè)面的資源。

解決方案：頁(yè)面銷毀時(shí)澈灼，先清除頁(yè)面中的定時(shí)器竞川；

3.2 正確使用事件

視圖層將事件反饋給邏輯層時(shí)店溢，需要一個(gè)通信過(guò)程叁熔，通信的方向是從視圖層到邏輯層。因?yàn)檫@個(gè)通信過(guò)程是異步的床牧，會(huì)產(chǎn)生一定的延遲荣回，延遲時(shí)間同樣與傳輸?shù)臄?shù)據(jù)量正相關(guān)，數(shù)據(jù)量小于64KB時(shí)在30ms內(nèi)戈咳。

解決方案：

• 去掉不必要的事件綁定（WXML中的 bind 和 catch）心软，從而減少通信的數(shù)據(jù)量和次數(shù)；
• 事件綁定時(shí)需要傳輸target和currentTarget的dataset著蛙，因而不要在節(jié)點(diǎn)的data前綴屬性中放置過(guò)大的數(shù)據(jù)删铃。

3.3 謹(jǐn)慎使用onPageScroll 和 scroll-view組件的scroll事件

scroll 事件，也是一次通訊踏堡，是webview層向js邏輯層的通訊猎唁。這次通訊也是開(kāi)銷較大，如果考慮到這個(gè)事件被頻繁的調(diào)用顷蟆，回調(diào)函數(shù)如果有復(fù)雜的setData的話，性能就會(huì)很差。

解決方案：

• 只在必要時(shí)監(jiān)聽(tīng)onPageScroll事件
• 不在onPageScroll中做復(fù)雜翩腐、耗時(shí)的邏輯處理
• 避免頻繁查詢節(jié)點(diǎn)信息(selectQuery)
• 當(dāng)需要在頻繁觸發(fā)的用戶事件(如 scroll 御雕、 Resize 事件)中調(diào)用 setData ，合理的利用 函數(shù)防抖(debounce) 和 函數(shù)節(jié)流(throttle) 可以減少 setData 執(zhí)行次數(shù)削樊。

4 setData優(yōu)化

setData是小程序開(kāi)發(fā)中使用最頻繁的接口豁生，也是最容易引發(fā)性能問(wèn)題的接口。

4.1 setData調(diào)用頻率優(yōu)化

setData接口的調(diào)用涉及邏輯層與渲染層間的線程通信，通信過(guò)于頻繁可能導(dǎo)致處理隊(duì)列阻塞甸箱，界面渲染不及時(shí)而導(dǎo)致卡頓眼刃，應(yīng)避免無(wú)用的頻繁調(diào)用。

解決方案：每秒調(diào)用setData的次數(shù)不超過(guò) 20 次摇肌。

4.2 setData數(shù)據(jù)大小優(yōu)化

由于小程序運(yùn)行邏輯線程與渲染線程之上擂红，setData的調(diào)用會(huì)把數(shù)據(jù)從邏輯層傳到渲染層，數(shù)據(jù)太大會(huì)增加通信時(shí)間围小。

解決方案：

• 控制要更新的數(shù)據(jù)大小
• 只更新 變化的數(shù)據(jù)
• 保證setData的數(shù)據(jù)在JSON.stringify后不超過(guò) 256KB

4.3 setData數(shù)據(jù)冗余優(yōu)化

setData操作會(huì)引起框架處理一些渲染界面相關(guān)的工作昵骤，一個(gè)未綁定的變量意味著與界面渲染無(wú)關(guān)，傳入setData會(huì)造成不必要的性能消耗肯适。

解決方案：setData傳入的所有數(shù)據(jù)都與頁(yè)面渲染有關(guān)变秦，對(duì)于與頁(yè)面渲染無(wú)關(guān)的變量，可以掛在頁(yè)面或者組件的this對(duì)象上框舔。

5 WXML優(yōu)化

5.1 控制頁(yè)面wxml節(jié)點(diǎn)數(shù)

建議一個(gè)頁(yè)面使用少于 1000 個(gè) WXML 節(jié)點(diǎn)蹦玫，節(jié)點(diǎn)樹(shù)深度少于 30 層，子節(jié)點(diǎn)數(shù)不大于 60 個(gè)刘绣。一個(gè)太大的 WXML 節(jié)點(diǎn)樹(shù)會(huì)增加內(nèi)存的使用樱溉，樣式重排時(shí)間也會(huì)更長(zhǎng)，影響體驗(yàn)纬凤。

解決方案：頁(yè)面WXML節(jié)點(diǎn)少于 1000 個(gè)福贞，節(jié)點(diǎn)樹(shù)深度少于 30 層，子節(jié)點(diǎn)數(shù)不大于 60 個(gè)停士。

5.2 正確使用wx:key

如果列表中項(xiàng)目的位置會(huì)動(dòng)態(tài)改變或者有新的項(xiàng)目添加到列表中挖帘，并且希望列表中的項(xiàng)目保持自己的特征和狀態(tài)（如 input 中的輸入內(nèi)容，switch 的選中狀態(tài)）恋技，需要使用 wx:key 來(lái)指定列表中項(xiàng)目的唯一的標(biāo)識(shí)符拇舀。

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

解決方案：

• 保證wx:key值的唯一性
• wx:key使用教程

6 圖片優(yōu)化

6.1 開(kāi)啟圖片緩存

開(kāi)啟 HTTP 緩存控制后，下一次加載同樣的圖片长搀，會(huì)直接從緩存讀取宇弛，大大提升加載速度。

解決方案：所有圖片均開(kāi)啟 HTTP 緩存

6.2 圖片大小優(yōu)化

圖片太大會(huì)增加下載時(shí)間和內(nèi)存的消耗源请，應(yīng)根據(jù)顯示區(qū)域大小合理控制圖片大小枪芒。

解決方案：如果儲(chǔ)存圖片的cdn支持彻况，可以對(duì)圖片進(jìn)行剪裁，使請(qǐng)求的圖片寬高都不超過(guò)實(shí)際顯示寬高的3倍舅踪。

6.3 圖片安全域名

使用 HTTPS纽甘，可以讓你的小程序更加安全，而 HTTP 是明文傳輸?shù)某槁担嬖诳赡鼙淮鄹膬?nèi)容的風(fēng)險(xiǎn)悍赢；

解決方案：使用 getHttpsImgUrl 函數(shù)，獲取圖片安全域名货徙。

function getHttpsImgUrl(url = '') {
  if(!url) return url;

  var httpsUrl = '';

  var domain = url.split('://')[1];

  httpsUrl = 'https://' + domain;

  return httpsUrl;
}

module.exports = {
  getHttpsImgUrl: getHttpsImgUrl
};

6.4 圖片請(qǐng)求數(shù)

短時(shí)間內(nèi)發(fā)起太多圖片請(qǐng)求會(huì)觸發(fā)瀏覽器并行加載的限制左权，可能導(dǎo)致圖片加載慢，用戶一直處理等待痴颊。

解決方案：應(yīng)該合理控制數(shù)量赏迟，可考慮使用雪碧圖技術(shù)或在屏幕外的圖片使用懶加載，保證每秒發(fā)起的圖片請(qǐng)求數(shù)不超過(guò) 20 個(gè)蠢棱。

6.5 應(yīng)讓圖片按原圖寬高比例顯示

圖片若沒(méi)有按原圖寬高比例顯示锌杀，可能導(dǎo)致圖片歪曲，不美觀泻仙，甚至導(dǎo)致用戶識(shí)別困難糕再。

解決方案：可根據(jù)情況設(shè)置 image 組件的 mode 屬性，以保持原圖寬高比饰豺。

7 網(wǎng)絡(luò)請(qǐng)求優(yōu)化

7.1 網(wǎng)絡(luò)請(qǐng)求數(shù)

短時(shí)間內(nèi)發(fā)起太多請(qǐng)求會(huì)觸發(fā)小程序并行請(qǐng)求數(shù)量的限制亿鲜，同時(shí)太多請(qǐng)求也可能導(dǎo)致加載慢等問(wèn)題

解決方案：合理控制請(qǐng)求數(shù)量冤吨，甚至做請(qǐng)求的合并等，保證每秒通過(guò)wx.request發(fā)起的請(qǐng)求數(shù)不超過(guò) 10 個(gè)饶套。

7.2 請(qǐng)求耗時(shí)

請(qǐng)求的耗時(shí)太長(zhǎng)會(huì)讓用戶一直等待甚至離開(kāi)漩蟆。

解決方案：應(yīng)當(dāng)優(yōu)化好服務(wù)器處理時(shí)間筋现、減小回包大小一膨，讓請(qǐng)求快速響應(yīng)买乃，保證網(wǎng)絡(luò)正常的情況下前联，所有網(wǎng)絡(luò)請(qǐng)求都在 1 秒內(nèi)返回結(jié)果功戚。

7.3 網(wǎng)絡(luò)請(qǐng)求緩存

發(fā)起網(wǎng)絡(luò)請(qǐng)求總會(huì)讓用戶等待，可能造成不好的體驗(yàn)似嗤，應(yīng)盡量避免多余的請(qǐng)求啸臀。

解決方案：對(duì)同樣的請(qǐng)求進(jìn)行緩存，3 分鐘以內(nèi)同一個(gè)url請(qǐng)求不出現(xiàn)兩次回包大于 128KB 且一模一樣的內(nèi)容烁落。

8 wxss優(yōu)化

8.1 提高wxss 覆蓋率

大量未使用的樣式乘粒，會(huì)增加小程序包體積大小，從而在一定程度上影響加載速度伤塌。

解決方案：

• 按需引入公用 wxss 資源灯萍；
• 刪除頁(yè)面中無(wú)用的wxss代碼；

8.2 滾動(dòng)區(qū)域可開(kāi)啟慣性滾動(dòng)以增強(qiáng)體驗(yàn)

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

9 UI交互優(yōu)化

9.1 合理設(shè)置可點(diǎn)擊元素的響應(yīng)區(qū)域大小

我們應(yīng)該合理地設(shè)置好可點(diǎn)擊元素的響應(yīng)區(qū)域大小，如果過(guò)小會(huì)導(dǎo)致用戶很難點(diǎn)中真屯，體驗(yàn)很差。

9.2 固定底部的可點(diǎn)擊組件都在iPhone X安全區(qū)域內(nèi)

底部的可交互組件如果渲染在iPhone X的安全區(qū)域外讨跟，容易誤觸Home Indicator 纪他。

關(guān)注我晾匠，一周3篇干貨文章與你分享。