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);
}
}