小程序加載快慢的示例分析

這篇文章主要介紹小程序加載快慢的示例分析，文中介紹的非常詳細(xì)，具有一定的參考價值，感興趣的小伙伴們一定要看完！

首先，先從網(wǎng)絡(luò)請求network說起：

這里基本不關(guān)前端的事情，但是這也是優(yōu)化小程序的一大重點，后端響應(yīng)我們請求數(shù)據(jù)的速度影響了整個頁面的速度，所以，把它拿到第一位

請求超過300ms就已經(jīng)算是慢了，所以會影響總體速度。

建議：叫后端優(yōu)化接口，加快響應(yīng)速度。

還有，盡量減少無謂的請求，將數(shù)據(jù)合并到一個接口上，這樣可以方便操作，又可以節(jié)約資源，（前提不被后端責(zé)罵）

第二：圖片

圖片的話，對越用戶上傳的圖片的大小驗證一下，大于500K的拒絕就好了，盡量經(jīng)過壓縮在上傳服務(wù)器，如果文中含有大量的圖片的，盡量使用base64，轉(zhuǎn)換一下，可以減少點資源，

多圖片的情況況下，最好做一個懶加載技術(shù)。。。把一些體積較大的圖片資源改為使用線上資源。具體做法是將素材先上傳到 cdn，然后在小程序中直接使用線上圖片地址。

不懂得如何壓縮大小的可以看看這個https://blog.csdn.net/Young_Gao/article/details/88183442現(xiàn)成的

第三：控制小程序包 的大小　減小資源包體積

精簡第三方依賴  盡量少用第三方包，第三方的方有的會引用比較大的模塊，盡量節(jié)約吧，減少不必要的代碼...包括一些注釋掉的，它好像也會打包進(jìn)去，所以最好就刪除吧，

第四：關(guān)于調(diào)用第三方接口的問題

調(diào)用了第三方的接口速度會很慢——例如調(diào)用了騰訊的獲取定位，有時候需要1秒才能響應(yīng)，如果公司內(nèi)部有自己的接口和算法，還是調(diào)用自己的吧，哪怕是騰訊的api有時候他響應(yīng)的速度也會超過300ms,盡量少用

第五：關(guān)于setData

5.1. 頻繁的去 setData

在我們分析過的一些案例里，部分小程序會非常頻繁（毫秒級）的去setData，其導(dǎo)致了兩個后果：

• Android 下用戶在滑動時會感覺到卡頓，操作反饋延遲嚴(yán)重，因為 JS 線程一直在編譯執(zhí)行渲染，未能及時將用戶操作事件傳遞到邏輯層，邏輯層亦無法及時將操作處理結(jié)果及時傳遞到視圖層；

• 渲染有出現(xiàn)延時，由于 WebView 的 JS 線程一直處于忙碌狀態(tài)，邏輯層到頁面層的通信耗時上升，視圖層收到的數(shù)據(jù)消息時距離發(fā)出時間已經(jīng)過去了幾百毫秒，渲染的結(jié)果并不實時；

5.2. 每次 setData 都傳遞大量新數(shù)據(jù)

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

5.3. 后臺態(tài)頁面進(jìn)行 setData

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

第六：變量

每個頁面都有生命周期的銷毀階段，在這階段里面講存在data里面的變量全部釋放（不會返回這頁面的時候可以這樣做），你二次進(jìn)入的時候會比上次快上一點，但是不會很明顯，如果變量特別龐大的時候，這個時候就會顯得特別明顯，我做的都是二三十個變量。。。這個可以忽略

第七：緩存

相信每個頁面多多少少都會有復(fù)用的東西，如果有復(fù)用的變量，直接存到本地里面，然后等小程序整個關(guān)閉之后去本地儲存刪掉，

如果首頁加載的東西很多的，可以把整個頁面緩存下來，然后，再次進(jìn)這頁面的時候渲染緩存的，等接口數(shù)據(jù)都請求到了，在進(jìn)行靜默渲染，

希望我講的額能幫到大家，感謝你的觀看

以上是“小程序加載快慢的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道！