換個角度提升APP效能和質量

餓了麼的使用者端不會出現高峰期的現象，訂餐時間都選在中午之前的一到兩個小時，量級非常大。我們內部有其他很多業務線，針對與配送人員和商戶的客戶端，還有供應鏈，以及內部的溝通工具。我們內部會簡單地做分析優良中差評做分級。

最早是以崩潰來算，但後來崩潰在後期並不是特別看重。崩潰率高包括ANR多這一類肯定是差，只能輪為可用的階段。而好用的階段除了UPM做指導性的工作，還要做非常深化的業務，我們一個框架部對外一直在輸出各種SDK，供內部使用。

根據裝置型別，除了在跑移動端，還有PC以及外圍。PC基本上沒有跑流量、耗電量的問題。結合主要的業務場景，我們面臨的問題是使用者端停留在使用者手上的時間很短暫，而商戶端和配送端一直開著APP。對配送人員來講優先考慮的是耗電問題，耗電問題在移動端的體現有兩點，網路和定位。GPS定位非常耗電，不停定位還要提升精度，是對物流端APP最大的挑戰。其次對商戶端考慮的是網路的優化和效能，本身網路環境是相對比較好的，我們主要提升它的APP到達和業務方面。

我們經常遇到的迴流和重繪問題。這個問題很經典，從最初的頁面載入到最後繪製在螢幕上。迴流是在流失佈局下，參照元素的佈局座標一旦發生了改變，那所有依賴它的元素都要重排，重新計算佈局位置的過程，尤其消耗UPC。

重繪是不發生重排的情況下重新佈局，現在的GPU都那麼強大，效能並不是瓶頸。

下面是我們處理商品訂單的問題，訂單當時是檢測到有很多使用者的投訴，訂單改版之後效能特別差。效能主要是卡在CPU上，CPU在計算的時候是非常慢的。

最終我們優化的結果非常好。雖然它也要做佈局計算，但在快速滾動的時候幀率是達到非常滿意的情況，基本上接近於60幀。

前端在滾動頁面的時候需要做一些效果，在滾動時監聽。在很高的頻率下不停地設計元素的位置，會導致滾動時的卡頓問題。而前端用的解決方法就是節流。

我們的做法還應用於正在開發的APM臺。我們有一個資料收集的問題，資料收集的數額大，頻次也快，使用者的軌跡分析的資料很多。我們在伺服器傳送資料的時候如果失敗的話，基本上為了保證資料傳輸過去，對於非實質性資料一定要把它傳過去，就存在了自動重試的問題。我把它定位為“黃金”重試節流策略。

接下來漸進增強和優雅降級。Graceful Degradation是對於出現某種情況不停地做減法。對於外圍來講，瀏覽器的碎片化特別重複，安卓端也有這種問題。如果它的功能不可用，就把這個功能減掉。還有漸進式增強，依賴瀏覽器IE6，設計一套基本的功能能在上面用，不停地做架構，直到它表現的非常好。利用更優元件，三方作為備選。操作效率會出現問題，操作效率和速度是隨著失效部件的增加逐漸下降的。我的設計就是這樣的框架，很簡單的，先建長連，可控可靠，存在異常就降級。

最後講法則。零崩潰零錯誤等於好用；啟動時間Main後比Main前重要；二進位制大於資源，耗件優化，硬體大於軟體。

關於耗電問題。手機裝置在通訊的時候處於休眠期，當你有需求的時候會自動開啟活躍期，活躍期和停歇期切換頻繁的話，電量就掉的非常快。我們的弱網判斷是針對與它的響應時間，我們自己做的網路框架可以知道所有的DSR包括資料時間。

我們拿來之後發現超時間，網路響應時間太長。這種情況下會做節流層，要麼不傳資料，要麼降低傳送頻率。合理的快取和批量的傳輸。大家有時候也會要求實質性非常高的資料往後端發，使用者點選一搜就把資料轉換成事件，可這樣的情況下瞬間傳送伺服器還是會崩潰。我們做一個簡單的調整，就是做忍受值。我們認為資料從生成勞動傳送到傳輸，傳輸的時候查過最慢的DNS解析是80秒，是非常非常差的網路外掛。我們認為有忍受值，目前設定的單位是60秒鐘，60秒鐘的資料都認為它是有實時屬性、架構的才往後端傳。一旦出超過60秒，就從傳輸佇列去掉。對我們傳輸的間隔也會調整，除了一系列網路的節流優化，加上這套實施策略，極大地提升了網路的效率和節點問題。

最終我們還會發現通過APM平臺會發現主機解析率特別高的，能達到86%。存在這樣的失敗率的網路軟體，而且還是每臺不停地發，能看到它傳送的頻率。我們是天網系統，是會開源的，伺服器端的程式碼也會開源的，只是服務不會去做。

今天基本上就講這麼多，謝謝大家！