換個角度提高APP性能和質量

內容來源：2017年5月26日，餓了麼移動技術部iOS工程師高亮亮在「極光開發者沙龍JIGUANG MEETU—移動應用性能優化實踐」進行《新瓶舊酒——換個角度提高APP性能和質量的實踐之路》演講分享。IT 大咖（微信ID：itdakashuo）說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：2350 | 6分鐘閱讀

嘉賓演講視頻回顧及PPT連接：suo.im/1BzjC7

摘要

結合當下火熱的移動性能話題和 APM 系統，圍繞移動應用性能質量，談談如何避開傳統解決方案，將其餘技術領域的概念如迴流重繪，節流防抖、優雅降級以及漸進加強等，經過類比借鑑，做爲一個新的角度來思考質量提高問題，並靈活的運用到移動端，從而提高應用的性能，穩定性和可用性。

剛加入餓了麼的時候作了一年左右的業務線，主要是商務平臺。在更早以前作過web開發。最近恰好在開發web相關的項目，以爲不少東西各個端是共通的，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%。存在這樣的失敗率的網絡軟件，並且仍是每臺不停地發，能看到它發送的頻率。咱們是天網系統，是會開源的，服務器端的代碼也會開源的，只是服務不會去作。

今天基本上就講這麼多，謝謝你們！