微信小程序性能優化入門指南

小程序從發佈到如今也已經有將近兩年的時間，愈來愈來多的公司開始重視小程序生態帶來的流量，今年也因爲小程序平臺對外能力的愈來愈多的開放以及小程序平臺的自身優化，愈來愈多的開發者也自主的投入到小程序的開發當中，如今，做爲前端若是會寫小程序，絕對是一個徹徹底底的面試加分項。
相信很多人剛接觸小程序時的感受大都是小程序很簡單，開發只要是會寫html、css、js就能夠了，可是當本身的第一個小程序開發完成上線時，卻發現小程序體驗很是糟糕，接下來就讓咱們一窺小程序優化之道。

加載流程

要想給小程序作優化，對小程序的加載流程必定要有必定的瞭解，小程序是怎麼加載的，讓咱們先來看一個圖片：

這三個圖片你們必定都不陌生，當你打開一個小程序的時候就會經歷這三個過程：

1. 資源準備，這個過程就是小程序在下載你的代碼包的過程
2. 業務代碼注入和渲染，這個過程就是小程序將的業務代碼分別注入視圖層和邏輯層，並在視圖層作視圖的渲染
3. 異步數據的請求，顯示加載中的時候，其實就是在到達首頁時，若是首頁有異步數據請求，這個時候小程序就會執行異步數據請求

上述就是對小程序的啓動過程的一個簡單概述，讓咱們再來看一個更加具體一點的圖片，可能會更好理解小程序啓動過程：

從這個圖片能夠看到，小程序在啓動加載的時候，其實分爲兩部分，一部分是邏輯層的啓動啓動，另外一部分是視圖層的啓動，邏輯層的啓動就是加載小程序的js代碼，視圖層的啓動webview對頁面進行加載和渲染，那預加載又是何時執行的呢？其實在微信動的時候，小程序平臺就開始靜默執行與加載的過程，包括JS引擎初始化和WebView的初始化，而後會注入小程序自帶的公共庫，例如自帶api、組件等，後面的小程序啓動，就是上面說過的打開一個小程序具體的啓動加載過程了，下載代碼包，分別注入邏輯層和視圖層，而後共同完成首屏渲染。

啓動性能優化

講完小程序的啓動過程，就能夠開始介紹具體的性能優化方案了，讓咱們一塊兒看看影響小程序性能的因素以及具體的解決辦法

代碼包大小

代碼包大小會直接影響小程序的啓動速度，代碼包越大，小程序的啓動時間就越長，在小程序啓動時，下載代碼包和代碼注入的時間和小程序代碼包大小是成正比的，通常小程序的平均啓動時間是2s左右，能夠看看你的小程序有沒有拖後腿，那麼如何控制包大小呢？

資源控制

1. 開啓開發工具」上傳代碼時自動壓縮」，小程序開發工具備一個上傳代碼時自動壓縮的功能，當開啓時，會在你上傳代碼時爲你作代碼壓縮，除了這個，咱們也能夠經過使用第三方打包工具作代碼壓縮，如webpack、grunt、grulp。
2. 及時清理無用代碼和資源文件，無用的代碼和資源也會佔用必定的包大小。
3. 減小代碼包中的資源文件，將資源存放在cdn上，小程序開發工具對資源文件的壓縮比率很是低，資源有條件的能夠儘可能放在CDN上，由於小程序開發工具對資源文件的壓縮比率很是低，只有10%左右，或者也能夠用第三編譯工具對資源文件本身進行壓縮處理

分包加載

分包加載是小程序提升加載啓動性能的一個重要方法，若是有人還不瞭解，能夠點開連接看官方介紹，那麼如何作好分包加載呢？
將小程序中不經常使用的代碼放在分包中，主包內只保留用戶最常訪問的頁面，可是因爲官方規定tab頁面只能放在主包中，由於小程序啓動時只會加載主包，使用時按需下載分包，不會在加載時一次將整個代碼包下載，這樣就能有效減小啓動加載的時間。
可是分包加載也有它的侷限性，用戶首次打開分包頁面時，須要先進行分包代碼的加載和注入，會形成頁面切換時產生必定的延時，所以在此基礎上，官方又推出了分包預加載和獨立分包。

