本文主要是根據微信小程序官方優(yōu)化建議和《2018微信公開課第七季上海站·小程序專場》的性能優(yōu)化方案，針對性我們的小程序項目進行性能優(yōu)化實踐，將過程記錄下來，方便以后查看，同時也希望能幫助到其他小伙伴，做好性能優(yōu)化。畢竟一切性能優(yōu)化都是為了更好的用戶體驗。

小程序常見性能問題

• 這個小程序為什么這么慢？
• 這個小程序為什么滑不動了，卡住了？
• 小程序在切頁面的時候為什么會有延遲？
• 為什么點擊了沒有反應，是不是掛掉啦？

這些問題的場景都反映了小程序的性能問題，直接影響到用戶體驗。

小程序如何進行性能優(yōu)化？

官方建議從這兩方面進行優(yōu)化：

• 啟動性能優(yōu)化
• 渲染性能優(yōu)化

啟動性能優(yōu)化

小程序在整個啟動流程中，一般需要完成幾項工作：

• 1.準備運行環(huán)境（微信自己處理的）
• 2.下載，注入并執(zhí)行對應小程序代碼包
• 3.渲染小程序首頁

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

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

小程序在首次打開時，會去下載并執(zhí)行代碼包，隨著代碼包大小的上升，耗時也會相應增加?？梢圆扇∫韵路桨福?/p>

分包

使用分包

對開發(fā)者而言，能使小程序有更大的代碼體積，承載更多的功能與服務；而對用戶而言，可以更快地打開小程序，同時在不影響啟動速度前提下使用更多功能。

建議開發(fā)者按照功能的劃分，拆分成幾個分包，當需要用到某個功能時，才加載這個功能對應的分包。

使用分包實踐

我們的一個小程序在兩年多前開始開發(fā)的，在設計之初，我們沒有考慮到這一點，當時也沒有小程序分包的功能。好吧，我們還是迎來了這個問題。

微信小程序在開發(fā)文檔中明確指出，小程序的所有包大小必須限制在2M以內，超過大小，就算在開發(fā)者工具中都不能正常預覽，更不能上傳發(fā)版。解決問題的方法：

將靜態(tài)資源圖片壓縮，因為小程序的壓縮算法對圖片的壓縮微乎其微，于是互，筆者對圖片進行一輪壓縮，并且將重復使用的圖片，進行了公共提取，雖然官方推薦使用網絡圖片，但是還需要去維護靜態(tài)資源，嫌麻煩，就放棄。

將項目中的棄用的頁面，以及不用的三方，進行了一波清除。

很多項目現(xiàn)在都是通過webpack打包成不通的分包，資源懶加載的形式來優(yōu)化，小程序也提供了這個功能：分包，筆者按照按照功能劃分的原則，將同一個功能下的頁面和邏輯放置于同一個目錄下，成為一個分包。

分包之后：

注意：1. 自定義第三方組件，需要放在主包內，miniprogram_npm文件會直接打到主包里；2. 小程序的tab切換頁，必須放在主包里。

分包預下載

分包預下載是為了解決首次進入分包頁面時的延遲問題而設計的。如果能夠在用戶進入分包頁面之前就預先將分包下載完畢，那么進入分包頁面的延遲就能夠盡可能降低。

實踐

用戶進行了某個操作，再去下載分包，延遲操作用戶體驗很差，于是乎筆者對上面的分包設置分包預下載。在 app.json 文件中配置：

"preloadRule": {
    "pages/work/index": {
      "network": "all",
      "packages": [
        "package-work",
        "package-field-statistics"
      ]
    },
    "pages/appeal/index": {
      "network": "all",
      "packages": [
        "package-appeal"
      ]
    }
},
復制代碼

這里建議不要一次性把所有分包預下載，這樣的操作同樣回帶來性能問題。

獨立分包

小程序中的某些場景（如廣告頁、活動頁、支付頁等），通常功能不是很復雜且相對獨立，對啟動性能有很高的要求。使用獨立分包，可以獨立于主包和其他分包運行。從獨立分包中頁面進入小程序時，不需要下載主包。

建議開發(fā)者將部分對啟動性能要求很高的頁面放到特殊的獨立分包中。

實踐

項目中沒有適合的場景，尚未實踐。

2.首屏渲染優(yōu)化

1. 提前首屏數據請求

