使用audits(除錯工具)
體驗評分：
避免太大而有效顯示區域較小，浪費流量和降載入速度；
網路資源應開啟 http 快取控制，減少請求次數；
避免請求的耗時太久，應優化好伺服器處理時間、減小回包大小，可以使用觸底載入；
避免短時間內發起太多的請求，否則會觸發瀏覽器並行載入的限制，可能導致載入慢，使用者一直處理等待。應該合理控制數量，可考慮使用雪碧圖技術或在螢幕外的使用懶載入；
避免短時間內發起太多的請求，否則會觸發小程式並行請求數量的限制，同時太多請求也可能導致載入慢等問題，應合理控制請求數量，甚至做請求的合併等；
避免 setdata 的資料過大，不能超多1m, 由於小程式執行邏輯執行緒與渲染執行緒之上，setdata的呼叫會把資料從邏輯層傳到渲染層，資料太大會增加通訊時間;
避免 setdata 的呼叫過於頻繁, setdata介面的呼叫涉及邏輯層與渲染層間的執行緒通過，通訊過於頻繁可能導致處理佇列阻塞，介面渲染不及時而導致卡頓，應避免無用的頻繁呼叫;
避免將未繫結在 wxml 的變數傳入 setdata,可以放在外面定義，減少setdata引起的效能消耗；
避免執行指令碼的耗時過長的情況，耗時過長會讓使用者覺得卡頓，體驗較差，出現這一情況時，需要確認並優化指令碼的邏輯 ；
對網路請求做必要的快取以避免多餘的請求，對同樣的請求進行快取，減少使用者的等待時間；
所有資源請求都建議使用 https，安全不易被篡改；
避免使用廢棄的介面；
定時器跟隨頁面**，當頁面被銷毀或隱藏時，應**定時器；
避免過大的 wxml 節點數目，
少於 1000 個 wxml 節點；
節點樹深度少於 30 層；
子節點數不大於 60 個。
避免首屏時間太長的情況，可以進行分包處理；
合理設定可點選元素的響應區域大小，不如按鈕不能太小；
避免使用 css ':active' 偽類來實現點選態，:active的效果不好，在滾動或滑動時，點選態並沒消失；應使用hover-class替代；
應讓按原圖寬高比例顯示，
否則可能導致歪曲，不美觀，甚至導致使用者識別困難。可根據情況設定 image 元件的 mode 屬性，以保持原圖寬高比；
滾動區域可開啟慣性滾動以增強體驗,
在安卓下預設有慣性滾動;
而在 ios 下需要額外設定 `-webkit-overflow-scrolling: touch` 的樣式 ;
執行體驗評分（start），避免過大的 wxml 節點數目然後所有頁面所用功能進行操作，操作完後（stop）,audits會列印出效能、體驗、最佳實踐進行評分和給出優化建議。
根據audits給出優化建議和定位，來優化。
優化程式效能
編寫高效程式需要兩個活動 第一，我們必須選擇一組最好的演算法和資料結構 第二，我們必須編寫出編譯器能夠有效優化以轉換成高效可執行 的源 這裡，我們主要講述後者。首先，我們討論一下為什麼要編寫高效程式。不難想象，如果本來要用 天執行完的程式，經過優化只需要 天就可執行完，這是一件多麼令人振奮的 事啊。...
優化程式效能
l 消除迴圈的低效率 n 對於迴圈中的過程呼叫盡量移出迴圈外,例如 nfor i 0 i strlen s i strlen 函式為線性增長 在字串長度很大時 很消耗系統資源 n 減少不必要的儲存器引用,將儲存器引用儲存在臨時變數中.l 處理器優化 即充分利用儲存器流水線操作的吞吐量 n 迴圈展開,...
優化程式效能
研究彙編 是理解編譯器以及產生的 會如何執行的最有效的手段之一。編譯器優化 的限制 1 程式設計中存在 儲存器別名使用 的問題。編譯器必須假設不同的指標可能指向儲存器中相同的位置。2 函式呼叫 簡略了。具體看書 基本的編碼原則 效能大幅度提公升 優化程式效能的一些方法 1 將除錯完的程式完成編譯器級...