383
Android應用性能優化實踐
何傑：UC優視Android技術負責人，專注Android平台應用開發方向；主導過UC瀏覽器的性能、內存、穩定性、網絡優化，增量升級技術攻關，插件平台搭建；目前負責Android UC瀏覽器的架構優化。
Android應用的卡頓問題非常突出，所有用戶都能感覺得到卻又很難做量化卡頓的嚴重程度，過去的做法隻是零星地發現和解決一些小點。DAU超億級的 UC瀏覽器在卡頓優化的過程中建立了一套衡量卡頓嚴重性的數據指標與監控分析機製，並藉此有針對性地落實了200+個性能優化點。下麵會介紹卡頓監控與分析的方法、常見的卡頓案例與原因。以下分享精彩內容。
背景 -- Android應用卡頓產生原因
安卓係統低效—安卓沒有自己獨立的渲染線程、同步接口、廣播機製；
運行環境惡劣—後台進程可能幾十甚至上百個同時跑、安全軟件給性能帶來一些挑戰；
低端機占比高—低內存、弱GPU、IO瓶頸；
產品考慮不足—功能定義簡陋，不一定會把整個閉環想的很清楚，功能堆積嚴重；
技術考慮不足。
問題—用戶反饋應用卡頓，怎麼辦？
複現難—用戶描述模煳、不穩定出現，複現問題難。
定位難—不同機型、固件、係統狀態表現不一，不確定性非常大，程序細節多、可疑麵廣。
衡量難—卡頓嚴重程度難以量化，無法掌握優化度，卡頓問題不便分類。
思路
卡 vs 頓，卡為主，頓為輔。卡和頓沒有一個明顯的界限，大部分頓的問題當環境足夠惡劣時就會表現為卡。所以抓住卡，就能解決很多問題。
打點統計 vs 全局監控：對於上百萬的代碼來說，做全局監控是很難的，所以我們定了一個短期目標：主路徑性能保障，打點統計；一個長期目標：整體的卡頓優化，全局監控。
線下分析 vs 線上監控：線下分析：實驗室調試去複現一個問題，精確定位、粒度細；線上監控：指標衡量、粒度粗。
方案
工具應用：TraceView，StrictMode，Systrace，Overdraw。隻能做調試用，無法去做一個更全麵的分析和監控。
打點統計：
– 耗時（針對我們的主路徑，啟動速度，退出速度，轉頁時間，多窗口的滑屏時間，啟動時間、響應速度）。
– 多窗口的滑屏幀率。
全局監控：做卡頓優化新的思路。
– 用戶反饋分析
– Anr日誌分析
– Strict Anr
– Looper Hook
全局監控 -- 用戶反饋
用戶反饋分析，用戶反饋是一個非常好的渠道。
– 預警機製
– 用戶分類
– 功能分類
– 縱向對比
最後更新：2017-04-01 13:37:06