出現 JavaScript 異常可能致使小程序的交互沒法進行下去,咱們應當追求零異常,保證小程序的高魯棒性和高可用性,相信這一點通常狀況下都不會出現,須要注意的是代碼測試中多場景的試錯。小程序
圖片太大會增長下載時間和內存的消耗,應根據顯示區域大小合理控制圖片大小。 通常狀況下圖片較大的,咱們應該都會選擇直接放在服務器上,直接拿到地址,可是官方說這樣讀取的圖片:
存在網絡圖片資源未開啓 HTTP 緩存控制
,這是個什麼意思,我也未徹底弄懂。微信小程序
請求失敗可能致使小程序的交互沒法進行下去,應當保證全部請求都能成功。然而,請求成功只是第一步,還可能存在的問題就是請求的耗時太長、存在短期內發起太多的請求這樣的狀況。緩存
因爲小程序運行邏輯線程與渲染線程之上,setData的調用會把數據從邏輯層傳到渲染層,數據太大會增長通訊時間. setData接口的調用涉及邏輯層與渲染層間的線程經過,通訊過於頻繁可能致使處理隊列阻塞,界面渲染不及時而致使卡頓,應避免無用的頻繁調用.服務器
setData操做會引發框架處理一些渲染界面相關的工做,一個未綁定的變量意味着與界面渲染無關,傳入setData會形成沒必要要的性能消耗。 這一條我想是不少開發人員在初次接觸小程序開發的時候都會犯的一個錯誤吧。由於剛開始的時候因爲這種setData的語法,讓咱們忘了還有全局變量的使用,因而會常常出現使用Page中定義的data作中間過渡。微信
咱們應該按需引入 wxss 資源,若是小程序中存在大量未使用的樣式,會增長小程序包體積大小,從而在必定程度上影響加載速度。 這個也是比較常見的一種不規範,寫了不少CSS樣式,不少不用的就留來了代碼裏面,愈來愈多,因此在編寫代碼過程當中,儘可能去對每一行代碼(特別是本身寫的)瞭如指掌。網絡
首屏時間是指用戶開始看到第一屏的內容的時間,首屏時間太長會致使用戶長時間看到的都是白屏,會一直等待有意義的內容展現出來。出現這一狀況,應仔細檢查這個過程都有哪一個操做,通常來講,多是請求數據的時間太長,或者是一次渲染的數據太大致使渲染時間太長。微信開發
這些東西是我感受比較常見且容易修改的,其它還存在一些規範,不妨打開微信開發者工具,點擊
Audits
,對你寫的代碼進行一個測試,測試結果會讓你很好的處理本身的代碼。That's really cool!框架