Android性能优化（六）之卡顿那些事

一、 Introduction

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

二、 The Final Reason Why It Block ?

在《Android性能优化（二）之布局优化面面观》中咱们说到：60fps VS 16ms。

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

三、 The Ways Lead To Block

3.1 UI线程中的耗时操做

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

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

• 不合理的布局虽然能够完成功能，但随着控件数量越多、布局嵌套层次越深，展开布局花费的时间几乎是线性增加，性能也就越差；
• 避免OverDraw致使的性能损耗；
• 能够参考《Android性能优化（二）之布局优化面面观》

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

• 内存抖动、内存泄漏都会致使：GC的次数越多、消耗在GC上的时间越长，CPU花在界面绘制上的时间相应越短；
• 能够参考《Android性能优化（四）以内存优化实战》

3.4 错误的异步方式

• 对线程开启方式的不一样选择以及不一样配置均可能致使卡顿的发生；
  • 在《Android性能优化（一）之启动加速35%》一文中说到过：**不正确的异步任务不只不能较好的完成异步任务，反而会加重卡顿。**关于异步任务开启的选择，以后会出一篇详细的文章，能够先参考启动加速的文章。

四、 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) {
                
            }
});
复制代码

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

五、 The Ways To Avoid Block

在第三节咱们分析了产生卡顿的缘由，那么避免卡顿的方法就很简单了：反其向行知便可。

5.1 将耗时操做移到异步中

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

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

• 一样的实现功能界面，不一样的布局方式产生的View个数以及渲染耗时差别是数倍的，恐怖的差别能够参考《Android性能优化（二）之布局优化面面观》；

5.3 合理优化内存

• 节省内存的分配空间，尽量的下降GC的频率，缩短GC的平均时间；CPU不被占用，卡顿的概率就会更低；

5.4 正确使用异步

• 再次强调一遍：耗时操做不能都直接随意交给异步，不正确的异步使用方式反而会加重卡顿；

六、 The Normal Ways Of Dealing Block

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

七、 Block Check Of System

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

ANR的前因后果：触发场景、分析方法，你真的都清楚吗？欢迎关注下一篇文章，带你细究ANR鲜为人知的那些事。

欢迎关注微信公众号：按期分享Java、Android干货！