前言


Android开发中卡顿问题一直是个比较棘手又重要的问题,严重影响用户体验;卡顿是人的一种视觉感受,比如我们滑动界面时,如果滑动不流畅我们就会有卡顿的感觉,这种感觉我们需要有一个量化指标,在编程时如果开发的程序超过了这个指标我们认为其是卡顿的

当用户在使用我们应用的时候,很多问题是很难被及时发现的,比如内存占用高,就容易造成app卡顿现象,一旦发生卡顿就会被用户直观的感受到,所以app卡顿是很影响用户体验的,所以优化一直是我们要考虑的重要部分,正文会介绍“优化卡顿的工具—友盟+u-apm”及几种优化工具

卡顿分析

谷歌官方对于流畅度的优化也是高度重视的,有界面渲染三核心Vsync、Triple Buffer和Choreographer

而对于开发者来说,卡顿的问题很难定位,发生问题的原因过于复杂,比如:代码问题、内存问题、绘制问题以及IO操作等等;而且线上发生的卡顿问题在线下我们很难发现,因为这种情况大多与用户用的系统环境有很大的关系,因此我们需要在用户反馈卡顿问题的时候,并记录下用户使用的场景等,这样的过程比较繁琐。要解决这些问题可以借助工具,友盟+u-apm应用性能监控平台这款监测工具,就可以帮助开发者查找和定位app出现问题,解决这些问题从而使用户有个良好的体验感!

如何衡量卡顿

FPS的高低不能准确的反映应用的流程度,只有有更新的时候才刷新界面。当界面没有变动的时候,手机不需要对界面进行更新,所以此时的FPS会很低,如果1秒钟内都没有变动那么FPS=0

所以我们需要利用其他方式来衡量应用的流程度,比如可以利用丢帧数来衡量。单位时间内丢帧数可以反映出应用是否流程,不丢帧是终极目标,但每秒丢帧在6-7帧左右可以接受,如果丢10帧以上就需要优化了;对于开发人员来说,会使用一些工具(比如:友盟+U-APM)找出卡顿比较集中的地方,找出原因,消除或减弱卡顿

为何是16ms/为何每秒60帧


android系统每隔16ms绘制一帧UI且要在16ms内完成,( 1秒 / 0.016帧每秒 = 62.5帧/秒 )差不多每秒更新60次;这是因为我们大脑和眼睛一般看24Fps的画面就已经是连续的运动了,看60Fps的画面更看不出端倪,但是60帧可以表达出更加绚丽多彩的内容

一旦没及时绘制,就会出现掉帧问题,也就是常说的卡顿。这是因为绘制的东西太多的话,CPU、GPU处理不及时

当然了,设备性能越好,处理能力越强,卡顿会越少,玩游戏的电脑配置高也是出于这方面考虑

卡顿产生的原因

核心:分析在16ms中我们的应用做了什么工作,那些工作阻止我们在16ms时更新界面

通常情况下,在16ms中我们有那些工作需要处理。而实际开发中我们还加入交互、业务处理等工作,这些工作都需要在16ms中处理完成。对于开发人员来说,需要有一个工具,很直观的帮助我们判断出那些工作占用了多少时间

通用优化流程

常规做法

● 没有用的父布局——没有背景绘制或没有大小限制的父布局,不会对界面效果产生任何影响;特别是进来的布局,很容易产生问题;可以通过标签替代

● 在布局层次一样的情况下,建议使用LinearLayout代替RelativeLayout。使用LinearLayout导致的层次变深,可以使用RelativeLayout进行替换。同样的界面我们可以使用不同的方式去实现,选择一个层级最少的方案

● 不常用的UI被设置成了GONE,尝试使用代替。去掉多余的背景颜色,减少过渡绘制,对于有多层背景色的布局来说,留最上面的一层即可;谨慎使用alpha,如果后渲染的元素有设置alpha值,那么这个元素就会和屏幕上已经渲染好的元素做blend处理,这样会导致不少性能问题,特别是出现在列表的Item中

对于使用Selector当背景的布局,可以将normal状态的color设置为透明。我们不能因为提高性能而忽略了界面需要达到的效果(平衡Design与Performance)

以上就是Android卡顿产生的原因和优化流程,那么具体如何规避卡顿,这就要求开发者在平时的开发中养成良好的代码习惯,书写高质量代码

