写了个 Android 性能检测的库，还有人看性能相关的么？

• 线程和线程池的创建和启动监控

• IPC(进程间通讯)监控

同时还实现了以下功能

• 实时通过 logcat 打印问题

• 高效保存检测信息到本地

• 提供上报到指定服务器接口

接入指南

====

1 在 APP 工程目录下面的 build.gradle 添加如下内容

dependencies {

debugImplementation “com.xander.performance:perf:0.1.9”

releaseImplementation “com.xander.performance:perf-noop:0.1.9”

}

2 APP 工程的 Application 类新增类似如下初始化代码

private void initPerformanceTool(Context context) {

PERF.Builder builder = new PERF.Builder().globalTag(“p-tool”) // 全局 log 日志 tag ，可以快速过滤日志

.checkUI(true, 100) // 检查
ui 线程, 超过指定时间还未结束，会被认为 ui 线程 block

.checkThread(true) // 检查线程和线程池的创建

.checkFps(true) // 检查 Fps

.checkIPC(true) // 检查 IPC 调用

.issueSupplier(new PERF.IssueSupplier() {

@Override

public long maxCacheSize() {

// issue 文件缓存的最大空间

return 1024 * 1024 * 20;

}

@Override

public File cacheRootDir() {

// issue 文件保存的根目录

return getApplicationContext().getCacheDir();

}

@Override

public boolean upLoad(File file) {

// 上传入口，返回 true 表示上传成功

return false;

}

}).build();

PERF.init(builder);

}

原理介绍

====

• UI 线程 block 检测原理

主要参考了 AndroidPerformanceMonitor 库的思路，对 UI 线程的 Looper 里面处理的 Message 过程进行监控。 在 Looper 开始处理 Message 前，在异步线程开启一个延时任务，用于后续收集信息。如果这个 Message 在指定的 时间段内完成了处理，那么在这个 Message 被处理完后，就取消之前的延时任务，说明 UI 线程没有 block 。如果在指定 的时间段内没有完成任务，说明 UI 线程有 block ，在判断发生 block 的同时，我们可以在异步线程执行刚才的延时任务， 如果我们在这个延时任务里面打印 UI 线程的方法调用栈，就可以知道 UI 线程在做什么了。

但是这个方案有一个缺点，就是无法处理 InputManager 的输入事件，比如 TV 端的遥控按键事件。通过按键事件的调用方法 链进行分析，最终每个按键事件都调用了 DecorView 类的 dispatchKeyEvent 方法，而非 Looper 的 loop Message 流程。所以 AndroidPerformanceMonitor 库是无法准确监控 TV 端应用的耗时情况。针对 TV 端应用按键处理， 需要找到一个新的切入点，这个切入点就是刚刚的 DecorView 类的 dispatchKeyEvent 方法。那如何介入 DecorView 类的 dispatchKeyEvent 方法呢？我们通过 epic 库来 hook 这个方法的调用，hook 成功后，我们可以在 DecorView 类的 dispatchKeyEvent 方法调用前后都接收到一个回调方法，在 dispatchKeyEvent 方法调用前我们可以在异步线程执行 一个延时任务，在 dispatchKeyEvent 方法调用后，取消这个延时任务。如果 dispatchKeyEvent 方法耗时时间小于 指定的时间阈值，可以认为没有 block ，此时移除了延时任务。如果 dispatchKeyEvent 方法耗时时间大于指定的时间阈值 说明此事 UI 线程是有 block 的，此时，就会执行这个延时任务来收集必要的信息。

以上就是 UI 线程 block 的检测原理了，目前做得还比较粗糙，后续可以考虑参考 AndroidPerformanceMonitor 打印 CPU 、内存等更多的信息。

最终终端 log 打印效果如下：

com.xander.performace.demo W/demo_Issue: =================================================

type: UI BLOCK

msg: UI BLOCK

create time: 2021-01-13 11:24:41

trace:

java.lang.Thread.sleep(Thread.java:-2)

java.lang.Thread.sleep(Thread.java:442)

java.lang.Thread.sleep(Thread.java:358)

com.xander.performance.demo.MainActivity.testANR(MainActivity.kt:49)

java.lang.reflect.Method.invoke(Method.java:-2)

androidx.appcompat.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:397)

android.view.View.performClick(View.java:7496)

android.view.View.performClickInternal(View.java:7473)

android.view.View.access$3600(View.java:831)

android.view.View$PerformClick.run(View.java:28641)

android.os.Handler.handleCallback(Handler.java:938)

android.os.Handler.dispatchMessage(Handler.java:99)

android.os.Looper.loop(Looper.java:236)

android.app.ActivityThread.main(ActivityThread.java:7876)

java.lang.reflect.Method.invoke(Method.java:-2)

com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)

