Android帧率统计及其相关基础知识介绍
帧率，在App层面，就是UI界面每秒可重绘的次数，它的上限是运行手机的屏幕刷新率，也就是屏幕每秒刷新的次数，一般来说，刷新率超过60，人眼就感知不到了，所以一般手机的屏幕刷新率都为60，因为超过60一没多大意义，二更耗电，并且还会加速屏幕的老化，影响使用寿命，所以会得不偿失
可以用如下代码获取屏幕刷新率：
Display display = getWindowManager().getDefaultDisplay();
float refreshRate = display.getRefreshRate();
一般都为60，也就是说，图像的刷新周期为16ms
Android图像显示自底向上依次是
- HWComposer HAL - VSync， framebuffer
- SurfaceFlinger -> 对App过来的Surface图像数据做叠加，组合等处理
- App - GPU DisplayList Render
- App - ViewTree DisplayList
App的每一个View都会包含一个DisplayList，既然是List，说明它本质上就是一个缓存区，它包含了View即将要绘制的Canvas API调用及其参数记录，设置缓存列表最大的好处就是，在每次绘制过程中，如果View UI没有变化，或者变化很少，可以尽可能的复用DisplayList，从而提高绘制效率
GPU DisplayList Render，指的是，将DisplayList包含的Canvas绘制命令转换成Open GL命令由GPU执行生成最终的图像数据
接着传递到SurfaceFlinger，在做叠加和组合后，最终通过framebuffer来显示到屏幕上
这四个角色如果要高效协作，必须要存在一个同步机制，它就是VSync机制
VSync介绍
Vsync这个中断通知，源头是从HWComposer HAL发出，并通知到SurfaceFlinger，然后SurfaceFlinger再将通知转发给各个App,咱们可以看Choreographer接受VSync的FrameDisplayEventReceiver是怎么实现的，直接看父类DisplayEventReceiver对应的C++实现：
DisplayEventReceiver::DisplayEventReceiver() {
sp<ISurfaceComposer> sf(ComposerService::getComposerService());
if (sf != NULL) {
mEventConnection = sf->createDisplayEventConnection();
if (mEventConnection != NULL) {
mDataChannel = mEventConnection->getDataChannel();
}
}
}
接着看Vsync是如何同步的
没有VSync：
第一个16ms一切正常，第二个16ms，前半段GPU和CPU都没参与进来，第2帧绘制触发过晚，导致CPU绘制和GPU渲染延后到了第三个16ms，从而产生卡顿；为什么第二个GPU和CPU会没参与进来，可能那时候在做别的运算，也可能是闲置的，没收到通知而已，总之就是，他两啥时候参与进来，是不确定的
使用VSync后：
加入Vsync后就好多了，Display会每16ms触发Vsync中断，通知CPU和GPU开始绘制下一桢，一切井然有序，画面流畅多了；有个VSync后，图中显示的正常情况，也会存在不正常情况
双重缓冲：
双重缓冲，说明只存在两个buffer，一个供当前显示，一个用于下一个界面的绘制，不过如果碰到图中所示的情况，就会存在卡顿的情况，原因是第一和第三个16ms周期，CPU和GPU都没能在周期内渲染完毕，延后到下一周期了，从而导致了第2和第4个16ms周期的卡顿；从图中可以看出，第二个16ms的CPU和GPU是空闲的，第三个16ms周期，前半段GPU也是空闲的，其实第三个16ms周期的A是可以提前触发的绘制的，目前没被触发是因为缓冲区不够，因为在第二个周期，A缓冲还被Display用着，要优化这种情况，必须再加个缓冲
三重缓冲：
引入三重缓冲后，虽然第二个周期还是jank了，但是由于有缓冲C可用，可以在第二个周期就开始下一帧的绘制，从而最大程度利用和CPU和GPU，减少了后续jank的产生
Choreographer的作用
直接看图：
sequenceDiagram
Choreographer->>SurfaceFliner: connection
Choreographer->>SurfaceFliner: request vsync notify
HWComposer->>SurfaceFliner: vsync event
SurfaceFliner->>Choreographer: notify
Choreographer->>Choreographer: do frame
Choreographer->>SurfaceFliner: swap frame buffer
从图中可以看出，Choreographer的作用就两点：
- 向SurfaceFlinger请求vsync通知
- 在下一vsync通知到来时，触发当前帧的绘制，绘制完成后，再把数据提交给SurfaceFliner，然后输出到framebuffer
从上面说的可以知道，app如果不想错过SurfaceFlinger这一次vsync数据提交，那必须在16ms完成全部的绘制，要不就错过了，从而产生掉帧
当前帧的绘制，是通过调用App运行时设置的callback来完成的，调用顺序：
CALLBACK_INPUT：与输入事件有关
CALLBACK_ANIMATION：与动画有关
CALLBACK_TRAVERSAL：与UI绘制有关
从代码层面分析
首先连接SurfaceFlinger：
private Choreographer(Looper looper) {
mLooper = looper;
mHandler = new FrameHandler(looper);
//就在这里
mDisplayEventReceiver = USE_VSYNC ? new FrameDisplayEventReceiver(looper) : null;
mLastFrameTimeNanos = Long.MIN_VALUE;
mFrameIntervalNanos = (long)(1000000000 / getRefreshRate());
mCallbackQueues = new CallbackQueue[CALLBACK_LAST + 1];
for (int i = 0; i <= CALLBACK_LAST; i++) {
mCallbackQueues[i] = new CallbackQueue();
}
}
FrameDisplayEventReceiver构造连接SurfaceFlinger的代码上头已经贴出
接着设置回调，直接看postCallbackDelayedInternal吧
private void postCallbackDelayedInternal(int callbackType,
Object action, Object token, long delayMillis) {
if (DEBUG) {
Log.d(TAG, "PostCallback: type=" + callbackType
+ ", action=" + action + ", token=" + token
+ ", delayMillis=" + delayMillis);
}
synchronized (mLock) {
final long now = SystemClock.uptimeMillis();
final long dueTime = now + delayMillis;
mCallbackQueues[callbackType].addCallbackLocked(dueTime, action, token);
if (dueTime <= now) {
scheduleFrameLocked(now);
} else {
Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_CALLBACK, action);
msg.arg1 = callbackType;
msg.setAsynchronous(true);
mHandler.sendMessageAtTime(msg, dueTime);
}
}
}
这个函数首先将callback以及执行时间添加到mCallbackQueues中，接着通过callback执行时间来决定是否立即执行scheduleFrameLocked：
private void scheduleFrameLocked(long now) {
if (!mFrameScheduled) {
mFrameScheduled = true;
if (USE_VSYNC) {
if (DEBUG) {
Log.d(TAG, "Scheduling next frame on vsync.");
}
// If running on the Looper thread, then schedule the vsync immediately,
// otherwise post a message to schedule the vsync from the UI thread
// as soon as possible.
if (isRunningOnLooperThreadLocked()) {
scheduleVsyncLocked();
} else {
Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_VSYNC);
msg.setAsynchronous(true);
mHandler.sendMessageAtFrontOfQueue(msg);
}
} else {
final long nextFrameTime = Math.max(
mLastFrameTimeNanos / TimeUtils.NANOS_PER_MS + sFrameDelay, now);
if (DEBUG) {
Log.d(TAG, "Scheduling next frame in " + (nextFrameTime - now) + " ms.");
}
Message msg = mHandler.obtainMessage(MSG_DO_FRAME);
msg.setAsynchronous(true);
mHandler.sendMessageAtTime(msg, nextFrameTime);
}
}
}
如果这个函数是在主线程调用的，直接调用scheduleVsyncLocked发送vsync请求：
private void scheduleVsyncLocked() {
mDisplayEventReceiver.scheduleVsync();
}
通过mFrameScheduled来控制，确保在一个vsync周期内，只发送一次vsync请求，因为vsync请求是一对一的，发送一次接收一次
通过上面可以看出，只要调用了Choreographer的postcallback相关函数，callback连同设置的执行时间就会被保存到mCallbackQueues队列，接着在callback执行时间点，判断是否发送了vsync请求，如果没有，则立即发送
最后，在下一个vsync中断到来时，SurfaceFlinger会把event及时的通知到Choreographer.FrameDisplayEventReceiver:
@Override
public void onVsync(long timestampNanos, int builtInDisplayId, int frame) {
...
mTimestampNanos = timestampNanos;
mFrame = frame;
Message msg = Message.obtain(mHandler, this);
msg.setAsynchronous(true);
mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);
}
@Override
public void run() {
mHavePendingVsync = false;
doFrame(mTimestampNanos, mFrame);
}
onVsync会给主线程发送消息，消息立即被执行，接着doFrame被调用：
void doFrame(long frameTimeNanos, int frame) {
synchronized (mLock) {
if (!mFrameScheduled) {
return; // no work to do
}
//vsync请求标记为false
mFrameScheduled = false;
mLastFrameTimeNanos = frameTimeNanos;
}
doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos);
doCallbacks(Choreographer.CALLBACK_ANIMATION, frameTimeNanos);
doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos);
...
}
Input, Animation, Traversal的callbacks队列中，在frameTimeNanos之前的callbacks会被取出，并依次执行
Handler同步屏障
为什么要有同步屏障？试想这个场景，你调用View.invalidate申请重绘，接着经过一系列的请求流转，到达了：
//ViewRootImpl.java
void invalidate() {
mDirty.set(0, 0, mWidth, mHeight);
if (!mWillDrawSoon) {
scheduleTraversals();
}
}
接着：
void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
mTraversalBarrier = mHandler.getLooper().postSyncBarrier();
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
if (!mUnbufferedInputDispatch) {
scheduleConsumeBatchedInput();
}
notifyRendererOfFramePending();
}
}
最终到达mChoreographer.postCallback，接着就像上面说过的，请求vsync notify，然后在下一vsync触发重绘？
有没有问题？常规来说肯定没问题，但是如果在invalidate之前，App其他代码调用Handler.sendMessageDelayed来发送一个delay的message，并且这个delay message正好在：
Message msg = mHandler.obtainMessage(MSG_DO_FRAME);
msg.setAsynchronous(true);
mHandler.sendMessageAtTime(msg, nextFrameTime);
这个MSG_DO_FRAME message之前被执行呢？这就有问题了，因为delay message的执行时间是不确定的，这就导致doframe的执行时间也会变的不确定，这肯定不行，必须要有一个机制把MSG_DO_FRAME的调用优先级提上来
这个机制就是Handler同步屏障，回过头来看ViewRootImpl.scheduleTraversals：
mTraversalBarrier = mHandler.getLooper().postSyncBarrier();
既然叫同步屏障，说明在调用上面这行代码后，在这个时间点之后所有的sync Message(默认状态)会被临时忽略，优先执行async message，上头的MSG_DO_FRAME message就是一条async message：
msg.setAsynchronous(true);
最终在ViewRootImpl.doTraversal中第一时间移除当前的同步屏障，使Handler分发恢复正常状态
void doTraversal() {
if (mTraversalScheduled) {
mTraversalScheduled = false;
//移除同步屏障
mHandler.getLooper().removeSyncBarrier(mTraversalBarrier);
...
}
}
接着简单看下同步屏障的原理，mHandler.getLooper().postSyncBarrier()最终调用：
//MessageQueue.java
int enqueueSyncBarrier(long when) {
// Enqueue a new sync barrier token.
// We don't need to wake the queue because the purpose of a barrier is to stall it.
synchronized (this) {
final int token = mNextBarrierToken++;
final Message msg = Message.obtain();
msg.markInUse();
msg.when = when;
msg.arg1 = token;
Message prev = null;
Message p = mMessages;
if (when != 0) {
while (p != null && p.when <= when) {
prev = p;
p = p.next;
}
}
if (prev != null) { // invariant: p == prev.next
msg.next = p;
prev.next = msg;
} else {
msg.next = p;
mMessages = msg;
}
return token;
}
}
在MessageQueue中添加一个target为null的Message,并按时间插入到Message队列中
接着看MessageQueue.next中相关代码(只分析异步message的处理逻辑)：
Message net(){
...
Message prevMsg = null;
Message msg = mMessages;
//如果msg.target为null，说明这是一个同步屏障
if (msg != null && msg.target == null) {
// Stalled by a barrier. Find the next asynchronous message in the queue.
//循环找出异步message
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
//有异步消息，但是还没到触发时间，设置pollTimeout时间，继续等待
if (now < msg.when) {
// Next message is not ready. Set a timeout to wake up when it is ready.
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
// Got a message.
mBlocked = false;
//如果存在同步堆栈，prevMsg是不可能为空的
if (prevMsg != null) {
//将异步message从队列中移除
prevMsg.next = msg.next;
} else {
mMessages = msg.next;
}
msg.next = null;
if (false) Log.v("MessageQueue", "Returning message: " + msg);
return msg;
}
} else {
// No more messages.
//如果msg为null，说明没找到异步message，继续监听等待
nextPollTimeoutMillis = -1;
}
...
}
帧率计算
public class FPSMonitor implements Choreographer.FrameCallback, Runnable{
//监控1秒内的帧数
private static final int MONITOR_TIME = 1000;
private HandlerThread handlerThread;
private long startTime = -1;
private long endTime = -1;
private long vSyncCount = 0;
private Handler workHandler;
public FPSMonitor(){
}
@Override
public void run() {
long duration = (endTime - startTime) / 1000000L;
float frame = 1000.0f * vSyncCount / duration;
Log.d("harish", "frame = " + frame + " duration = " + duration);
start();
}
@Override
public void doFrame(long frameTimeNanos) {
if (startTime == -1){
startTime = frameTimeNanos;
}
vSyncCount++;
long duration = (frameTimeNanos - startTime) / 1000000L;
if (duration >= MONITOR_TIME){
endTime = frameTimeNanos;
workHandler.post(this);
}else{
Choreographer.getInstance().postFrameCallback(this);
}
}
public void start(){
Log.d("harish", "FPSMonitor -- start");
if (handlerThread == null){
handlerThread = new HandlerThread("fps monitor thread");
handlerThread.start();
workHandler = new Handler(handlerThread.getLooper());
}
startTime = -1;
endTime = -1;
vSyncCount = 0;
Choreographer.getInstance().postFrameCallback(this);
}
}
7014
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
