關於小程式的載入快慢這可是一大學問，自古以來性能都是重點，所以下麵我淺談一下自己遇到的問題和解決方法吧 首先，先從網路請求network說起： 這裡基本不關前端的事情，但是這也是優化小程式的一大重點，後端響應我們請求數據的速度影響了整個頁面的速度，所以，把它拿到第一位 請求超過300ms就已經算是慢 ...
關於小程式的載入快慢這可是一大學問，自古以來性能都是重點，所以下麵我淺談一下自己遇到的問題和解決方法吧
首先，先從網路請求network說起：
這裡基本不關前端的事情，但是這也是優化小程式的一大重點，後端響應我們請求數據的速度影響了整個頁面的速度，所以，把它拿到第一位
請求超過300ms就已經算是慢了，所以會影響總體速度。
建議：叫後端優化介面，加快響應速度。
還有，儘量減少無謂的請求，，將數據合併到一個介面上，這樣可以方便操作，又可以節約資源，（前提不被後端責罵）
第二：圖片
圖片的話，對越用戶上傳的圖片的大小驗證一下，大於500K的拒絕就好了，儘量經過壓縮在上傳伺服器，如果文中含有大量的圖片的，儘量使用base64，轉換一下，可以減少點資源，
多圖片的情況況下，最好做一個懶載入技術。。。把一些體積較大的圖片資源改為使用線上資源。具體做法是將素材先上傳到 cdn，然後在小程式中直接使用線上圖片地址。
不懂得如何壓縮大小的可以看看這個https://blog.csdn.net/Young_Gao/article/details/88183442現成的
第三：控制小程式包 的大小 減小資源包體積
精簡第三方依賴 儘量少用第三方包，第三方的方有的會引用比較大的模塊，儘量節約吧，減少不必要的代碼...包括一些註釋掉的，它好像也會打包進去，所以最好就刪除吧，
第四：關於調用第三方介面的問題
調用了第三方的介面速度會很慢——例如調用了騰訊的獲取定位，有時候需要1秒才能響應，如果公司內部有自己的介面和演算法，還是調用自己的吧，哪怕是騰訊的api有時候他響應的速度也會超過300ms,儘量少用
第五：關於setData
5.1. 頻繁的去 setData
在我們分析過的一些案例里，部分小程式會非常頻繁（毫秒級）的去setData，其導致了兩個後果：
- Android 下用戶在滑動時會感覺到卡頓，操作反饋延遲嚴重，因為 JS 線程一直在編譯執行渲染，未能及時將用戶操作事件傳遞到邏輯層，邏輯層亦無法及時將操作處理結果及時傳遞到視圖層；
- 渲染有出現延時，由於 WebView 的 JS 線程一直處於忙碌狀態，邏輯層到頁面層的通信耗時上升，視圖層收到的數據消息時距離發出時間已經過去了幾百毫秒，渲染的結果並不實時；
5.2. 每次 setData 都傳遞大量新數據
由setData的底層實現可知，我們的數據傳輸實際是一次 evaluateJavascript 腳本過程，當數據量過大時會增加腳本的編譯執行時間，占用 WebView JS 線程，
5.3. 後臺態頁面進行 setData
當頁面進入後臺態（用戶不可見），不應該繼續去進行setData，後臺態頁面的渲染用戶是無法感受的，另外後臺態頁面去setData也會搶占前臺頁面的執行。
第六：變數
每個頁面都有生命周期的銷毀階段，在這階段裡面講存在data裡面的變數全部釋放（不會返回這頁面的時候可以這樣做），你二次進入的時候會比上次快上一點，但是不會很明顯，如果變數特別龐大的時候，這個時候就會顯得特別明顯，我做的都是二三十個變數。。。這個可以忽略
第七：緩存
相信每個頁面多多少少都會有復用的東西，如果有復用的變數，直接存到本地裡面，然後等小程式整個關閉之後去本地儲存刪掉，
如果首頁載入的東西很多的，可以把整個頁面緩存下來，然後，再次進這頁面的時候渲染緩存的，等介面數據都請求到了，在進行靜默渲染，
希望我講的額能幫到大家，感謝你的觀看