优化工具

CPU Profile

目前Android Studio自带了CPU Profiler工具,它可以以图形化的形式展示执行的时间、调用栈等信息;收集的信息比较全面,包含了所有线程;但是由于其收集信息全面,导致了运行时内存开销严重,App函数整体运行都会变慢,可能会带偏我们的优化方向

Systrace

Systrace它是轻量级的框架,而且开销小,可以直观反映CPU的利用率而且右侧alter可以针对一些问题给出相关的建议; 比如绘制慢或者GC频繁等

Android2.3引入的一个工具类:严苛模式。是一种运行时检测机制。可以帮助开发人员检测代码当中不规范的问题;StrictMode主要检测线程策略和虚拟机策略

线程策略包括

● 自定义的耗时调用,detectCustimSlowCalls

● 磁盘读取操作,detectDiskReads

● 网络操作,detectNetwork

虚拟机策略

● Activity泄漏,detectActivityLeaks

● Sqlite对象泄漏,detectLeakedSqlLiteObjects

● 检测实例数量,setClassInstanceLimit

自动化检测卡顿方法

CPU Profiler 和 Systrace 都是适合线下使用的,无法带到线上。那我们如何做到线上监测卡顿呢?

我们都知道一个进程中只有个Looper对象,我们通过查看Looper源码发现,在其loop方法中的死循环中有个mLogging对象,在执行的时候打印了一个Dispatching to日志,执行完成的时候有打印了一个Finished to日志

友盟U-APM性能检测工具

以上介绍的卡顿检测的方法并不完美,那么有没有一款工具能实时检测App卡顿问题呢?答案是有的。这里介绍一款带有卡顿检测和分析功能的工具-友盟U-APM性能检测工具,它的卡顿分析功能可以实时检测卡顿发生代码位置、卡顿的发生时间及卡顿次数等等,还可以进行告警设置,通过钉钉或者邮件的方式在第一时间把问题反馈给开发人员,再也不用担心找不到问题代码的位置了

另外,友盟+搭载在U-APM应用性能监控平台上推出了友盟+云真机服务,为移动开发者提供了灵活地测试操作界面,支持ADB调试、WEB远程调试、扫码、抓包、虚拟定位等测试功能,并提供了测试报告供开发者后续查看。提供了海量Android、iOS真机,通过资源集中管理,合理调度分配,为开发者提供发版前测试、发现线上问题后复现等场景使用,助力开发者平衡成本与需求,提升研发效率

友盟+u-apm

● 开发app的性能目标就是保持60fps,这意味着每一帧你只有16ms≈1000/60的时间来处理所有的任务;Android系统每隔16ms发出VSYNC信号,触发对UI进行渲染,如果每次渲染都成功,这样就能够达到流畅的画面所需要的60fps;友盟+U-APM就是一款对Android卡顿进行分析的平台,下面来说说如何借助友盟+这个平台对Android进行卡顿分析及优化的

● 友盟+U-APM应用性能监控平台,通过轻量级的集成接入即可拥有实时、可靠、全面的应用崩溃、ANR、自定义异常等捕获能力,及卡顿、启动分析、内存分析、网络分析等性能监测能力,支持多场景、多通道智能告警监测,帮助开发者高效还原异常、卡顿用户的访问路径和业务现场,缩短故障排查时间

● 提供云真机测试能力,助力开发者从研发测试质量验收到线上问题复现排查,保障应用品质,提升测试效率;在云真机测试期间自动采集崩溃信息,提供详尽的崩溃报告协助筛查,真正实现监控测试全流程深度打通

结语

作为开发人员,在平时的开发中要养成良好的代码习惯,写完代码后也可以先使用友盟U-APM这款工具进行监测,毕竟以防万一嘛~开发者提前监测到问题,比如:卡顿、内存、app崩溃、闪退等等,在借助友盟这款工具针对监测出的问题去解决,总要比用户使用后一系列的吐槽强,这样也不至于降低用户的体验感!

技术是无止境的,你需要对自己提交的每一行代码、使用的每一个工具负责,不断挖掘其底层原理,才能使自己的技术升华到更高的层面

Android 架构师之路还很漫长,与君共勉

PS:有问题欢迎指正,可以在评论区留下你的建议和感受; 欢迎大家点赞评论,觉得内容可以的话,可以转发分享一下