Android 性能优化“基石”是什么，apt编译时期自动生成代码&动态类加载

2 先抛出问题

---

1. 一个性能数据采集系统，你不能成为一个app的负担，不能在采集的时候耽误主线程的渲染，接入了Apm之后反倒让App变得更加卡顿。

2. 由于Fps，内存，Cpu等都是需要频繁采样的，比如Fps，一秒钟刷新60帧，如果全量数据上报，那么后端大佬可能就把我给打死了。

3. 在业务最少介入的情况下完成关键页面数据的收集，以及将页面数据和性能数据进行绑定。

3 Fps采集

---

首先我们还是要先介绍下什么是Fps.

流畅度，是页面在滑动、渲染等过程中的体验。Android系统要求每一帧都要在 16ms 内绘制完成，平滑的完成一帧意味着任何特殊的帧需要执行所有的渲染代码（包括 framework 发送给 GPU 和 CPU 绘制到缓冲区的命令）都要在 16ms 内完成，保持流畅的体验。如果没有在期间完成渲染秒就会发生掉帧。掉帧是用户体验中一个非常核心的问题。丢弃了当前帧，并且之后不能够延续之前的帧率，这种不连续的间隔会容易会引起用户的注意，也就是我们常说的卡顿、不流畅。

那么是不是1s只要绘制了60帧是不是就是流畅的呢？也不一定，如果发生抖动的情况，那么肯定会有其中几帧是有问题的。其中肯定会有最大绘制帧，和最小绘制帧的情况，所以平均值，最大值最小值都是我们需要知道的。

在讨论采集之前，我们要先简单的说下两个东西Choreographer和LooperPrinter。

Choreographer(编舞者)

Choreographer中文翻译过来是"舞蹈指挥"，字面上的意思就是优雅地指挥以上三个UI操作一起跳一支舞。这个词可以概括这个类的工作，如果android系统是一场芭蕾舞，他就是Android UI显示这出精彩舞剧的编舞，指挥台上的演员们相互合作，精彩演出。Google的工程师看来挺喜欢舞蹈的！

其中关于Choreographer的介绍相关的可以参考这篇文章* https://juejin.im/post/6890407553457963022*，面试中也经常会问到这个问题，ViewRootImp和Vsync等等，但是我们还是比较专注于数据的采集和上报，所以关注的重点还是有点不同。

一般常规的Fps采集可以通过Choreographer既UI线程绘制的编舞者，Choreographer是一个ThreadLocal的单例，接收vsync信号进行界面的渲染，我们只要对其添加一个CallBack，就可以巧妙的计算出这一帧的绘制时长。

Matrix对于核心Choreographer是对CallbackQueue的hook，通过hook addCallbackLocked分别在不同类型的回调队列的头部添加自定义的FrameCallback。

这样系统CALLBACK_INPUT = 自定义CALLBACK_ANIMATION的开始时间-自定义CALLBACK_INPUT的完成时间

系统CALLBACK_ANIMATION = 自定义CALLBACK_TRAVERSAL开始时间-自定义CALLBACK_ANIMATION开始时间

系统CALLBACK_TRAVERSAL = msg dipatch结束时间- 自定义CALLBACK_TRAVERSAL开始时间

LooperPrinter

首先我们先要有个概念，所有的View相关的和生命周期相关的都被执行在主线程上。那么我们有没有方法可以监控到主线程耗时呢？

我们盘一盘Handler是如何执行的，首先Looper从MessageQueue中获取到Message,之后判断Message内部的Handler或者Runnable来决定执行后续的操作。

从ActivityThread分析，所有的主线程操作的被执行在主线程的Looper上，那么我们是不是只要在主线程的Looper的loop方法，获取到Message的前后执行加上写代码就能监控到一个Message 被执行的时长了呢。

public static void loop() {

final Looper me = myLooper();

if (me == null) {

throw new RuntimeException(“No Looper; Looper.prepare() wasn’t called on this thread.”);

}

final MessageQueue queue = me.mQueue;

// Make sure the identity of this thread is that of the local process,

// and keep track of what that identity t