美文网首页Android开发工具APP优化
Android性能优化(六)之卡顿那些事

Android性能优化(六)之卡顿那些事

作者: 未来的理想 | 来源:发表于2017-03-27 17:52 被阅读4430次

1、 Introduction

对普通用户而言,类如内存占用高、耗流量、耗电量等性能问题可能不会轻易发现,但是卡顿问题用户一定会立马直观的感受到。本文就带你一览卡顿的发生、检测、及优化。

2、 The Final Reason Why It Block ?

《Android性能优化(二)之布局优化面面观》中我们说到:60fps VS 16ms。

60帧每秒是目前最合适的图像显示速度,也是绝大部分Android设备设置的调试频率,如果在16ms内顺利完成界面刷新操作可以展示出流畅的画面,而由于任何原因导致接收到VSYNC信号的时候无法完成本次刷新操作,就会产生掉帧的现象,刷新帧率自然也就跟着下降(假定刷新帧率由正常的60fps降到30fps,用户就会明显感知到卡顿)。

卡顿感受的由来

3、 The Ways Lead To Block

3.1 UI线程中的耗时操作

  • UI线程中有I/O读写、数据库访问等耗时操作;

3.2 复杂、不合理的布局以及OverDraw

3.3 内存使用异常导致的卡顿

3.4 错误的异步方式

  • 对线程开启方式的不同选择以及不同配置都可能导致卡顿的发生;
    • 《Android性能优化(一)之启动加速35%》一文中说到过:不正确的异步任务不仅不能较好的完成异步任务,反而会加剧卡顿。关于异步任务开启的选择,之后会出一篇详细的文章,可以先参考启动加速的文章。

4、 The Ways To Find Block

4.1 StickMode

StrictMode类是Android 2.3 (API 9)引入的一个工具类,可以用来帮助开发者发现代码中的一些不规范的问题,以达到提升应用响应能力的目的。可以设置不同的线程检测策略、虚拟机检测策略。

 public void onCreate() {
     if (DEVELOPER_MODE) {
        // 线程检测策略
         StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
                 .detectDiskReads()
                 .detectDiskWrites()
                 .detectNetwork()   // or .detectAll() for all detectable problems
                 .penaltyLog()
                 .build());
        // 虚拟机检测策略    
         StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
                 .detectLeakedSqlLiteObjects()
                 .detectLeakedClosableObjects()
                 .penaltyLog()
                 .penaltyDeath()
                 .build());
     }
     super.onCreate();
 }

当违规操作发生时,可以根据自定义的策略记录下Log或者Crash,以便于跟踪改善。

4.2 TraceView

与StickMode相比,TraceView简直是发现Block根源的神器,不仅能看出每个方法消耗的时间、发生次数,并且可以进行排序,直接从最耗时的方法开始处优化;

关于TraceView的使用及分析,请参考《Android性能优化(一)之启动加速35%》第五章节。

4.3 AndroidPerformanceMonitor

AndroidPerformanceMonitor 是一个检测卡顿的开源库,前身是BlockCanary,更前身则是LeakCanary。而其使用与LeakCanary也比较相似,可以自主设置卡顿检测时间,检测到的卡顿同样是以Notification展示,在使用体验上也相当类似,与LeakCanary可以说是孪生兄弟。

原理
利用了Looper.loop()中每个Message被分发前后的Log打印,而我们设置自己的Printer就可以根据Log的不同的处理:

  • Message分发前,使用HandlerThread延时发送一个Runnable,这个时间可自己设置;
  • Message在规定的时间内完成分发,则会取消掉这个Runnable;
  • Message没有在规定的时间内(实际上是规定时间的0.8)完成分发,那这个Runnable就会被执行,可以获取到当前的堆栈信息;
// This must be in a local variable, in case a UI event sets the logger
Printer logging = me.mLogging;
if (logging != null) {
    logging.println(">>>>> Dispatching to " + msg.target + " " +
            msg.callback + ": " + msg.what);
}

msg.target.dispatchMessage(msg);

if (logging != null) {
    logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
}

4.4 ANR-WatchDog

ANR-WatchDog同样是一个检测卡顿的检测库,与AndroidPerformanceMonitor不一样的是它的原理相对简单:

  • 原理是开启一个线程,持续循环不断的往UI线程中Post一个Runnable(修改一个数的大小),然后在规定时间之后检测这个Runnable是否被执行(数的大小有没有 被修改过来)。没有被执行的话说明主线程执行上一个Message超时,然后获取当前堆栈信息;
  • ANR-WatchDog的原理更加简单,但是根据使用情况来看准确性不及AndroidPerformanceMonitor高,而且可设置的配置不如AndroidPerformanceMonitor丰富;