分包預加載

先來看一下以前分包加載時的流程是怎樣的：

那麼分包預加載是怎麼幹的呢？分包預下載：提早配置可能會跳到哪些分包，框架在進入頁面後根據配置進行預下載，分包預加載會在你進入主包頁面後，爲你靜默開啓分包代碼的下載和注入，這個過程是無感的，來看一下分包預加載的流程是怎樣的：

分包預加載須要注意的是：同一個分包中的頁面享有共同的預下載大小限額2M，限額會在工具中打包時校驗，所以不能把全部的分包頁面都配置到分包預加載的配置中，只配置主包頁面會跳轉的頁面便可。

獨立分包

獨立分包又是什麼呢？因爲從分包頁面啓動是，必需要依賴於主包的下載和注入，啓動速度會受到主包大小的制約，所以這就有了獨立分包，獨立分包在啓動分包頁面時，能夠獨立啓動而不須要依賴主包，這樣就能夠減小主包下載和注入的時間，一般狀況下咱們會將活動、廣告一類的具備獨立邏輯的功能代碼標記爲一個獨立分包，在分包頁面啓動時，能夠不依賴於主包啓動，只下載分包代碼進行注入。讓咱們來看一下獨立分包的加載流程是怎樣的：

首屏加載性能優化

首屏加載的體驗對小程序來講十分重要，那麼如何提高首屏加載性能呢？

1. 提早請求：異步數據數據請求不須要等待頁面渲染完成
2. 利用緩存：利用storage API對異步請求數據進行緩存，二次啓動時先利用緩存數據渲染頁面，再進行後臺更新
3. 避免白屏：先展現頁面骨架和基礎內容
4. 及時反饋：及時地對須要用戶等待的交互操做給出反饋，避免用戶覺得小程序沒有響應

渲染性能優化

要想提升渲染性能，就須要知道小程序如何作頁面渲染的，讓咱們先來看一個頁面渲染的流程圖：

js引擎和native均可以過js的計算或者data修改來對Webview發起繪製操做，可是對開發者來講最重要的就是js引擎和Webview之間的通訊，這通訊過程是一個跨進程通訊，是很是耗時的一個過程，咱們要提升渲染的性能，也就是減小這個跨進程通訊的時間，那麼怎麼去減小跨進程通訊的時間呢？

避免不當使用setData

1. 使用data在方法間共享數據，會增長setData傳輸的數據量，同時會增長頁面重繪的機率
2. data僅包括與頁面相關的數據
3. 使用setData傳輸大量數據，通信耗時與數據量正相關，頁面更新延遲可能形成更新開銷增長
4. 僅傳輸頁面中發生變化的數據，使用setData的特殊key實現局部更新
5. 後臺頁面進行setData搶佔前臺頁面的資源
6. 頁面切入後臺後的setData調用，延遲到頁面從新展現的時候執行

總結來講就是在data中只定義與頁面渲染相關的數據，其餘與頁面渲染無關的數據都定義成普通變量，在作setData操做時，儘可能只傳輸頁面渲染須要的數據，當頁面切換時，將後臺執行的setData操做銷燬，等到頁面從新展現的時候再執行。

避免不當使用onPageScroll

1. 只在必要的時候監聽pageScroll事件
2. 避免在onPageScroll中執行復雜邏輯
3. 避免在onPageSroll中頻繁調用setData
4. 避免頻繁查詢節點信息(SelectQuery),部分場景使用節點佈局相交狀態監聽(IntersectionObserver)替代

因爲onPageSroll事件監聽在處理js引擎和webview之間的通訊時也是一個跨進程通訊，所以在使用onPageScroll事件時，要注意以上的幾點內容，來進行相關的優化

使用自定義事件

在須要頻繁更新的場景下，自定組件的更新只在組件內部更新，不受頁面其餘部份內容複雜性影響，這樣也能夠在必定程度優化渲染性能

總結

這篇文章簡單的介紹了微信小程序性能優化的一些方法，還有不少我沒有介紹到方法就須要你們本身去探索總結了。但願你們看完這篇文章能對小程序性能優化有必定的認識，若是有錯誤或不嚴謹的地方，歡迎批評指正，若是喜歡，歡迎點贊收藏。