1. 程式人生 > >微信小程式效能優化方案——讓你的小程式如此絲滑

微信小程式效能優化方案——讓你的小程式如此絲滑

微信小程式如果想要優化效能,有關鍵性的兩點:

  1. 提高載入效能
  2. 提高渲染效能

接下來分別來介紹一下:

提高載入效能

首先,問一個問題,當用戶點選小程式後發生了什麼?

上圖中的三個狀態,我們經常遇到,它們分別對應小程式的下面三個狀態:

有三個點的白屏(左側): 下載程式碼包的階段

沒有三個點的白屏(中間): 業務程式碼注入和渲染的階段

載入中(右邊): 業務程式碼中非同步請求資料

總的來說,小程式呈現到使用者面前,實際上經歷了下面兩個階段:

  1. 執行環境的載入
  2. 下載程式碼包

下面具體介紹這兩個階段:

執行環境預載入

這步是微信做的。微信會在使用者開啟小程式之前就已經準備好環境,使用者點選小程式入口後,直接下載小程式的程式碼包即可。

下載程式碼包啟動小程式

小程式程式碼包裡面的程式碼,不是小程式的原始碼,而是編譯、壓縮、打包之後的程式碼包。

下圖中,左側的“預載入”對應的是執行環境的預載入,右側的“小程式啟動” 對應的是下載程式碼包啟動小程式。

小程式提供的執行環境,分為邏輯層(AppService)和 檢視層(webView),邏輯層是執行javascript的地方,檢視層是渲染頁面的地方。當小程式的程式碼包下載完畢後,業務程式碼分別注入邏輯層和渲染層。

提升載入效能的最最最關鍵性一點是,控制包的大小,這個也是微信官方的說法。

控制包的大小

提升體驗最直接的方法是控制小程式包的大小

,基本上可以說,1M的程式碼包,下載耗時1秒左右。

控制包的大小的措施

  • 壓縮程式碼,清理無用的程式碼
  • 圖片放在cdn
  • 採用分包策略
    • 分包預載入
    • 獨立分包(版本要求有點高)

除了上面講的控制包的大小,對非同步請求的優化也很重要。

對非同步請求的優化

  • onLoad 階段就可以發起請求,不用等ready
  • 請求結果放在快取中, 下次接著用
  • 請求中可以先展示骨架圖
  • 先反饋,再請求。比如說,點讚的按鈕,可以先改變按鈕的樣式,再 發起非同步請求。

提升渲染效能

setData 幹了啥

每呼叫一次setData, 都是邏輯層向渲染層的一次通訊,這個通訊還不是直接傳給webView, 而是通過走了native層,通訊的開銷很大。

渲染層收到通訊後,還需要重新渲染出來,所以,emmm, 一次setData帶來兩次開銷:通訊的開銷 + webview更新的開銷。

在資料傳輸時,邏輯層會執行一次JSON.stringify來去除掉setData資料中不可傳輸的部分,之後將資料傳送給檢視層。同時,邏輯層還會將setData所設定的資料欄位與data合併,使開發者可以用this.data讀取到變更後的資料。

減少setData的資料量

如果一個數據不能會影響渲染層,則不用放在setData裡面

合併setData的請求,減少通訊的次數

這個很好理解吧

列表的區域性更新

在一個列表中,有n條資料,採用上拉載入更多的方式,假如這個時候想對其中某一個數據進行點贊操作,還能及時看到點讚的效果

此時,可以採用setData全域性重新整理,點贊完成之後,重新獲取資料,再次進行全域性重新渲染,這樣做的優點是:方便,快捷!缺點是:使用者體驗極其不好,當用戶刷量100多條資料後,重新渲染量大會出現空白期(沒有渲染過來)

如果採用佈局重新整理,將點讚的id傳過去,知道點的是那一條資料, 將點讚的id傳過去,知道點的是那一條資料。

重新獲取資料,查詢相對應id的那條資料的下標(index是不會改變的),用setData進行區域性重新整理

this.setData({
    list[index] = newList[index]
})
複製程式碼

小心後臺頁面的js

小程式中可能有n個頁面,所有的這些頁面,雖然都擁有自己的webview(渲染層), 但是卻共享同一個js執行環境。也就是說,當你跳到了另外一個頁面(假設是B頁面),本頁面(假設是A頁面)的定時器等js操作仍在進行,並且不會被銷燬,並且會搶佔B頁面的資源。

在h5的環境中,當我們跳轉到其他頁面,老頁面的js環境會被自動銷燬,定時器什麼都被銷燬掉了,因此我們不需要關心老頁面中,還有哪些js程式碼可能還會執行。但是在小程式中,我們必須手動的“清理”掉這樣的程式碼。

小心onPageScroll

pageScroll 事件,也是一次通訊,是webview層向js邏輯層的通訊。這次通訊也是開銷較大,如果考慮到這個事件被頻繁的呼叫,回撥函式如果有複雜的setData的話,emmmmm, 效能就會很差了。

小心獲取節點位置

在h5 中的環境中,為了實現懶載入、下拉載入,我們不得不去獲取節點的位置。

為啥說不得不,是因為我們本可以用新的api ——intersectionObject去輕鬆實現(google等主流瀏覽器都已經支援了),但是微信的內建X5瀏覽器很遺憾的不支援。

沒想到,在小程式的環境中,微信竟然良心發現,支援intersectionObject api, 因此獲取節點的資訊,儘量還是用這api 吧。

儘可能使用小程式元件

自定義元件的更新只在元件內部進行,不受頁面其他不能分內容的影響;比如一些運營活動的定時模組可以單獨抽出來,做成一個定時元件,定時元件的更新並不會影響頁面上其他元素的更新;各個元件也將具有各自獨立的邏輯空間。每個元件都分別擁有自己的獨立的資料、setData呼叫

優化心得

相比於上面的優化策略,最重要的是找出小程式中的效能瓶頸。在自己的優化實踐中,遇到了下面的問題:

  1. 下拉載入更多,特別特別卡,通過列表區域性更新的技巧,發現效能改善不大。 後來發現,是因為首頁需要監聽scroll事件,導致scroll事件被頻繁的觸發,回撥函式中有耗時操作,導致onreachBottom事件被阻塞了,也就是說,要等大概1~2秒才會去發起下一頁的請求。 取消掉scroll事件的監聽,原本>4s的載入時間,控制在1s之內。

一些坑

  1. 在微信開發者工具沒有辦法復現某些效能問題,是因為從邏輯層到webview的通訊,開發者工具底層是通過onpostMessage, 微信ios好像是微信自己實現的橋接。所以強烈建議使用真機進行除錯
  2. 微信開發者工具,沒有辦法在【network】裡面看到圖片資源的載入,通過【trace】面板連線安卓真機也沒有辦法看到。如果想測試懶載入的效果,就比較麻煩,需要通過設定微信開發者工具的代理到127.0.0.1,通過charles可以抓包看到(截止2018年11月1日是這樣的)

一些迷茫

搞微信小程式遇到的這些坑,雖然可以收穫滿滿的填坑經驗,但是這些填坑經驗並不算是真正的計算機知識,因為這些知識的並不是基於對本質底層的理解,而是依靠經驗,而經驗是很快就會過時,可能下一次小程式api來一次大的升級,小程式優化手段馬上就會換成另外一種。