- App 的 FPS 检测的原理
这里简单说下 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 打印效果如下:
【写了个 Android 性能检测的库,还有人看性能相关的么?】
com.xander.performace.demo W/demo_FPSTool: APP FPS is: 54 Hzcom.xander.performace.demo W/demo_FPSTool: APP FPS is: 60 Hzcom.xander.performace.demo W/demo_FPSTool: APP FPS is: 60 Hz
- 线程和线程池的创建和启动监控原理
一个比较容易想到的方法就是,应用代码里面的所有线程和线程池继承同一个线程基类和线程池基类 。然后在构造函数和启动函数里面打印方法调用栈,这样我们就知道哪里创建和执行了线程或者线程池 。
让应用所有的线程和线程池继承同一个基类,可以通过编译插件来实现,定制一个特殊的 Transform , 通过 ASM 编辑生成的字节码来改变继承关系 。但是,这个方法有一定的上手难度,不太适合新手 。
除了这个方法,我们还有另外一种方法,就是 hook。通过 hook 线程或者线程池的构造方法和启动方法, 我们就可以在线程或者线程池的构造方法和启动方法的前后做一些切片处理,比如打印当前方法调用栈等 。这个也就是线程和线程池监控的基本原理 。
线程池的监控没有太大难度,一般都是 ThreadPoolExecutor 的子类,所以我们 hook 一下 ThreadPoolExecutor 的 构造方法就可以监控线程池的创建了 。线程池的执行主要就是 hook 住 ThreadPoolExecutor 类的 execute 方法 。
线程的创建和执行的监控方法就稍微要费些脑筋了,因为线程池里面会创建线程,所以这个线程的创建和执行应该和线程池 绑定的 。需要找到线程和线程池的联系,之前看到一个库,好像是通过线程和线程池的 ThreadGroup 来建立关联的,本来 我也计划按照这个关系来写代码的,但是我发现,我们有的小伙伴写的线程池的 ThreadFactory 里面创建线程并没有传入 ThreadGroup ,这个就尴尬了,就建立不了联系了 。经过查阅相关源码发现了一个关键的类,ThreadPoolExecutor 的内部类 Worker ,由于这个类是内部类,所以这个类实际的构造方法里面会传入一个外部类的实例,也就是 ThreadPoolExecutor 实例 。同时, Worker 这个类还是一个 Runnable 实现,在 Worker 类通过 ThreadFactory 创建线程的时候,会把自己作为一个 Runnable 传给 Thread 所以,我们通过这个关系,就可以知道 Worker 和 Thread 的关联了 。这样,我们通过 ThreadPoolExecutor 和 Worker 的关联,以及 Worker 和 Thread 的关联,就可以得到 ThreadPoolExecutor 和 它创建的 Thread 的关联了 。这个也就是线程和线程池的监控原理了 。
推荐阅读
- 为什么选朱厚熜做皇帝 朱厚璁后下一个皇帝
- 10 个冷门但又非常实用的 Docker 使用技巧
- 每个软件架构师和软件工程师都必须知道的10种设计模式
- 《大盗贼》?我是一个大盗贼什么也不怕
- airpods pro一个耳朵有声音一个耳朵没声音但可以操控,airpodspro一个耳朵有声音一个耳朵没声音-
- nova6se对比荣耀20s?荣耀20和nova6se哪个好_1
- libresse卫生巾感受?libresse薇尔卫生巾怎么样
- 良心推荐8个安全测试工具,快来取走
- 清朝八旗是哪八旗,哪个旗的地位更高? 八旗地位最高的是哪一旗
- 端口的作用