4.5 Choreographer

我们知道Android系统每隔16ms都会发出VSYNC信号,触发UI的绘制,而我们可以拿到回调的监听。如果16ms没有回调的话我们就知道发生了卡顿。

Choreographer.getInstance().postFrameCallback(new Choreographer.FrameCallback() {
            @Override
            public void doFrame(long l) {
                
            }
});

备注:这种方式的原理也比较简单,但是可用性不高,只能测出界面绘制的卡顿

5、 The Ways To Avoid Block

在第三节我们分析了产生卡顿的原因,那么避免卡顿的方法就很简单了:反其向行知即可。

5.1 将耗时操作移到异步中

  • 类如I/O读写、数据库访问等都应该采用异步的方式,不能有“只是一个很小的文件”之类的想法,防微杜渐;

5.2 合理优化布局,避免OverDraw。

5.3 合理优化内存

  • 节省内存的分配空间,尽可能的降低GC的频率,缩短GC的平均时间;CPU不被占用,卡顿的几率就会更低;

5.4 正确使用异步

  • 再次强调一遍:耗时操作不能都直接随意交给异步,不正确的异步使用方式反而会加剧卡顿;

6、 The Normal Ways Of Dealing Block

1. 开发中使用AndroidPerformanceMonitor检测卡顿进行处理;
2. 任何耗时操作正确的移到异步里;
3. 合理优化布局,避免OverDraw;
4. 优化内存分配,减少GC频率,这一般不是某个界面的事情,是一项长期工作;

7、 Block Check Of System

系统对Block有检测吗?那必须有!大名鼎鼎的ANR就来于此。

ANR的来龙去脉:触发场景、分析方法,你真的都清楚吗?欢迎关注下一篇文章,带你细究ANR不为人知的那些事。

欢迎关注微信公众号:定期分享Java、Android干货!

欢迎关注

相关文章

网友评论

  • houliang:文章干货!!!👍👍👍👍👍👍
    有个问题请教下:通过msg的logger检测卡顿,以及文中提到的anr检测,在检测到卡顿的时候"打印堆栈",这个堆栈指的是?这里打出来的好像都是消息分发的堆栈,怎么打出当前卡顿的执行堆栈呢?
    未来的理想:@houliang 1. 判断是分发前还是分发后,可以通过匹配字符串,也可以通过自己写一个变量作为识别的依据;2. 判断到是分发前的话使用handler.postDelay一个msg,然后在分发结束之后remove这个msg;而如果超过了设定的超时时间,这个msg就被执行,获取堆栈信息。还有一种方式,不post消息:在分发之后判断下具体执行耗时,超过超时时间的话获取堆栈信息显示。最新版的AndroidPerformanceMonitor就是这么做的,参见代码:https://github.com/markzhai/AndroidPerformanceMonitor/blob/master/blockcanary-analyzer/src/main/java/com/github/moduth/blockcanary/LooperMonitor.java
    houliang: @双十二技术哥 感谢您的回答,我又看了下文章,anr那个大概可以理解,performance那个还是有点疑问,首先dispatch的log,printer如何识别是分发前还是分发后的,通过字符串匹配吗?其次执行过程中当前的msg如何会去检测插入的runnable的状态呢?还有就是当前的msg何时去检测插入的runnable呢?
    未来的理想:@houliang 卡顿的堆栈信息是通过Looper.getMainLooper().getThread().getStackTrace()获取到的,Printer打印的消息分发的信息是拿来判断是否出现了卡顿的,判断出现了卡顿,则自己获取卡顿的堆栈信息。
  • 韦东锏:希望有实际的检查卡顿的例子
    特别是跑monkey碰到的卡顿,如何检测!!
    未来的理想:可以参考下第七篇文章《Android性能优化(七)之你真的理解ANR吗?》,开发过程可以使用AndroidPerformanceMonitor来检测卡顿,同样在跑Monkey的时候也加上这个库。还有就是去分析跑Monkey之后的日志信息了。另外要注意由于Monkey自身的特点、系统的Bug等,有些ANR可能也是无法分析到原因的。

本文标题:Android性能优化(六)之卡顿那些事

本文链接:https://www.haomeiwen.com/subject/ixbrottx.html