微信小程序之提升應用速度小技巧

推薦理由：

關於小程序的相關乾貨，我已經在前面向你們推薦了幾篇文章，今天我推薦的這篇文章，主要是針對小程序的一些優化方法，如何有效提升小程序的響應速度和用戶體驗；但願對你們有所幫助。

如下爲文章原文：
做者：vicyao， 騰訊web前端開發 高級工程師
商業轉載請聯繫騰訊WeTest得到受權，非商業轉載請註明出處。
原文連接：http://wetest.qq.com/lab/view...

WeTest 導讀

小程序科普類的文章已經不少了，今天這裏講的是針對小程序的優化方法，能夠有效提升小程序的響應速度和用戶體驗。固然，開發體驗也提升很多。

一、提升頁面加載速度

在小程序這個環境下，怎樣提升頁面加載速度呢？ 這個問題很大，我把問題具體一下，如何縮短從用戶點擊某個連接，到打開新頁面的這段時間？ 這裏拋一個核心關鍵點：

從頁面響應用戶點擊行爲，開始跳轉，到新頁面onload事件觸發，存在一個延遲，這個延遲大概在100-300ms之間（安卓響應比ios慢些）。
這個延遲說短不短，咱們能夠利用這段時間，預先發起新頁面所須要的網絡請求。這樣一來，就節省了100-300ms（或者一個網絡請求的時間）。

知道有這個gap後，代碼如何實現呢？

說白了，就是實現一個在A頁面預加載B頁面數據的功能。但而這種跨頁面的調用，很容易把邏輯搞複雜，將不一樣頁面的邏輯耦合在一塊兒。因此，咱們但願將預加載的邏輯隱藏於無形中，不增長任何的頁面間耦合，以及開發複雜度。

下面以騰訊視頻小程序爲例，講解下技術實現。

小程序首頁：

當用戶點擊海報圖後，會執行如下代碼（就一行）：

接下來程序會加載播放頁：

播放頁主要代碼：

能夠看到，不論是外部頁面的調用仍是實際邏輯的實現都很是簡潔。在第二個頁面中，咱們擴展了Page的生命週期函數，增長了onNavigate方法。該方法在頁面即將被建立但還沒開始建立的時候執行。

老司機也許會發現這裏有點蹊蹺。在首頁點擊的時候，播放頁根本就沒有建立，對象都不存在，怎麼訪問到裏面的方法呢？
這裏就要說下微信的頁面機制。

在小程序啓動時，會把全部調用Page()方法的object存在一個隊列裏（以下圖）。每次頁面訪問的時候，微信會從新建立一個新的對象實例（實際上就是深拷貝）。

也就是說，在A頁面在執行點擊響應事件的時候，B頁面的實例還沒建立，這時候調用的onNavigate方法，其實是Page對象的原型（小程序啓動時候建立的那個）。

而接下來立刻要被建立的B頁面，又是另一個object。因此，在onNavigate和onLoad方法中，this指針指的不是同一個對象，不能把臨時數據存儲在當前object身上。所以咱們封裝了一對全局的緩存方法，$put()和$take()。

爲了通用性，Page上用到的公共的方法，好比$route、$put、$take都定義在了一個Page的基類裏面。基類還同時保存了全部頁面的list，這樣就能夠作到根據頁面名調用具體頁面的onNavigate方法。 固然，並非每一個頁面都須要實現onNavigate方法，對於沒有定義onNavigate方法的，$route函數會跳過預加載環節，直接跳轉頁面。因此對於開發者來講，不須要關心別的頁面實現了什麼，對外看來徹底透明。

二、用戶行爲預測

在上面的例子中，咱們實現了用戶主動點擊頁面，提早加載下一頁面數據的方法。而在某些場景下，用戶的行爲能夠預測，咱們能夠在用戶還沒點擊的時候就預加載下個頁面的數據。讓下個頁面秒開，進一步提高體驗的流暢性。

