極光開發者沙龍 之 移動應用性能優化實踐 【一】舊酒新瓶——換個角度提高 App 性能與質量

舊酒新瓶——換個角度提高 App 性能與質量

　　主講人：高亮亮　---   餓了麼移動技術部高級iOS工程師，負責餓了麼商家版iOS APP開發，對架構和系統底層有深刻研究，擅長移動性能分析，trouble shooting，iOS 逆向編程。

　　主講時間：2017-05-26

　　

 

　　主講內容：

　　一、性能與質量概述：

　　二、「新」技術概念的介紹與實踐：

　　三、違反常規的「真理」：

　　

　　1、性能與質量概述：

　　• 應用分級以及與性能質量的關係

　　• 根據設備特色設計提高方案

　　• 結合主要業務場景制定優先級 

 

　　迴流(Reflow)/ 重繪(Repaint)

　　

　　• 迴流:流式佈局下，因爲參照元素佈局框發生變化而致使的佈局從新計算。

　　• 重繪:元素佈局不發生變化的狀況下，從新渲染視圖。

 

　　案例重現：

　　

　　• 單張訂單視圖做爲重用的基本單元

　　• 視圖層級複雜，且採用動佈局技術

　　• 視圖不固定，且存在強依賴關係

　　• 商品列表在滾動時產生嚴重回流

 

　　2、解決方案

　　• 調整視圖關係，合理利用重用機制，避免滾動時迴流

　　• ADK 方案，異步計算佈局並緩存，細膩的線程控制

　　

 

　　節流(Throttle)/ 防抖(Debounce)

　　

　　案例重現

　　失敗重試致使的 Self-DDoS　　

　　• 在保證服務前提下的自動重試，且固定重試頻率

　　• 忽略錯誤類型，「一刀切」式的 DFF 設計

　　• 重試周期同步，從而致使惡性循環

 

　　解決方案：

　　• 指數回退 —— 固定重試間隔加倍

　　• 添加抖動 —— 隨機抖動間隔，避免鎖定同步週期

　　• 標記重試 —— 優先處理高重試請求

　　• 「黃金」重試節流策

　　

　　擴展運用

　　• 實時查詢防抖 —— 減小網絡請求

　　• 事件響應節流 —— 避免冗餘資源消耗

　　• 界面渲染節流 —— 避免大量 CPU 消耗

 

　　漸進加強(PE)/ 優雅降級(GD)
　　

 

　　 案例重現：

　　基於三方服務的推送系統

　　• 同業務對推送的實時性、可靠性要求高且存在差別

　　---➡ 利用更優的組件做爲首選，三方做爲備選

　　• 三方服務不可控，且在實時性、可靠性上都存在不足

  ---➡ 操做的效率和速度隨着失效部件的增長逐漸降低

　　解決方案：

　　

 

　　Taco 混合推送框架

設備	平臺	系統	先後臺	發送數	發送成功數	接收消息數	到達率
紅 Note3	Android	MIUI 8	前臺(鎖 屏)	300	297	267	89.9%
錘	Android	Smartisan OS 3.2.5	後臺( 鎖 屏)	300	298	250	83.9%
Nexus5	Android	6.0	後臺(鎖 屏)	300	296	234	79.1%
iPhone 6	iOS	iOS 9.1	前臺( 鎖 屏)	300	299	299	100%
iPhone 4s	iOS	iOS 8	前臺( 鎖 屏)	300	296	178	60.1%

 

　　穩 => 快 => 省，普適法則

　　• 0崩潰&0錯誤!=好 

　　• 啓動時間:main() 後 main() 前重要

　　• 包體積優化: 進制 > 資源

　　• 耗電優化:硬件 > 軟件

 

　　0 崩潰 & 0 錯誤 != 好用

　　

　　

　　0 崩潰 & 0 錯誤 != 好用

　　

 

　　啓動時間:main() 後 main() 前重要

　　• main() 前優化點

　　　　‣ dylib loading —— 多爲系統動態庫，廣泛使用靜態庫

　　　　‣ rebase / binding —— 佔比低，減小 Class 等行爲違反軟件工程原則

　　　　‣ Objc Setup —— 受工程量影響，盲目優化違反工程原則

　　　　‣ Initializer —— + load 優化，影響工程設計

　　• main() 後優化點

　　　　‣ 屏渲染優化

　　　　‣ 避免主線程阻塞

　　　　‣ 關鍵路徑線程優化

 

　　　　包體積優化: 二進制 > 資源　　　　　　　　　　　　　　　　　耗電優化:硬件 > 軟件

　　　　　

 

　　耗電優化:硬件 > 軟件