Android-高工面试真题：说说你对FPS的理解？如何检测应用的FPS？

ViewRootImpl.java

void scheduleTraversals() {
// 1. 防止重复调用
if (!mTraversalScheduled) {
mTraversalScheduled = true;
// 2. 发送同步屏障，保证优先处理异步消息
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
// 3. 最终会执行 mTraversalRunnable 这个任务
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
…
}
}

1. mTraversalScheduled 是个布尔值，防止重复调用，在一次 vsync 信号期间多次调用是没有意义的
2. 利用 Handler 的同步屏障机制，优先处理异步消息
3. Choreographer 登场

到这里，鼎鼎大名的 编舞者 —— Choreographer [ˌkɔːriˈɑːɡrəfər] 就该出场了（为了避免面试中出现不会读单词的尴尬，掌握一下发音还是必须的）。

通过 mChoreographer 发送了一个任务 mTraversalRunnable ，最终会在某个时刻被执行。在看源码之前，先抛出来几个问题：

1. mChoreographer 是在什么时候初始化的？
2. mTraversalRunnable 是个什么鬼？
3. mChoreographer 是如何发送任务以及任务是如何被调度执行的？

围绕这三个问题，我们再回到源码中。

先来看第一个问题，这就得回到上一节介绍过的 WindowManagerGlobal.addView() 方法。

WindowManagerGlobal.java

// 参数 view 就是 DecorView
public void addView(View view, ViewGroup.LayoutParams params, Display display, Window parentWindow) {
…
ViewRootImpl root;
// 1. 初始化 ViewRootImpl
root = new ViewRootImpl(view.getContext(), display);

mViews.add(view);
mRoots.add(root);

root.setView(view, wparams, panelParentView);
…
}

注释 1 处 新建了 ViewRootImpl 对象，跟进 ViewRootImpl 的构造函数。

ViewRootImpl.java

public ViewRootImpl(Context context, Display display) {
mContext = context;
// 1. IWindowSession 代理对象，与 WMS 进行 Binder 通信
mWindowSession = WindowManagerGlobal.getWindowSession();
…
mThread = Thread.currentThread();
…
// IWindow Binder 对象
mWindow = new W(this);
…
// 2. 初始化 mAttachInfo
mAttachInfo = new View.AttachInfo(mWindowSession, mWindow, display, this, mHandler, this,
context);
…
// 3. 初始化 Choreographer，通过 Threadlocal 存储
mChoreographer = Choreographer.getInstance();
…
}

在 ViewRootImpl 的构造函数中，注释 3 处初始化了 mChoreographer，调用的是 Choreographer.getInstance() 方法。

Choreographer.java

public static Choreographer getInstance() {
return sThreadInstance.get();
}

sThreadInstance 是一个 ThreadLocal<Choreographer> 对象。

Choreographer.java

private static final ThreadLocal sThreadInstance =
new ThreadLocal() {
@Override
protected Choreographer initialValue() {
Looper looper = Looper.myLooper();
if (looper == null) {
throw new IllegalStateException(“The current thread must have a looper!”);
}
// 新建 Choreographer 对象
Choreographer choreographer = new Choreographer(looper, VSYNC_SOURCE_APP);
if (looper == Looper.getMainLooper()) {
mMainInstance = choreographer;
}
return choreographer;
}
};

所以 mChoreographer 保存在 ThreadLocal 中的线程私有对象。它的构造函数中需要传入当前线程(这里就是主线程)的 Looper 对象。

这里再插一个题外话，主线程 Looper 是在什么时候创建的？ 回顾一下应用进程的创建流程：

• 调用 Process.start() 创建应用进程

• ZygoteProcess 负责和 Zygote 进程建立 socket 连接，并将创建进程需要的参数发送给 Zygote 的 socket 服务端

• Zygote 服务端接收到参数之后调用 ZygoteConnection.processOneCommand() 处理参数，并 fork 进程

• 最后通过 findStaticMain() 找到 ActivityThread 类的 main() 方法并执行，子进程就启动了

ActivityThread 并不是一个线程，但它是运行在主线程上的，主线程 Looper 就是在它的 main() 方法中执行的。

ActivityThread.java

public static void main(String[] args) {
…
// 创建主线程 Looper
Looper.prepareMainLooper();
…
// 创建 ActivityThread ，并 attach(false)
ActivityThread thread = new ActivityThread();
thread.attach(false, startSeq);
…
// 开启主线程消息循环
Looper.loop();
}

Looper 也是存储在 ThreadLocal 中的。

再回到 Choreographer，我们来看一下它的构造函数。

Choreographer.java

