今天的工作已經做完，在馬上就進入五一假期的下班焦躁時刻，來個簡單的微信小程式開發規範總結。
1.小程式應避免出現任何 JavaScript 異常
出現 JavaScript 異常可能導致小程式的互動無法進行下去，我們應當追求零異常，保證小程式的高魯棒性和高可用性，相信這一點一般情況下都不會出現，需要注意的是程式碼測試中多場景的試錯。
2.合理控制圖片的大小
圖片太大會增加下載時間和記憶體的消耗，應根據顯示區域大小合理控制圖片大小。 一般情況下圖片較大的，我們應該都會選擇直接放在伺服器上，直接拿到地址，但是官方說這樣讀取的圖片：
存在網路圖片資源未開啟 HTTP 快取控制,這是個什麼意思，我也未完全弄懂。
3.小程式所有請求應響應正常
請求失敗可能導致小程式的互動無法進行下去，應當保證所有請求都能成功。然而，請求成功只是第一步，還可能存在的問題就是請求的耗時太長、存在短時間內發起太多的請求這樣的情況，一方面是後臺人員的介面寫的爛，一方面就是需求使然（技術半吊子，還想安全的產品經理會有這種讓你去指定地方請求的情況），比如在阿里雲OSS儲存的一些json資料。。。。
4.避免setData的資料過大且避免setData的呼叫過於頻繁。
由於小程式執行邏輯執行緒與渲染執行緒之上，setData的呼叫會把資料從邏輯層傳到渲染層，資料太大會增加通訊時間. setData介面的呼叫涉及邏輯層與渲染層間的執行緒通過，通訊過於頻繁可能導致處理佇列阻塞，介面渲染不及時而導致卡頓，應避免無用的頻繁呼叫.
5.避免將未繫結在 WXML 的變數傳入 setData
setData操作會引起框架處理一些渲染介面相關的工作，一個未繫結的變數意味著與介面渲染無關，傳入setData會造成不必要的效能消耗。 這一條我想是很多開發人員在初次接觸小程式開發的時候都會犯的一個錯誤吧。因為剛開始的時候由於這種setData的語法，讓我們忘了還有全域性變數的使用，於是會經常出現使用Page中定義的data做中間過渡。
6.wxss 覆蓋率較高，較少或沒有引入未被使用的樣式
我們應該按需引入 wxss 資源，如果小程式中存在大量未使用的樣式，會增加小程式包體積大小，從而在一定程度上影響載入速度。 這個也是比較常見的一種不規範，寫了很多CSS樣式，很多不用的就留來了程式碼裡面，越來越多，所以在編寫程式碼過程中，儘量去對每一行程式碼（特別是自己寫的）瞭如指掌。
7.避免首屏時間太長的情況
首屏時間是指使用者開始看到第一屏的內容的時間，首屏時間太長會導致使用者長時間看到的都是白屏，會一直等待有意義的內容展示出來。出現這一情況，應仔細檢查這個過程都有哪個操作，一般來說，可能是請求資料的時間太長，或者是一次渲染的資料太大導致渲染時間太長。
這些東西是我感覺比較常見且容易修改的，其它還存在一些規範，不妨開啟微信開發者工具，點選
Audits,對你寫的程式碼進行一個測試，測試結果會讓你很好的處理自己的程式碼。That's really cool!