如果检测我们的UI卡顿?
企业级开发常态:在复杂的项目环境中,由于历史代码庞大,业务复杂,包含各种第三方库,偶尔再来个jni调用,所以在出现了卡顿的时候,我们很难定位到底是哪里出现了问题,即便知道是哪一个Activity/Fragment,也仍然需要进去里面一行一行看,动辄数千行的类再加上跳来跳去调来调去的,结果就是不了了之随它去了,实在不行了再优化吧。于是一拖再拖,最后可能压根就改不动了,客户端越来越卡。
事实上,很多情况下卡顿不是必现的,它们可能与机型、环境、操作等有关,存在偶然性,即使发生了,再去查那如山般的logcat,也不一定能找到卡顿的原因,是我们自己的应用导致的还是其他应用抢占资源导致的?是哪些方法导致的?很难去回朔。有些机型自己修改了api导致的卡顿,还必须拿那台机器才能去调试找原因。
BlockCanar介绍
BlockCanary对主线程操作进行了完全透明的监控,并能输出有效的信息,帮助开发分析、定位到问题所在,迅速优化应用。其特点有:
非侵入式,简单的两行就打开监控,不需要到处打点,破坏代码优雅性。
精准,输出的信息可以帮助定位到问题所在(精确到行),不需要像Logcat一样,慢慢去找。
目前包括了核心监控输出文件,以及UI显示卡顿信息功能。仅支持Android端。
如何使用?
配置 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'
新建一个类,继承自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"; } }
在自定义的Application对象中初始化Block的配置信息
public class MyApplication extends Application { public void onCreate() { super.onCreate(); //初始化配置信息 BlockCanary.install(this, new AppBlockCanaryContext()); } }
记得在清单文件的Application节点中声明android:name=”.MyApplication”
OK,环境搭建完毕,我们来模拟一个主界面卡顿的代码,用BlockCanary进行检测
在xml布局中添加一个按钮,来触发模拟卡顿的代码
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent" android:orientation="vertical" > <Button android:layout_width="wrap_content" android:layout_height="wrap_content" android:onClick="imitateClick" android:text="模仿UI卡顿"/> </LinearLayout>
在代码中使主线程阻塞3秒钟
public void imitateClick(View view) { SystemClock.sleep(3000); }
OK,代码已经写完,很简单,只是在布局中添加了一个按钮,并且在按钮点击之后让主线程阻塞2秒钟
整个程序界面如下:
当我们点击按钮之后等待3秒,查看BlockCanary给我们的提示信息
至此,我们可以清晰的看到,第20行代码就是界面的元凶,我们就可以修改20行的代码来解决界面卡顿的状况.