private Choreographer(Looper looper, int vsyncSource) {
mLooper = looper;
// 处理事件
mHandler = new FrameHandler(looper);
// USE_VSYNC 在 Android 4.1 之后默认为 true，
// FrameDisplayEventReceiver 是个 vsync 事件接收器
mDisplayEventReceiver = USE_VSYNC
? new FrameDisplayEventReceiver(looper, vsyncSource)
: null;
mLastFrameTimeNanos = Long.MIN_VALUE;

// 一帧的时间，60pfs 的话就是 16.7ms
mFrameIntervalNanos = (long)(1000000000 / getRefreshRate());
// 回调队列
mCallbackQueues = new CallbackQueue[CALLBACK_LAST + 1];
for (int i = 0; i <= CALLBACK_LAST; i++) {
mCallbackQueues[i] = new CallbackQueue();
}
}

这里出现了几个新面孔，FrameHandler、FrameDisplayEventReceiver、CallbackQueue，这里暂且不表，先混个脸熟，后面会一一说到。

介绍完 Choreographer 是如何初始化的，再回到 Choreographer 发送任务那块。

mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);

我们看看 mTraversalRunnable 是什么东西。

ViewRootImpl.java

final TraversalRunnable mTraversalRunnable = new TraversalRunnable();

final class TraversalRunnable implements Runnable {
@Override
public void run() {
doTraversal();
}
}

没什么特别的，它就是一个 Runnable 对象，run() 方法中会执行 doTraversal() 方法。

ViewRootImpl.java

void doTraversal() {
if (mTraversalScheduled) {
// 1. mTraversalScheduled 置为 false
mTraversalScheduled = false;
// 2. 移除同步屏障
mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);

// 3. 开始布局，测量，绘制流程
performTraversals();
…
}

再对比一下最开始发起绘制的 scheduleTraversals() 方法：

ViewRootImpl.java

void scheduleTraversals() {
// 1. mTraversalScheduled 置为 true，防止重复调用
if (!mTraversalScheduled) {
mTraversalScheduled = true;
// 2. 发送同步屏障，保证优先处理异步消息
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
// 3. 最终会执行 mTraversalRunnable 这个任务
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
…
}
}

仔细分别看一下上面两个方法的注释 1、2、 3，还是很清晰的。mTraversalRunnable 被执行后最终会调用 performTraversals() 方法，来完成整个 View 的测量，布局和绘制流程。

分析到这里，就差最后一步了，mTraversalRunnable 是如何被调度执行的？ 我们再回到 Choreographer.postCallback() 方法。

Choreographer.java

public void postCallback(int callbackType, Runnable action, Object token) {
postCallbackDelayed(callbackType, action, token, 0);
}

public void postCallbackDelayed(int callbackType,
Runnable action, Object token, long delayMillis) {
…
postCallbackDelayedInternal(callbackType, action, token, delayMillis);
}

// 传入的参数依次是 Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null，0
private void postCallbackDelayedInternal(int callbackType,
Object action, Object token, long delayMillis) {
…
synchronized (mLock) {
final long now = SystemClock.uptimeMillis();
final long dueTime = now + delayMillis;
// 1. 将 mTraversalRunnable 塞入队列
mCallbackQueues[callbackType].addCallbackLocked(dueTime, action, token);

if (dueTime <= now) { // 立即执行
// 2. 由于 delayMillis 是 0，所以会执行到这里
scheduleFrameLocked(now);
} else { // 延迟执行
Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_CALLBACK, action);
msg.arg1 = callbackType;
msg.setAsynchronous(true);
mHandler.sendMessageAtTime(msg, dueTime);
}
}
}

首先根据 callbackType(这里是 CALLBACK_TRAVERSAL) 将稍后要执行的 mTraversalRunnable 放入相应队列中，其中的具体逻辑就不看了。

然后由于 delayMillis 是 0，所以 dueTime 和 now 是相等的，所以直接执行 scheduleFrameLocked(now) 方法。如果 delayMillis 不为 0 的话，会通过 FrameHandler 发送一个延时消息，最后执行的仍然是 scheduleFrameLocked(now) 方法。

Choreographer.java

private void scheduleFrameLocked(long now) {
if (!mFrameScheduled) {
mFrameScheduled = true;
if (USE_VSYNC) { // Android 4.1 之后 USE_VSYNCUSE_VSYNC 默认为 true

// 如果是当前线程，直接申请 vsync，否则通过 handler 通信
if (isRunningOnLooperThreadLocked()) {
scheduleVsyncLocked();
} else {
// 发送异步消息
Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_VSYNC);
msg.setAsynchronous(true);
mHandler.sendMessageAtFrontOfQueue(msg);
}
} else { // 未开启 vsync，4.1 之后默认开启
final long nextFrameTime = Math.max(
mLastFrameTimeNanos / TimeUtils.NANOS_PER_MS + sFrameDelay, now);
Message msg = mHandler.obtainMessage(MSG_DO_FRAME);
msg.setAsynchronous(true);
mHandler.sendMessageAtTime(msg, nextFrameTime);
}
}
}