繼續以騰訊視頻小程序爲例，主界面分爲3個頁卡（大部分小程序都會這麼設計），經過簡單的數據分析，發現進入首頁的用戶有50%會訪問第二個頁卡。因此預加載第二個頁卡的數據能夠很大程度提升用戶下個點擊頁面的打開速度。

一樣，先看看代碼實現。 首頁預加載頻道頁的姿式：

頻道頁的實現方法：

跟第一個例子相似，這裏定義了一個$preLoad()方法，同時給Page擴展了一個onPreload事件。頁面調用$preLoad()後，基類會自動找到該頁面對應的onPreload函數，通知頁面執行預加載操做。 跟第一個例子不一樣，這裏預加載的數據會保存在storage內，由於用戶不必定會立刻訪問頁面，而把數據存在全局變量會增長小程序佔用的內存。微信會堅決果斷的把內存佔用過大的小程序給殺掉。

也許對於大部分有app開發經驗的同窗來講，更廣泛的作法是先讓頁面展現上次緩存的數據，再實時拉取新數據，而後刷新頁面。這個方法在小程序上也許體驗並不太好，緣由是小程序的性能以及頁面渲染速度都不如原生app。將一個大的data傳輸給UI層，是一個很重的操做。所以不建議採用這種方法。

三、減小默認data的大小

剛剛說到，頁面打開一個新頁面時微信會深拷貝一個page對象，所以，應該儘可能減小默認data的大小，以及減小對象內的自定義屬性。有圖有真相：

以一個100個屬性的data對象爲測試用例，在iphone6上，頁面的建立時間會所以增長150ms。

四、組件化方案

微信沒有提供小程序的組件化方案（相信必定在實現中）。但開談不說組件化，寫再多代碼也枉然。這裏演示一個簡單的組件化實現。

以騰訊視頻播放頁爲例，頁面定義以下：

其中，P()函數是自定義的基類。這是一個很是有用的東西，能夠把全部通用的邏輯都寫在基類裏面，包括pv統計，來源統計，擴展生命週期函數，實現組件化等。

函數第一個參數是頁面名稱，做爲頁面的key。第二個是page對象，其中擴展了一個comps數組，裏面就是全部要加載的組件。

以播放器組件/comps/player/index.js爲例：

組件的定義跟一個普通Page對象如出一轍，有data屬性，onLoad、onShow等事件，也有頁面響應的回調方法。wxml模板裏定義的事件和js事件一一對應。

基類作的事情，就是把這些組件對象的屬性和方法複製到Page對象上（淺拷貝）。其中data屬性會merge到一塊兒。而微信預約義的生命週期函數（包括本身擴展的），則封裝成隊列按序執行。好比當系統調用onLoad方法時，其實是執行了全部組件的onLoad方法，最後再執行Page的onLoad。

以上是代碼部分，至於wxml模板和wxss部分，就要手工import過去了。

wxml：

wxss：

五、其餘

雖然小程序已經足夠小巧，但啓動速度仍是有那麼2-3秒，沒法作到秒開。樓主嘗試對小程序的啓動時間作優化，但沒有找到多少有價值的優化點。單個頁面的初始化只須要1-2ms。也許大部分時間消耗在了微信跟服務器端通訊的過程當中。

所幸，騰訊提供了一個能夠自主進行服務器性能測試的環境，用戶只須要填寫域名和簡單的幾個參數就能夠獲知本身的服務器性能狀況，目前在騰訊WeTest平臺能夠無償使用。

騰訊WeTest服務器性能測試運用了沉澱十多年的內部實踐經驗總結，經過基於真實業務場景和用戶行爲進行壓力測試，幫助遊戲開發者發現服務器端的性能瓶頸，進行鍼對性的性能調優，下降服務器採購和維護成本，提升用戶留存和轉化率。

功能目前免費對外開放中，歡迎你們的體驗！

文章出自騰訊雲技術社區

（埋文字鏈https://www.qcloud.com/commun...）

推薦你們關注騰訊雲技術社區微信公衆號：QcloudCommunity