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