com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)

• App 的 FPS 检测的原理

FPS 检测的原理，利用了 Android 的屏幕绘制原理。

这里简单说下 Android 的屏幕绘制原理。

系统每隔 16 ms 就会发送一个 VSync 信号，如果 App 注册了这个 VSync 信号，就会在 VSync 信号到来的时候，收到回调， 从而开始准备绘制，如果准备顺利，也就是 cpu 准备好数据， gpu 栅格化完成。如果这些任务在 16 ms 之内完成，那么下一个 VSync 信号到来的时候就可以绘制这一帧界面了。这个准备好的画面就会被显示出来。如果没准备好，可能就需要 32 ms 后 或者更久的时间后，才能准备好，这个画面才能显示出来，这种情况下就发生了丢帧。

上面提到了 VSync 信号，当 VSync 信号到来的时候会通知应用开始准备绘制，具体的通知细节不做表述。大概的原理就是， 开始准备绘制前，往 MessageQueue 里面放一个同步屏障，这样 UI 线程就只会处理异步消息，直到同步屏障被移除， 然后 App 注册一个 VSync 信号监听，当 VSync 信号到达的时候，给 MessageQueue 里面放一个异步 Message 。 由于之前 MessageQueue 里有了一个同步屏障消息，所有后续 UI 线程会优先处理这个异步 Message 。 这个异步 Message 做的事情就是从 ViewRootImpl 开始了我们熟悉的 measure 、layout 和 draw 。

检测 FPS 的原理其实挺简单的，就是通过一段时间内，比如 1s，统计绘制了多少个画面，就可以计算出 FPS 了。

那如何知道应用 1s 内绘制了多少个界面呢？这个就要靠 VSync 信号监听了。我们通过 Choreographer 注册 VSync 信号监听。 16ms 后，我们收到了 VSync 的信号，给 MessageQueue 里面放一个同步消息，我们不做特别处理，只是做一个计数， 然后监听下一次的 VSync 信号，这样，我们就可以知道 1s 那我们监听到了多少个 VSync 信号，就可以得出帧率。

为什么监听到的 VSync 信号数量就是帧率呢？由于 Looper 处理 Message 是串行的，就是一次只处理一个 Message ，处理 完了这个 Message 才会处理下一个 Message 。而绘制的时候，绘制任务 Message 是异步消息，会优先执行，绘制任务 Message 执行完成后，就会执行上面说的 VSync 信号计数的任务，所以最后统计到的 VSync 信号数量可以认为是某段时间内绘制的帧数。 然后就可以通过这段时间的长度和 VSync 信号数量来计算帧率了。

最终终端 log 打印效果如下：

com.xander.performace.demo W/demo_FPSTool: APP FPS is: 54 Hz

com.xander.performace.demo W/demo_FPSTool: APP FPS is: 60 Hz

com.xander.performace.demo W/demo_FPSTool: APP FPS is: 60 Hz

• 线程和线程池的创建和启动监控原理

线程和线程池的监控，主要是监控线程和线程池在哪里创建和执行的，如果我们可以知道这些信息， 我们就可以比较清楚线程和线程池的创建和启动时机是否合理。从而得出优化方案。

一个比较容易想到的方法就是，应用代码里面的所有线程和线程池继承同一个线程基类和线程池基类。 然后在构造函数和启动函数里面打印方法调用栈，这样我们就知道哪里创建和执行了线程或者线程池。

让应用所有的线程和线程池继承同一个基类，可以通过编译插件来实现，定制一个特殊的 Transform ， 通过 ASM 编辑生成的字节码来改变继承关系。但是，这个方法有一定的上手难度，不太适合新手。

除了这个方法，我们还有另外一种方法，就是 hook 。通过 hook 线程或者线程池的构造方法和启动方法， 我们就可以在线程或者线程池的构造方法和启动方法的前后做一些切片处理，比如打印当前方法调用栈等。 这个也就是线程和线程池监控的基本原理。

线程池的监控没有太大难度，一般都是 ThreadPoolExecutor 的子类，所以我们 hook 一下 ThreadPoolExecutor 的 构造方法就可以监控线程池的创建了。线程池的执行主要就是 hook 住 ThreadPoolExecutor 类的 execute 方法。
hook 。通过 hook 线程或者线程池的构造方法和启动方法， 我们就可以在线程或者线程池的构造方法和启动方法的前后做一些切片处理，比如打印当前方法调用栈等。 这个也就是线程和线程池监控的基本原理。

线程池的监控没有太大难度，一般都是 ThreadPoolExecutor 的子类，所以我们 hook 一下 ThreadPoolExecutor 的 构造方法就可以监控线程池的创建了。线程池的执行主要就是 hook 住 ThreadPoolExecutor 类的 execute 方法。