大部分小程序在渲染首頁時，需要依賴服務端的接口數據，接口請求放到頁面的生命周期 onLoad 中，而不是 onReady 里。 `：

實踐

監(jiān)聽到頁面加載，就校驗登錄情況，請求頁面數據

onLoad: function (options) {
    app.checkAuth((error, token) => {
      if (error) {
        return
      }
      // 請求該頁面的數據
    })
  },
復制代碼

2. 緩存請求數據

小程序提供了wx.setStorageSync等異步讀寫本地緩存的能力，數據存儲在本地，返回的會比網絡請求快。

實踐

登錄成功后將用戶的token，以及用戶信息都可以緩存到本地，記得退出登錄的時候清楚緩存，:joy:。

/**
 * 設置本地 token 緩存
 * @param {Object} session 服務器返回的數據
 * @param {String} session.access_token 存取token
 * @param {String} session.refresh_token 刷新token
 * @param {String} session.expires_in 有效期限，以秒為單位
 */
export function set(session) {
  const localSession = Object.assign({}, session, {
    expires_timestamp: getExpireTimestamp(session.expires_in)
  });
  wx.setStorageSync(SESSION_KEY, localSession);

  _token = session.access_token;
}

export function clear() {
  wx.removeStorageSync(SESSION_KEY);
  clearTimeout(refresh_timer);

  _token = null;
}
復制代碼

3. 精簡首屏數據

推薦開發(fā)者延遲請求非關鍵渲染數據，縮短網絡請求時延，與視圖層渲染無關的數據盡量不要放在 data 中，以免傳輸垃圾數據，加快首屏渲染完成時間。

實踐

通過id請求詳情的情況，id在渲染層不需要，就可以不把id，定義在data中：

// 原來代碼
data: {
    id: ‘’,
    // ….
},
onLoad: function (options) {
    	this.setData({
		id: options.id
	})
	// ….
}

// 改寫后 不把id定義到data中
data: {
    // ….
},
app.checkAuth((error, token) => {
      const id = options.id === undefined ? '' : options.id;
      this.id = id 
})
復制代碼

接口返回的數據要做數據處理，不要直接都塞給data，減少冗余數據的雙線程回傳。也是 精簡首屏數據優(yōu)化的一部分。

4. 避免阻塞渲染

在小程序啟動流程中，會順序執(zhí)行app.onLaunch, app.onShow, page.onLoad, page.onShow, page.onReady，所以，盡量避免在這些生命周期中使用Sync結尾的同步API，如 wx.setStorageSync，wx.getSystemInfoSync 等。

實踐

項目中沒有這樣使用，有先見之明。:smile:

渲染性能優(yōu)化

小程序的視圖層目前使用 WebView 作為渲染載體，而邏輯層是由獨立的 JavascriptCore 作為運行環(huán)境。在架構上，WebView 和 JavascriptCore 都是獨立的模塊，并不具備數據直接共享的通道。當前，視圖層和邏輯層的數據傳輸，實際上通過兩邊提供的 evaluateJavascript 所實現(xiàn)。即用戶傳輸的數據，需要將其轉換為字符串形式傳遞，同時把轉換后的數據內容拼接成一份 JS 腳本，再通過執(zhí)行 JS 腳本的形式傳遞到兩邊獨立環(huán)境。

而 evaluateJavascript 的執(zhí)行會受很多方面的影響，數據到達視圖層并不是實時的。

** 常見的 setData 操作錯誤 **

1. 頻繁的去 setData

導致了兩個后果：

• Android 下用戶在滑動時會感覺到卡頓，操作反饋延遲嚴重，因為 JS 線程一直在編譯執(zhí)行渲染，未能及時將用戶操作事件傳遞到邏輯層，邏輯層亦無法及時將操作處理結果及時傳遞到視圖層；
• 渲染有出現(xiàn)延時，由于 WebView 的 JS 線程一直處于忙碌狀態(tài)，邏輯層到頁面層的通信耗時上升，視圖層收到的數據消息時距離發(fā)出時間已經過去了幾百毫秒，渲染的結果并不實時；

實踐

目前項目代碼還是比較規(guī)范的，我們并沒有把setData當成一個普通的對象去調用，曉得每次使用都需要兩個線程間通信，WebView再去渲染的。哇，好棒。

2. 每次 setData 都傳遞大量新數據

由setData的底層實現(xiàn)可知，我們的數據傳輸實際是一次 evaluateJavascript 腳本過程，當數據量過大時會增加腳本的編譯執(zhí)行時間，占用 WebView JS 線程。

實踐

目前每個接口的數據量并大，數據的量級還沒達到影響腳步執(zhí)行的程度，有需要的話再優(yōu)化吧。

3. 后臺態(tài)頁面進行 setData

當頁面進入后臺態(tài)（用戶不可見），不應該繼續(xù)去進行setData，后臺態(tài)頁面的渲染用戶是無法感受的，另外后臺態(tài)頁面去setData也會搶占前臺頁面的執(zhí)行。

實踐

A頁面上有個定時器，此時打開了B頁面，A頁面的定時器還在運行，繼續(xù)搶占B頁面的資源，B頁面卡頓了，但是并不是B頁面的造成的性能問題，這種問題就不太好排查。希望大家都能做個有始有終的人，定時器不用了要清除。下面demo，定時器在 onHide 時要清除掉。切記切記:point_down:

/**
   * 生命周期函數--監(jiān)聽頁面顯示
   */
onShow: function () {
    clearTimeout(getTodaytime)
    this.updateNowTime()
},

/**
   * 生命周期函數--監(jiān)聽頁面隱藏
 */
onHide: function () {
    // 取消定時器 防止小程序內存不足，崩潰
    clearTimeout(getTodaytime)
},
updateNowTime() {
    getTodaytime = setInterval(() => {
      const myDate = new Date(); 
      const hours = myDate.getHours())
      const minutes = myDate.getMinutes())
      const seconds = myDate.getSeconds())

      const newTime = hours + ':' + minutes + ':' + seconds;
      this.setData({
        newTime: newTime
      })
    }, 1000)
  },
復制代碼

2. 用戶事件使用不當

• 過多的使用bindTap、bindCatch
• 不當的使用onPageScroll

實踐

項目中展示沒用使用該事件。

3. 使用自定義組件

在需要頻繁更新的場景下，自定義組件的更新只在組件內部進行，不受頁面其他部分內容復雜性的影響。