APP開發中，卡頓絕對優化的大頭，Google為了幫助開發者更好的定位問題，提供了不少工具，如Systrace、GPU呈現模式分析工具、Android Studio自帶的CPU Profiler等，主要是輔助定位哪段代碼、哪塊邏輯比較耗時，影響UI渲染，導致了卡頓。拿Profile GPU Rendering工具而言，它用一種很直觀的方式呈現可能超時的節點，該工具及其原理也是本文的重點：
CPU Profiler也會提供相似的圖表，本文主要圍繞著GPU呈現模式分析工具展開，簡析各個階段耗時統計的原理，同時總結下在使用及分析過程中也遇到的一些問題，可能算工具自身的BUG，這給分析帶來了不少困惑。比如如下幾點：
- GPU呈現模式分析工具跟Google官方文檔上似乎對應不起來（各個顏色代表的階段）
- CPU Profiler的函數調用似乎有些調用被合併了，並非獨立的調用棧（影響分析哪塊耗時）
- Skip Frame掉幀可能跟我們預想的不同，而且掉幀的統計也可能不準（主要是Vsync的延時部分，有些耗時操作導致卡頓了，但是可能沒有統計出掉幀）
GPU呈現模式分析工具簡介
Profile GPU Rendering工具的使用很簡單，就是直觀上看一幀的耗時有多長，綠線是16ms的閾值，超過了，可能會導致掉幀，這個跟VSYNC垂直同步信號有關係，當然，這個圖表並不是絕對嚴謹的（後文會說原因）。每個顏色的方塊代表不同的處理階段，先看下官方文檔給的映射表：
想要完全理解各個階段，要對硬件加速及GPU渲染有一定的瞭解，不過，有一點，必須先記心裡：雖名為 Profile GPU Rendering，但圖標中所有階段都發生在CPU中，不是GPU 。最終CPU將命令提交到 GPU 後觸發GPU異步渲染屏幕，之後CPU會處理下一幀，而GPU並行處理渲染，兩者硬件上算是並行。 不過，有些時候，GPU可能過於繁忙，不能跟上CPU的步伐，這個時候，CPU必須等待，也就是最終的swapbuffer部分，主要是最後的紅色及黃色部分（同步上傳的部分不會有問題，個人認為是因為在Android GPU與CPU是共享內存區域的），在等待時，將看到橙色條和紅色條中出現峰值，且命令提交將被阻止，直到 GPU 命令隊列騰出更多空間。
在使用Profile GPU Rendering工具時，我面臨第一個問題是：官方文檔的使用指導好像不太對。
Profile GPU Rendering工具顏色問題
真正使用該工具的時候，條形圖的顏色跟文檔好像對不上，為了測試，這裡先用一個小段代碼模擬場景，鑑別出各個階段，最後再分析源碼。從下往上，先忽略VSYNC部分，先看輸入事件，在一個自定義佈局中，為觸摸事件添加延時，並觸發重繪。
@Override public boolean dispatchTouchEvent(MotionEvent ev) { try { Thread.sleep(20); } catch (InterruptedException e) { } mTextView.setText("" + System.currentTimeMillis()); requestLayout(); super.dispatchTouchEvent(ev); return true; }
這個時候看到的超時部分主要是輸入事件引起的，進而確定下輸入事件的顏色：
輸入事件加個20ms延後，上圖紅色方塊部分正好映射到輸入事件耗時，這裡就能看到，輸入事件的顏色跟官方文檔的顏色對不上，如下圖
同樣，測量佈局的耗時也跟文檔對不上。為佈局測量加個耗時，即可驗證：
@Override protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { try { Thread.sleep(20); } catch (InterruptedException e) { } super.onMeasure(widthMeasureSpec, heightMeasureSpec); }
可以看到，上圖中測量佈局的耗時跟官方文檔的顏色也對不上。除此之外，似乎多出了第三部分耗時，這部分其實是VSYNC同步耗時，這部分耗時怎麼來的，真的存在耗時嗎？官方解釋似乎是連個連續幀之間的耗時，但是後面分析會發現，可能這個解釋同源碼對應不起來。
Miscellaneous
In addition to the time it takes the rendering system to perform its work, there’s an additional set of work that occurs on the main thread and has nothing to do with rendering. Time that this work consumes is reported as misc time. Misc time generally represents work that might be occurring on the UI thread between two consecutive frames of rendering.
其次，為什麼幾乎每個條形圖都有一個測量佈局耗時跟輸入事件耗時呢？為什麼是一一對應，而不是有多個？測量佈局是在Touch事件之後立即執行呢，還是等待下一個VSYNC信號到來再執行呢？這部主要牽扯到的內容：VSYNC垂直同步信號、ViewRootImpl、Choreographer、Touch事件處理機制，後面會逐步說明，先來看一下以上三個事件的耗時是怎麼統計的。
Miscellaneous--VSYNC延時
Profile GPU Rendering工具統計的入口在Choreographer類中，時機是VSYNC信號Message被執行，注意這裡是信號消息被執行，而不是信號到來，因為信號到來並不意味著立即被執行，因為VSYNC信號的申請是異步的，信號申請後線程繼續執行當前消息，SurfaceFlinger在下一次分發VSYNC的時候直接往APP UI線程的MessageQueue插入一條VSYNC到來的消息，而消息被插入後，並不會立即被執行，而是要等待之前的消息執行完畢後才會執行，而VSYNC延時其實就是VSYNC消息到來到被執行之間的延時。
void doFrame(long frameTimeNanos, int frame) { final long startNanos; synchronized (mLock) { if (!mFrameScheduled) { ... long intendedFrameTimeNanos = frameTimeNanos; <!--關鍵點1 設置vsync開始，並記錄起始時間 --> mFrameInfo.setVsync(intendedFrameTimeNanos, frameTimeNanos); mFrameScheduled = false; mLastFrameTimeNanos = frameTimeNanos; } try { // 開始處理輸入事件，並記錄起始時間 mFrameInfo.markInputHandlingStart(); doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos); // 開始處理動畫，並記錄起始時間 mFrameInfo.markAnimationsStart(); doCallbacks(Choreographer.CALLBACK_ANIMATION, frameTimeNanos); // 開始處理測量佈局，並記錄起始時間 mFrameInfo.markPerformTraversalsStart(); doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos); } finally { }
這裡的 VSYNC延時其實是 mFrameInfo.markInputHandlingStart - frameTimeNanos，而frameTimeNanos是VSYNC信號到達的時間戳，如下
private final class FrameDisplayEventReceiver extends DisplayEventReceiver implements Runnable { private boolean mHavePendingVsync; private long mTimestampNanos; private int mFrame; public FrameDisplayEventReceiver(Looper looper) { super(looper); } @Override public void onVsync(long timestampNanos, int builtInDisplayId, int frame) { ... <!--存下時間戳，並往UI的MessageQueue發送一個消息--> 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() { <!--將之前的時間戳作為參數傳遞給doFrame--> mHavePendingVsync = false; doFrame(mTimestampNanos, mFrame); } }
onVsync是VSYNC信號到達的時候在Native層回調Java層的方法，其實是MessegeQueue的native消息隊列那一套，並且VSYNC要一個執行完，下一個才會生效，否則下一個VSYNC只能在隊列中等待，所以之前說的？？？第三部分延時就是VSYNC延時，但是這部分不應該被算到渲染中去，另外根據寫法，VSYNC延時可能也有很大出入。看doFrame中有一部分是統計掉幀的，個人理解也許這部分統計並不是特別靠譜，下面看下掉幀的部分。
掉幀Skiped Frame同Vsync延時耗時的關係
有些APM檢測工具通過將Choreographer的SKIPPED_FRAME_WARNING_LIMIT設置為1，來達到掉幀檢測的目的，即如下設置：
try { Field field = Choreographer.class.getDeclaredField("SKIPPED_FRAME_WARNING_LIMIT"); field.setAccessible(true); field.set(Choreographer.class, 0); } catch (Throwable e) { }
如果出現卡頓，在log日誌中就能看到如下信息
感覺這裡並不是太嚴謹，看源碼如下：
void doFrame(long frameTimeNanos, int frame) { final long startNanos; synchronized (mLock) { if (!mFrameScheduled) { return; // no work to do } long intendedFrameTimeNanos = frameTimeNanos; <!--skip frame關鍵點 --> startNanos = System.nanoTime(); final long jitterNanos = startNanos - frameTimeNanos; if (jitterNanos >= mFrameIntervalNanos) { final long skippedFrames = jitterNanos / mFrameIntervalNanos; if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) { Log.i(TAG, "Skipped " + skippedFrames + " frames! " + "The application may be doing too much work on its main thread."); } ... }
可以看到跳幀檢測的算法就是：Vsync信號延時/16ms，有多少個，就算跳幾幀。Vsync信號到了後，重繪並不一定會立刻執行，因為UI線程可能被阻塞再某個地方，比如在Touch事件中，觸發了重繪，之後繼續執行了一個耗時操作，這個時候，必然會導致Vsync信號被延時執行，跳幀日誌就會被打印，如下
@Override public boolean dispatchTouchEvent(MotionEvent ev) { super.dispatchTouchEvent(ev); scrollTo(0,new Random().nextInt(15)); try { Thread.sleep(40); } catch (InterruptedException e) { } return true; }
可以看到，顏色2的部分就是Vsync信信號延時，這個時候會有掉幀日誌。
但是如果將觸發UI重繪的消息放到延時操作後面呢？毫無疑問，卡頓依然有，但這時會發生一個有趣的現象，跳幀沒了，系統認為沒有幀丟失，代碼如下：
@Override public boolean dispatchTouchEvent(MotionEvent ev) { super.dispatchTouchEvent(ev); try { Thread.sleep(40); } catch (InterruptedException e) { } scrollTo(0,new Random().nextInt(15)); return true; }
可以看到，圖中幾乎沒有Vsync信信號延時，這是為什麼？因為下一個VSYNC信號的申請是由scrollTo觸發，觸發後並沒有什麼延時操作，直到VSYNC信號到來後，立即執行doFrame，這個之間的延時很少，系統就認為沒有掉幀，但是其實卡頓依舊。因為整體來看，一段時間內的幀率是相同的，整體示意如下：
以上就是scrollTo在延時前後的區別，兩種其實都是掉幀的，但是日誌統計的跳幀卻出現了問題，而且，每一幀真正的耗也並不是我們看到的樣子，個人覺得這可能算是工具的一個BUG，不能很精確的反應卡頓問題，依靠這個做FPS偵測，應該也都有問題。比如滾動時候，處理耗時操作後，再更新UI，這種方式是檢測不出跳幀的，當然不排除有其他更好的方案。下面看一下Input時間耗時，之前，針對Touch事件的耗時都是直接用了，並未分析為何一幀裡面會有且只有一個Touch事件耗時？是否所有的Touch事件都被統計了呢？Touch事件如何影響GPU 統計工具呢？
輸入事件耗時分析
輸入事件處理機制：InputManagerService捕獲用戶輸入，通過Socket將事件傳遞給APP端（往UI線程的消息隊列裡插入消息）。對於不同的觸摸事件有不同的處理機制：對於Down、UP事件，APP端需要立即處理，對於Move事件，要結合重繪事件一併處理，其實就是要等到下一次VSYNC到來，分批處理。可以認為只有MOVE事件才被GPU柱狀圖統計到裡面，UP、DOWN事件被立即執行，不會等待VSYNC跟UI重繪一起執行。。這裡不妨先看一個各個階段耗時統計的依據，GPU 呈現工具圖表的繪製是在native層完成的，其各個階段統計示意如下：
FrameInfoVisualizer.cpp
前文分析的VSYNC延時其實就是 FrameInfoIndex::HandleInputStart -FrameInfoIndex::IntendedVsync 顏色是0x00796B，輸入事件耗時其實就是FrameInfoIndex::PerformTraversalsStart -FrameInfoIndex::HandleInputStart，不過這裡只有7種，跟文檔的8中對應不上。在doFrame可以得到驗證：
void doFrame(long frameTimeNanos, int frame) { final long startNanos; synchronized (mLock) { if (!mFrameScheduled) { ... // 設置vsync開始，並記錄起始時間 <!--關鍵點1 --> mFrameInfo.setVsync(intendedFrameTimeNanos, frameTimeNanos); mFrameScheduled = false; mLastFrameTimeNanos = frameTimeNanos; } try { // 開始處理輸入事件，並記錄起始時間 mFrameInfo.markInputHandlingStart(); doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos); // 開始處理動畫，並記錄起始時間 mFrameInfo.markAnimationsStart(); doCallbacks(Choreographer.CALLBACK_ANIMATION, frameTimeNanos); // 開始處理測量佈局，並記錄起始時間 mFrameInfo.markPerformTraversalsStart(); doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos); } finally { }
如上代碼很簡單，但是在利用CPU Profiler看函數調用棧的時候，卻發現很多問題。為Touch事件處理加入延時後，CPU Profiler看到的調用棧如下：
這個棧是怎麼回事？不是說好的，一次VSYNC信號調用一次doFrame，而一次doFrame會依次執行不同類型的CallBack，但是看以上的調用棧，怎麼是穿插著來啊？這就尷尬了，莫非是BUG，事實證明，確實真可能是CPU Profiler的BUG。 證據就是doFrame的調用次數跟CPU Profiler 中統計的次數的壓根對應不起來，doFrame的次數明顯要很多。
也就是說CPU Profiler應該將一些類似的函數調用給整合分組了，所以看起來好像一個Vsync執行了一次doFrame，但是卻執行了很多CallBack，實際上，默認情況下，每種類型的CallBack在一次VSYNC期間，一般最多執行一次。垂直同步信號機制下，在下一個垂直同步信號到來之前，Android系統最多隻能處理一個MOVE的Patch、一個繪製請求、一次動畫更新。先看看Touch時間處理機制，上文的dispatchTouchEvent如何被執行的呢？
@Override public boolean dispatchTouchEvent(MotionEvent ev) { try { Thread.sleep(20); } catch (InterruptedException e) { } mTextView.setText("" + System.currentTimeMillis()); requestLayout(); super.dispatchTouchEvent(ev); return true; }
InputManagerService收到Touch事件後，通過Socket傳遞給APP端，APP端的UI Loop會將事件讀取出來，在native預處理下，將事件發送給Java層，
public abstract class InputEventReceiver { ... public final boolean consumeBatchedInputEvents(long frameTimeNanos) { if (mReceiverPtr == 0) { Log.w(TAG, "Attempted to consume batched input events but the input event " + "receiver has already been disposed."); } else { return nativeConsumeBatchedInputEvents(mReceiverPtr, frameTimeNanos); } return false; } // Called from native code. @SuppressWarnings("unused") private void dispatchInputEvent(int seq, InputEvent event) { mSeqMap.put(event.getSequenceNumber(), seq); onInputEvent(event); } // NativeInputEventReceiver // Called from native code. @SuppressWarnings("unused") private void dispatchBatchedInputEventPending() { onBatchedInputEventPending(); } ... }
如果是DOWN、UP事件，調用dispatchInputEvent，如果是MOVE事件，則被封裝成Batch，調用dispatchBatchedInputEventPending，對於DOWN、UP事件會調用子類的enqueueInputEvent立即執行
final class WindowInputEventReceiver extends InputEventReceiver { public WindowInputEventReceiver(InputChannel inputChannel, Looper looper) { super(inputChannel, looper); } @Override public void onInputEvent(InputEvent event) { <!--關鍵點 最後一個參數是true--> enqueueInputEvent(event, this, 0, true); } void enqueueInputEvent(InputEvent event, InputEventReceiver receiver, int flags, boolean processImmediately) { adjustInputEventForCompatibility(event); <!--獲取輸入事件--> QueuedInputEvent q = obtainQueuedInputEvent(event, receiver, flags); ... <!--是否立即執行--> if (processImmediately) { doProcessInputEvents(); } else { scheduleProcessInputEvents(); } }
對於DOWN UP事件會調用 doProcessInputEvents立即執行， 而對於dispatchBatchedInputEventPending則調用WindowInputEventReceiver的onBatchedInputEventPending延遲到下一個VSYNC執行：
final class WindowInputEventReceiver extends InputEventReceiver { public WindowInputEventReceiver(InputChannel inputChannel, Looper looper) { super(inputChannel, looper); } ... @Override public void onBatchedInputEventPending() { if (mUnbufferedInputDispatch) { super.onBatchedInputEventPending(); } else { scheduleConsumeBatchedInput(); } }
mUnbufferedInputDispatch默認都是false，為了提高執行效率，發行版的源碼該參數都是false，所以這裡會執行scheduleConsumeBatchedInput：
void scheduleConsumeBatchedInput() { <!--mConsumeBatchedInputScheduled保證了當前Touch事件被執行前，不會再有Batch事件被插入--> if (!mConsumeBatchedInputScheduled) { mConsumeBatchedInputScheduled = true; <!--通過Choreographer暫存回調，同時請求VSYNC信號--> mChoreographer.postCallback(Choreographer.CALLBACK_INPUT, mConsumedBatchedInputRunnable, null); } }
scheduleConsumeBatchedInput中的邏輯保證了每次VSYNC間，最多隻有一個Batch被處理。Choreographer.CALLBACK_INPUT類型的CallBack是輸入事件耗時統計的對象，只有Batch類Touch事件（MOVE事件）會涉及到這個類型，所以個人理解GPU呈現工具統計的輸入耗時只針對MOVE事件，直觀上也比較好理解：MOVE滾動或者滑動事件一般都是要伴隨UI更新，這個持續的流程才是幀率關心的重點，如果不是持續更新，FPS（幀率）沒有意義。繼續看Choreographer.postCallback函數
private void postCallbackDelayedInternal(int callbackType, Object action, Object token, long delayMillis) { synchronized (mLock) { final long now = SystemClock.uptimeMillis(); final long dueTime = now + delayMillis; <!--添加回調--> mCallbackQueues[callbackType].addCallbackLocked(dueTime, action, token); <!--ViewrootImpl過來的一般都是立即執行，直接申請Vsync信號--> if (dueTime <= now) { scheduleFrameLocked(now); } ... }
Choreographer為Touch事件添加一個CallBack，並加入到緩存隊列中，同時異步申請VSYNC，等到信號到來後，才會處理該Touch事件的回調。VSYNC信號到來後，Choreographer最先執行doFrame中的doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos)，該函數會調用ConsumeBatchedInputRunnable的run函數，最終調用doConsumeBatchedInput處理Batch事件：
void doConsumeBatchedInput(long frameTimeNanos) { <!--標記事件被處理，新的事件才有機會被添加進來--> if (mConsumeBatchedInputScheduled) { mConsumeBatchedInputScheduled = false; if (mInputEventReceiver != null) { if (mInputEventReceiver.consumeBatchedInputEvents(frameTimeNanos) && frameTimeNanos != -1) { ... } } <!--處理事件--> doProcessInputEvents(); } }
doProcessInputEvents會走事件分發機制最終回調到對應的 dispatchTouchEvent完成Touch事件的處理。這個有個很重要的點：如果在處理Batch事件的時候觸發了UI重繪（非常常見），比如MOVE事件一般都伴隨著列表滾動，那麼這個重繪CallBack會立即被添加到Choreographer.CALLBACK_TRAVERSAL隊列中，並在執行完當前Choreographer.CALLBACK_INPUT回調後，立刻執行，這就是為什麼CPU Profiler中總能看到一個一個Touch事件後面跟著一個UI重繪事件。拿上文例子而言requestLayout()最終會調用ViewRootImpl的:
@Override public void requestLayout() { if (!mHandlingLayoutInLayoutRequest) { checkThread(); mLayoutRequested = true; scheduleTraversals(); } }
從而調用scheduleTraversals，可以看到這裡也用了一個標記mTraversalScheduled，保證一次VSYNC中最多一次重繪：
void scheduleTraversals() { // 重複多次調用invalid requestLayout只會標記一次，等到下一次Vsync信號到，只會執行執行一次 if (!mTraversalScheduled) { mTraversalScheduled = true; <!--添加一個柵欄，阻止同步消息執行--> mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier(); mChoreographer.postCallback( Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null); <!--=更新UI的時候，通常伴隨MOVE事件，預先請求一次Vsync信號，不用真的等到消息到來再請求，提高吞吐率--> // mUnbufferedInputDispatch =false 一般都是false 所以會執行scheduleConsumeBatchedInput， if (!mUnbufferedInputDispatch) { scheduleConsumeBatchedInput(); } notifyRendererOfFramePending(); pokeDrawLockIfNeeded(); } }
對於重繪事件而言，通過mChoreographer.postCallback直接添加一個CallBack，同時請求Vsync信號，一般而言scheduleTraversals中的scheduleConsumeBatchedInput請求VSYNC是無效，因為連續兩次請求VSYNC的話，只有一次是有效的，scheduleConsumeBatchedInput只是為後續的Touch事件提前佔個位置。剛開始執行Touch事件的時候，mCallbackQueues信息是這樣的：
可以看到，開始並沒有Choreographer.CALLBACK_TRAVERSAL類型的回調，在處理Touch事件的時候，觸發了重繪，動態增加了Choreographer.CALLBACK_TRAVERSAL類CallBack，如下
那麼，在當前MOVE時間處理完畢後，doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos)會被執行，剛才被加入的重繪CallBack會立即執行，而不會等待到下一次Vsync信號的到來，這就是之前MOVE跟重繪一一對應，並且重繪總是在MOVE事件之後執行的原理，同時也看到Choreographer用了不少標記，保證一次VSYNC期間，最多有一個MOVE事件、重回時間被依次執行（先忽略動畫）。以上兩個是GPU玄學曲線中比較擰巴的地方，剩餘的幾個階段其實就比較清晰了。
CALLBACK_ANIMATION類CallBack耗時 （似乎被算到Touch事件耗時中去了）
一般MOVE事件伴隨Scroll，比如List，scroll的時候可能觸發了所謂的動畫，
public void scrollTo(int x, int y) { if (mScrollX != x || mScrollY != y) { int oldX = mScrollX; int oldY = mScrollY; mScrollX = x; mScrollY = y; invalidateParentCaches(); onScrollChanged(mScrollX, mScrollY, oldX, oldY); if (!awakenScrollBars()) { postInvalidateOnAnimation(); } } }
最終調用Choreogtapher的postInvalidateOnAnimation創建Choreographer.CALLBACK_ANIMATION類型回調
public void postInvalidateOnAnimation() { final AttachInfo attachInfo = mAttachInfo; if (attachInfo != null) { attachInfo.mViewRootImpl.dispatchInvalidateOnAnimation(this); } } final class InvalidateOnAnimationRunnable implements Runnable { ... private void postIfNeededLocked() { if (!mPosted) { mChoreographer.postCallback(Choreographer.CALLBACK_ANIMATION, this, null); mPosted = true; } }
只是調用View的invalidate，不怎麼耗時：
final class InvalidateOnAnimationRunnable implements Runnable { @Override public void run() { final int viewCount; final int viewRectCount; synchronized (this) { ... for (int i = 0; i < viewCount; i++) { mTempViews[i].invalidate(); mTempViews[i] = null; }
當然，如果這裡有自定義動畫的話，就不一樣了。但是，就GPU呈現模式統計耗時而言，卻並非像官方文檔說的那樣，似乎壓根沒有這部分耗時，而源碼中也只有七段，如下圖：
重寫invalidate函數驗證，會發現，這部分耗時會被歸到輸入事件耗時裡面：
@Override public void invalidate() { super.invalidate(); try { Thread.sleep(10); } catch (InterruptedException e) { } }
也就是說下面的官方說明可能是錯誤的，因為真機上沒看到這部分耗時，或者說，這部分耗時被歸結到Touch事件耗時中去了，從源碼中看好像也是這樣。
測量、佈局、繪製耗時
走到測量重繪的時候，整個流程已經清晰了，在UI線程中測量重繪耗時很直觀，也很忠誠，用多少就是多少，沒有Vsync那樣彆扭的問題，沒什麼分析必要，不過需要注意的是，這裡的Draw僅僅是構建DisplayList數，也可以看做是幫助創建OpenGL繪製命令及預處理些數據，沒有真正渲染，到這裡為止，都是在UI線程中進行的，剩下三個階段Sync/upload、Issue commands、swap buffers都是在RenderThread線程。
Sync/upload（同步和上傳 ）耗時
The Sync & Upload metric represents the time it takes to transfer bitmap objects from CPU memory to GPU memory during the current frame.
As different processors, the CPU and the GPU have different RAM areas dedicated to processing. When you draw a bitmap on Android, the system transfers the bitmap to GPU memory before the GPU can render it to the screen. Then, the GPU caches the bitmap so that the system doesn’t need to transfer the data again unless the texture gets evicted from the GPU texture cache.
表示將位圖信息上傳到 GPU 所花的時間，不過Android手機上 CPU跟GPU是共享物理內存的，這裡的上傳個人理解成拷貝，這樣的話，CPU跟GPU所使用的數據就相互獨立開來，兩者並行處理的時候不會有什麼同步問題，耗時大的話，說明需要上傳位圖信息過多，這裡個人感覺主要是給紋理、材質準備的素材。
Issue commands
The Issue Commands segment represents the time it takes to issue all of the commands necessary for drawing display lists to the screen.
這部分耗時主要是CPU將繪製命令發送給GPU，之後，GPU才能根據這些OpenGL命令進行渲染。這部分主要是CPU調用OpenGL ES API來實現。
swapBuffers耗時
Once Android finishes submitting all its display list to the GPU, the system issues one final command to tell the graphics driver that it's done with the current frame. At this point, the driver can finally present the updated image to the screen.
之前的GPU命令被issue完畢後，CPU一般會發送最後一個命令給GPU，告訴GPU當前命令發送完畢，可以處理，GPU一般而言需要返回一個確認的指令，不過，這裡並不代表GPU渲染完畢，僅僅是通知CPU，GPU有空開始渲染而已，並未渲染完成，但是之後的問題APP端無需關心了，CPU可以繼續處理下一幀的任務了。如果GPU比較忙，來不及回覆通知，則CPU需要阻塞等待，直到收到通知，才會喚起當前阻塞的Render線程，繼續處理下一條消息，這個階段是在swapBuffers中完成的。這三部分耗時統計源碼簡析如下，可進一步參考Android硬件加速（二）-RenderThread與OpenGL GPU渲染。
OpenGL GPU Profiler源碼 （非真機，軟件模擬的OpenGL庫libagl）
GPU Profiler繪製主要是通過FrameInfoVisualizer的draw函數實現：
void FrameInfoVisualizer::draw(OpenGLRenderer* canvas) { RETURN_IF_DISABLED(); ... // 繪製一條條,dubug模式中可以開啟 if (mType == ProfileType::Bars) { // Patch up the current frame to pretend we ended here. CanvasContext // will overwrite these values with the real ones after we return. // This is a bit nicer looking than the vague green bar, as we have // valid data for almost all the stages and a very good idea of what // the issue stage will look like, too FrameInfo& info = mFrameSource.back(); info.markSwapBuffers(); info.markFrameCompleted(); <!--計算寬度及高度--> initializeRects(canvas->getViewportHeight(), canvas->getViewportWidth()); drawGraph(canvas); drawThreshold(canvas); } }
這裡用的色值及用的就是之前說的7種，這部分代碼提前markSwapBuffers跟markFrameCompleted，看註釋，CanvasContext後面用real耗時進行校準：
void FrameInfoVisualizer::drawGraph(OpenGLRenderer* canvas) { SkPaint paint; for (size_t i = 0; i < Bar.size(); i++) { nextBarSegment(Bar[i].start, Bar[i].end); paint.setColor(Bar[i].color | BAR_FAST_ALPHA); canvas->drawRects(mFastRects.get(), mNumFastRects * 4, &paint); paint.setColor(Bar[i].color | BAR_JANKY_ALPHA); canvas->drawRects(mJankyRects.get(), mNumJankyRects * 4, &paint); } }
之前簡析過Java層四種耗時，現在看看最後三種耗時的統計點：
<!--同步開始--> void CanvasContext::prepareTree(TreeInfo& info, int64_t* uiFrameInfo, int64_t syncQueued) { mRenderThread.removeFrameCallback(this); <!--將Java層拷貝--> mCurrentFrameInfo->importUiThreadInfo(uiFrameInfo); mCurrentFrameInfo->set(FrameInfoIndex::SyncQueued) = syncQueued; // 這裡表示開始同步上傳位圖 mCurrentFrameInfo->markSyncStart(); ... mRootRenderNode->prepareTree(info); ... }
markSyncStart標記著上傳位圖開始，通過prepareTree將Texture相關位圖拷貝給GPU可用內存區域後，CanvasContext::draw進一步issue GPU命令到GPU緩衝區：
void CanvasContext::draw() { ... <!--Issue的開始--> mCurrentFrameInfo->markIssueDrawCommandsStart(); ... <!--GPU呈現模式的圖表繪製--> profiler().draw(mCanvas); <!--像GPU發送命令,可能是對應的GPU驅動，緩存等--> mCanvas->drawRenderNode(mRootRenderNode.get(), outBounds); <!--命令發送完畢--> mCurrentFrameInfo->markSwapBuffers(); if (drew) { swapBuffers(dirty, width, height); } // TODO: Use a fence for real completion? <!--這裡只有用GPU fence才能獲取真正的耗時，不然還是無效的，看每個手機廠家的實現了--> mCurrentFrameInfo->markFrameCompleted(); mJankTracker.addFrame(*mCurrentFrameInfo); mRenderThread.jankTracker().addFrame(*mCurrentFrameInfo); }
markIssueDrawCommandsStart 標記著issue命令開始，而mCanvas->drawRenderNode負責真正issue命令到緩衝區，issue結束後，通知GPU繪製，同時將圖層移交SurfaceFlinger，這部分是通過swapBuffers來實現的，在真機上需要藉助Fence機制來同步GPU跟CPU，參考Android硬件加速（二）-RenderThread與OpenGL GPU渲染。由於後三部分可控性比較小，不再分析，有興趣可以自己查查OpenGL及GPU相關知識。
總結
- GPU Profiler的色值跟官方文檔對不起來
- 動畫耗時並沒有單獨的色塊，而是被歸併到Touch事件耗時中
- Studio自帶的CPU Profiler有問題，存在合併操作的BUG
- 源碼中關於跳幀的統計可能不準，他統計的不是跳幀，而是VSYNC的延時
- Chorgropher通過各種標記保證了一個VSYNC信號中最多隻有一個Touch事件、一個重繪事件、一次動畫更新
- GPU呈現模式的圖表僅供參考，並不完全正確。
