前言：
小程序已上線一段時間，評測結果性能良好，這個成績相對來說還是不錯，但是良好不是我們的目標，優秀才是。
依據提示，點擊查看性能體檢報告，列出了幾點待改善的意見，但是沒有具體細則。開發工具-調試器-Audis面板可進行詳細跳轉有優化
1、開發者工具進行評測
評測步驟：
微信開發者工具——》調試器——》Audits——》運行（操作）——》結束
點擊運行以後，儘可能多的對小程序進行操作，最好覆蓋全頁面和所有的交互動作。操作完成以後，點擊結束，出行評測結果以及評測的具體列表，需要優化的地方。
2、性能優化
2.1存在將未綁定在 WXML 的變量傳入 setData
詳解：setData 是小程序開發中使用最頻繁的接口，setData操作會引起框架處理一些渲染頁面的相關工作，一個未在頁面結構綁定的變量意味着與界面渲染無關，傳入不必要的setData會造成不必要的性能消耗。
常見的setData錯誤操作：
-
頻繁的去setData，（頁面不停的渲染，導致卡頓）
-
setData 都傳遞大量新數據。(渲染壓力太大，會出現延遲，頁面不顯示的數據不要傳遞)
-
所有的變量都定義在data屬性，進行setData操作，進行數據渲染（不需要渲染頁面的數據要定義在外面，定義成變量）
Demo解決實例：
如上圖，contentWidth肯定不是被綁定的數據，在給出的頁面路徑裏，找到這個變量，把他從data屬性裏面移出去，放在外面，定義成一個全局變量。
2.2 存在網絡圖片資源未開啓 HTTP 緩存控制
詳解：開啓 HTTP 緩存控制後，下一次加載同樣的圖片，會直接從緩存讀取，提升加載速度。
解決方案：片請求裏，服務器沒有返回cache-control頭部。一般對於資源請求建議加上緩存頭部，這樣下次訪問相同的資源就不用重新向服務發起請求。
2.3 存在可能沒有對請求進行緩存的情況
詳解：發起網絡請求總會讓用戶等待，可能造成不好的體驗，應儘量避免多餘的請求，比如對同樣的請求進行緩存 。
解決方案：對相同的請求進行緩存，但是如果遇到需要實時獲取動態數據的，就沒有辦法了
2.4 存在圖片太大而有效顯示區域較小
詳解：圖片太大會增加下載時間和內存的消耗，應根據顯示區域大小合理控制圖片大小 。
解決方案：例如，前端展示圖片大小爲100*100，那麼後臺維護圖片大小最好也是100*100，如果後臺圖片1000*1000，勢必增加下載時間和內存的消耗。
3、體驗優化
3.1存在可點擊元素的響應區域過小
詳解：我們應該合理地設置好可點擊元素的響應區域大小，如果過小會導致用戶很難點中，體驗很差，在前期設計的時候，應該儘量避免點擊元素相應區域過小的問題。來提高用戶體驗。
3.2頁面設計
詳解：文字顏色與背景色需要搭配得當，適宜的顏色對比度可以讓用戶更好地閱讀，提升小程序的用戶體驗。設計儘量符合小程序的設計原則。
小程序設計規範：
https://developers.weixin.qq.com/miniprogram/design/#%E9%87%8D%E7%82%B9%E7%AA%81%E5%87%BA最佳實踐優化
4、最佳實踐
4.1存在定時器未跟隨頁面回收
詳解：時器是全局的，並不是跟頁面綁定的，當小程序從一個頁面路由到另一個頁面之後，前一個頁面定時器應注意手動回收。
解決：離開頁面的時候，釋放定時器。
4.2 wxss 覆蓋率較低，存在未使用的樣式
詳解：們應該按需引入 wxss 資源，如果小程序中存在大量未使用的樣式，會增加小程序包體積大小，從而在一定程度上影響加載速度
解決：隨着業務的調整和優化，會有冗餘代碼和樣式文件，應該及時的刪除。
最後總結，上面的這些問題，是沒有經過小程序評審通過。評審的過程還會涉及到其他很多問題，以此類推，遇到問題解決，如果解決不了，去社區搜索提問。問題總會得到解決。