找出造成Android App界面卡顿的原因- BlockCanary

如果检测我们的UI卡顿?

企业级开发常态：在复杂的项目环境中，由于历史代码庞大，业务复杂，包含各种第三方库，偶尔再来个jni调用，所以在出现了卡顿的时候，我们很难定位到底是哪里出现了问题，即便知道是哪一个Activity/Fragment，也仍然需要进去里面一行一行看，动辄数千行的类再加上跳来跳去调来调去的，结果就是不了了之随它去了，实在不行了再优化吧。于是一拖再拖，最后可能压根就改不动了，客户端越来越卡。

事实上，很多情况下卡顿不是必现的，它们可能与机型、环境、操作等有关，存在偶然性，即使发生了，再去查那如山般的logcat，也不一定能找到卡顿的原因，是我们自己的应用导致的还是其他应用抢占资源导致的？是哪些方法导致的？很难去回朔。有些机型自己修改了api导致的卡顿，还必须拿那台机器才能去调试找原因。

BlockCanar介绍

BlockCanary对主线程操作进行了完全透明的监控，并能输出有效的信息，帮助开发分析、定位到问题所在，迅速优化应用。其特点有：

非侵入式，简单的两行就打开监控，不需要到处打点，破坏代码优雅性。
精准，输出的信息可以帮助定位到问题所在（精确到行），不需要像Logcat一样，慢慢去找。
目前包括了核心监控输出文件，以及UI显示卡顿信息功能。仅支持Android端。

如何使用?

1. 配置 build.gradle文件

   compile 'com.github.moduth:blockcanary-android:1.2.1'
   // 仅在debug包启用BlockCanary进行卡顿监控和提示的话，可以这么用
   debugCompile 'com.github.moduth:blockcanary-android:1.2.1'
   releaseCompile 'com.github.moduth:blockcanary-no-op:1.2.1'
   

2. 新建一个类,继承自BlockCanaryContext，实现自己的监控上下文，代码示意如下

   public class AppBlockCanaryContext extends BlockCanaryContext {
   
       //设置卡顿判断的阙值
       public int getConfigBlockThreshold() {
           return 500;
       }
   
       //是否需要显示卡顿的信息
       public boolean isNeedDisplay() {
           return BuildConfig.DEBUG;
       }
   
       //设置log保存在sd卡的目录位置
       public String getLogPath() {
           return "/blockcanary/performance";
       }
   }
   

3. 在自定义的Application对象中初始化Block的配置信息

   public class MyApplication extends Application {
       public void onCreate() {
           super.onCreate();
           //初始化配置信息
           BlockCanary.install(this, new AppBlockCanaryContext());
       }
   }
   

   记得在清单文件的Application节点中声明android:name=”.MyApplication”

OK,环境搭建完毕,我们来模拟一个主界面卡顿的代码,用BlockCanary进行检测

1. 在xml布局中添加一个按钮,来触发模拟卡顿的代码

2. 在代码中使主线程阻塞3秒钟

   public void imitateClick(View view) {
       SystemClock.sleep(3000);
   }
   

OK,代码已经写完,很简单,只是在布局中添加了一个按钮,并且在按钮点击之后让主线程阻塞2秒钟

整个程序界面如下:

当我们点击按钮之后等待3秒,查看BlockCanary给我们的提示信息

至此,我们可以清晰的看到,第20行代码就是界面的元凶,我们就可以修改20行的代码来解决界面卡顿的状况.