开头到现在，已经好几次提到了 VSYNC，官方也有一个视频介绍 Android Performance Patterns: Understanding VSYNC ，大家可以看一看。简而言之，VSYNC 是为了解决屏幕刷新率和 GPU 帧率不一致导致的 “屏幕撕裂” 问题。VSYNC 在 PC 端是很久以来就存在的技术，但在 4.1 之后，Google 才将其引入到 Android 显示系统中，以解决饱受诟病的 UI 显示不流畅问题。

再说的简单点，可以把 VSYNC 看成一个由硬件发出的定时信号，通过 Choreographer 监听这个信号。每当信号来临时，统一开始绘制工作。这就是 scheduleVsyncLocked() 方法的工作内容。

Choreographer.java

private void scheduleVsyncLocked() {
mDisplayEventReceiver.scheduleVsync();
}

mDisplayEventReceiver 是 FrameDisplayEventReceiver 对象，但它并没有 scheduleVsync() 方法，而是直接调用的父类方法。FrameDisplayEventReceiver 的父类是 DisplayEventReceiver 。

DisplayEventReceiver.java

public abstract class DisplayEventReceiver {

public void scheduleVsync() {
if (mReceiverPtr == 0) {
Log.w(TAG, "Attempted to schedule a vertical sync pulse but the display event "

• “receiver has already been disposed.”);
  } else {
  // 注册监听 vsync 信号，会回调 dispatchVsync() 方法
  nativeScheduleVsync(mReceiverPtr);
  }
  }

// 有 vsync 信号时，由 native 调用此方法
private void dispatchVsync(long timestampNanos, int builtInDisplayId, int frame) {
// timestampNanos 是 vsync 回调的时间
onVsync(timestampNanos, builtInDisplayId, frame);
}

public void onVsync(long timestampNanos, int builtInDisplayId, int frame) {
}
}

在 scheduleVsync() 方法中会通过 nativeScheduleVsync() 方法注册下一次 vsync 信号的监听，从方法名也能看出来，下面会进入 native 调用，水平有限，就不追进去了。

注册监听之后，当下次 vsync 信号来临时，会通过 jni 回调 java 层的 dispatchVsync() 方法，其中又调用了 onVsync() 方法。父类 DisplayEventReceiver 的 onVsync() 方法是个空实现，我们再回到子类 FrameDisplayEventReceiver ，它是 Choreographer 的内部类。

Choreographer.java

private final class FrameDisplayEventReceiver extends DisplayEventReceiver
implements Runnable {
private long mTimestampNanos;
private int mFrame;

// vsync 信号监听回调
@Override
public void onVsync(long timestampNanos, int builtInDisplayId, int frame) {
…
long now = System.nanoTime();
// // timestampNanos 是 vsync 回调的时间，不能比 now 大
if (timestampNanos > now) {
Log.w(TAG, "Frame time is " + ((timestampNanos - now) * 0.000001f)

• " ms in the future! Check that graphics HAL is generating vsync "
• “timestamps using the correct timebase.”);
  timestampNanos = now;
  }
  …
  mTimestampNanos = timestampNanos;
  mFrame = frame;
  // 这里传入的是 this，会回调本身的 run() 方法
  Message msg = Message.obtain(mHandler, this);
  // 这是一个异步消息，保证优先执行
  msg.setAsynchronous(true);
  mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);
  }

@Override
public void run() {
doFrame(mTimestampNanos, mFrame);
}
}

在 onVsync() 回调中，向主线程发送了一个异步消息，注意 sendMessageAtTime() 方法参数中的时间是 timestampNanos / TimeUtils。timestampNanos 是 vsync 信号的时间戳，单位是纳秒，所以这里做一个除法转换为毫秒。代码执行到这里的时候 vsync 信号已经发生，所以 timestampNanos 是比当前时间小的。这样这个消息塞进 MessageQueue 的时候就可以直接塞到前面了。另外 callback 是 this，所以当消息被执行时，调用的是自己的 run() 方法，run() 方法中调用的是 doFrame() 方法。

Choreographer.java

