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

如果检测我们的UI卡顿?
企业级开发常态：在复杂的项目环境中，由于历史代码庞大，业务复杂，包含各种第三方库，偶尔再来个jni调用，所以在出现了卡顿的时候，我们很难定位到底是哪里出现了问题，即便知道是哪一个/，也仍然需要进去里面一行一行看，动辄数千行的类再加上跳来跳去调来调去的，结果就是不了了之随它去了，实在不行了再优化吧。于是一拖再拖，最后可能压根就改不动了，客户端越来越卡。
事实上，很多情况下卡顿不是必现的，它们可能与机型、环境、操作等有关，存在偶然性，即使发生了，再去查那如山般的，也不一定能找到卡顿的原因，是我们自己的应用导致的还是其他应用抢占资源导致的？是哪些方法导致的？很难去回朔。有些机型自己修改了api导致的卡顿，还必须拿那台机器才能去调试找原因。
介绍
对主线程操作进行了完全透明的监控，并能输出有效的信息，帮助开发分析、定位到问题所在，迅速优化应用。其特点有：
非侵入式，简单的两行就打开监控，不需要到处打点，破坏代码优雅性。
精准，输出的信息可以帮助定位到问题所在（精确到行），不需要像一样，慢慢去找。
目前包括了核心监控输出文件，以及UI显示卡顿信息功能。仅支持端。
如何使用?

文章插图
配置 build.文件

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'

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

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

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

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

记得在清单文件的节点中声明:name=”.”
OK,环境搭建完毕,我们来模拟一个主界面卡顿的代码,用进行检测
在xml布局中添加一个按钮,来触发模拟卡顿的代码

在代码中使主线程阻塞3秒钟
public void imitateClick(View view) {SystemClock.sleep(3000);}
OK,代码已经写完,很简单,只是在布局中添加了一个按钮,并且在按钮点击之后让主线程阻塞2秒钟
整个程序界面如下:

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

文章插图
【找出造成Android App界面卡顿的原因- BlockCanary】至此,我们可以清晰的看到,第20行代码就是界面的元凶,我们就可以修改20行的代码来解决界面卡顿的状况.