Android应用性能优化实践

  1. 云栖社区>
  2. 博客>
  3. 正文

Android应用性能优化实践

云学习小组 2015-12-13 13:48:49 浏览8409
展开阅读全文


何杰: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

全局监控 -- 用户反馈

用户反馈分析,用户反馈是一个非常好的渠道。

  预警机制

  用户分类

  功能分类

  纵向对比

 图1

针对用户反馈进行很多方面的筛选,资讯类的,网页类的,性能相关的等所有信息进行一个整合,会有对应的负责人专门负责,比如像性能方面的用户反馈如图1,全部集于一个邮件发过来,我们会去关注,发现规律,通过用户的分类对手机的各个参数作聚合,也对业务各个模块反馈卡顿的占比是什么样的,指标高的对我们就是一个预警。

全局监控—anr日志分析

Anr信息很全,有所有线程的调用站,我们肯定能够知道当前主线程式卡在哪里,会有精确的定位,数据量化,把实验室的研究方式拿到线上来。

 图2 anr日志分析

全局监控 -- Strict Anr

 方案说明

  vs Anr (主线程超时,5s -> 1s)

  暴露更多问题

  精确定位问题

  方便用户联调

 图3 Strict Anr日志分析

所有的调用栈去写一个脚本,全部用图形化的方式展现出来,显示各个帧的占比,再去做一个分析,针对性的解决问题。

全局监控 -- Looper Hook

方案说明

  监控系统消息循环

  计算消息耗时

  定位耗时点(msg.what or msg.callback)

 

图4Andriod的消息循环

 图5耗时点分析

从图5看,发现卡顿点就能知道handler是谁,如果是一个message,可以知道message的ID是多少,这样我们就能准确的精确度我们自己代码的一个代码段。

 

 图6

从图6数据上看,红色和蓝色一个是2s的卡顿率,一个是1s的卡顿率,我们在灰度的版本上去搜所有的消息循环里耗时超过2s和1s的数据,把数据整理下,每天的卡顿的用户数除以UC每天的日活数,得到每天有多少用户是在卡顿这样一个卡顿率的指标,进行优化。

 

技术成果 -- 问题回顾

200+项技术优化

举例说明

  下载界面展开卡顿(分段加载)

  二维码界面展现慢(延迟加载,先出界面,再初始化相机)

  文件管理转屏卡顿(缓存复用,缓存View,转屏只重布局)

  启动完成后操作卡(线程抢占,低优先级后台线程+队列)

  视频播放控制卡顿(API兼容,异步化)

  获取网络代理卡顿(IPC异常,异步DNS+缓存)

  从第三方返回卡死(固件问题,Shield Activity)

  网页滑屏操作卡顿(GPU加速)

  So加载/Jni注册卡(异步加载+时序控制)

  SharedPreference(主线程IO,commit -> apply)

  安全软件事件拦截(沟通反馈。。。)

  ...

 

经验推广

    禁止:

  主线程文件IO(标记文件读除外)

  主线程耗CPU操作

  主线程同步IPC调用

推荐:

  异步化:产品及程序设计,预加载 + 闲时加载 + 按需加载

  线程管理:线程数限制 + 任务队列,非主线程优先级调低

  压力测试

  防御式编程

  主路径自动化数据监控

  全局性能监控

延伸:

精确化 & 自动化:用户反馈,卡顿日志

新监控方案:Api Hook

新优化方向:卡顿率 -> 帧率,低端机优化

 

                                                                                                                      PPT下载地址:http://club.alibabatech.org/resource_detail.htm?topicId=181

网友评论

登录后评论
0/500
评论
云学习小组
+ 关注