void doFrame(long frameTimeNanos, int frame) {
final long startNanos;
synchronized (mLock) {
if (!mFrameScheduled) {
return; // no work to do
}
…

long intendedFrameTimeNanos = frameTimeNanos;
startNanos = System.nanoTime();
// 计算超时时间
// frameTimeNanos 是 vsync 信号回调的时间，startNanos 是当前时间戳
// 相减得到主线程的耗时时间
final long jitterNanos = startNanos - frameTimeNanos;
// mFrameIntervalNanos 是一帧的时间
if (jitterNanos >= mFrameIntervalNanos) {
final long skippedFrames = jitterNanos / mFrameIntervalNanos;
// 掉帧超过 30 帧，打印 log
if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) {
Log.i(TAG, "Skipped " + skippedFrames + " frames! "

• “The application may be doing too much work on its main thread.”);
  }
  final long lastFrameOffset = jitterNanos % mFrameIntervalNanos;
  frameTimeNanos = startNanos - lastFrameOffset;
  }
  …
  }

try {
AnimationUtils.lockAnimationClock(frameTimeNanos / TimeUtils.NANOS_PER_MS);

// doCallBacks() 开始执行回调
mFrameInfo.markInputHandlingStart();
doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos);

mFrameInfo.markAnimationsStart();
doCallbacks(Choreographer.CALLBACK_ANIMATION, frameTimeNanos);

mFrameInfo.markPerformTraversalsStart();
doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos);

doCallbacks(Choreographer.CALLBACK_COMMIT, frameTimeNanos);
} finally {
AnimationUtils.unlockAnimationClock();
}
…
}

在 Choreographer.postCallback() 方法中将 mTraversalRunnable 塞进了 mCallbackQueues[] 数组中，下面的 doCallbacks() 方法就要把它取出来执行了。

Choreographer.java

void doCallbacks(int callbackType, long frameTimeNanos) {
CallbackRecord callbacks;
synchronized (mLock) {
final long now = System.nanoTime();
// 根据 callbackType 找到对应的 CallbackRecord 对象
callbacks = mCallbackQueues[callbackType].extractDueCallbacksLocked(
now / TimeUtils.NANOS_PER_MS);
if (callbacks == null) {
return;
}
mCallbacksRunning = true;
…
}
try {
for (CallbackRecord c = callbacks; c != null; c = c.next) {
// 执行 callBack
c.run(frameTimeNanos);
}
} finally {
…
}
}

根据 callbackType 找到对应的 mCallbackQueues ，然后执行，具体流程就不深入分析了。callbackType 共有四个类型，分别是 CALLBACK_INPUT、CALLBACK_ANIMATION、CALLBACK_TRAVERSAL、CALLBACK_COMMIT 。

Choreographer.CallbackRecord

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip204888 （备注Android）

结尾

最后，针对上面谈的内容，给大家推荐一个Android资料，应该对大家有用。

首先是一个知识清单：（对于现在的Android及移动互联网来说，我们需要掌握的技术）

泛型原理丶反射原理丶Java虚拟机原理丶线程池原理丶
注解原理丶注解原理丶序列化
Activity知识体系（Activity的生命周期丶Activity的任务栈丶Activity的启动模式丶View源码丶Fragment内核相关丶service原理等）
代码框架结构优化（数据结构丶排序算法丶设计模式）
APP性能优化（用户体验优化丶适配丶代码调优）
热修复丶热升级丶Hook技术丶IOC架构设计
NDK（c编程丶C++丶JNI丶LINUX）
如何提高开发效率？
MVC丶MVP丶MVVM
微信小程序
Hybrid
Flutter

接下来是资料清单：（敲黑板！！！）

---

1.数据结构和算法

2.设计模式

3.全套体系化高级架构视频；七大主流技术模块，视频+源码+笔记

4.面试专题资料包（怎么能少了一份全面的面试题总结呢~）

不论遇到什么困难，都不应该成为我们放弃的理由！共勉~

如果你看到了这里，觉得文章写得不错就给个赞呗？如果你觉得那里值得改进的，请给我留言。一定会认真查询，修正不足。谢谢。

MVC丶MVP丶MVVM

微信小程序
Hybrid
Flutter

[外链图片转存中…(img-XTrHevMO-1711913127296)]

接下来是资料清单：（敲黑板！！！）

---

1.数据结构和算法

[外链图片转存中…(img-h893eotP-1711913127297)]

2.设计模式

[外链图片转存中…(img-F2jaULgk-1711913127297)]

3.全套体系化高级架构视频；七大主流技术模块，视频+源码+笔记

[外链图片转存中…(img-uli9pELA-1711913127297)]

4.面试专题资料包（怎么能少了一份全面的面试题总结呢~）

[外链图片转存中…(img-FGKaRksu-1711913127298)]

不论遇到什么困难，都不应该成为我们放弃的理由！共勉~

如果你看到了这里，觉得文章写得不错就给个赞呗？如果你觉得那里值得改进的，请给我留言。一定会认真查询，修正不足。谢谢。

[外链图片转存中…(img-UwMStQtH-1711913127298)]

本文已被CODING开源项目：《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》收录