自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

Vsync 信號機制和 UI 刷新流程

作者： Android開發(fā)編程
移動開發(fā) Android
Android系統(tǒng)每隔16ms發(fā)出VSYNC信號，觸發(fā)對UI進行渲染，VSync是Vertical Synchronization(垂直同步)的縮寫，是一種在PC上很早就廣泛使用的技術，可以簡單的把它認為是一種定時中斷。而在Android 4.1(JB)中已經(jīng)開始引入VSync機制。

[[439732]]

 

前言

屏幕刷新幀率不穩(wěn)定，掉幀嚴重，無法保證每秒60幀，導致屏幕畫面撕裂;

今天我們來講解下VSYNC機制和UI刷新流程

一、 Vsync信號詳解

1、屏幕刷新相關知識點

  • 屏幕刷新頻率：一秒內(nèi)屏幕刷新的次數(shù)(一秒內(nèi)顯示了多少幀的圖像)，單位 Hz(赫茲)，如常見的 60 Hz。刷新頻率取決于硬件的固定參數(shù)(不會變的);
  • 逐行掃：顯示器并不是一次性將畫面顯示到屏幕上，而是從左到右邊，從上到下逐行掃描，順序顯示整屏的一個個像素點，不過這一過程快到人眼無法察覺到變化。以 60 Hz 刷新率的屏幕為例，這一過程即 1000 / 60 ≈ 16ms;
  • 幀率：表示 GPU 在一秒內(nèi)繪制操作的幀數(shù)，單位 fps。例如在電影界采用 24 幀的速度足夠使畫面運行的非常流暢。而 Android 系統(tǒng)則采用更加流程的 60 fps，即每秒鐘GPU最多繪制 60 幀畫面。幀率是動態(tài)變化的，例如當畫面靜止時，GPU 是沒有繪制操作的，屏幕刷新的還是buffer中的數(shù)據(jù)，即GPU最后操作的幀數(shù)據(jù);
  • 屏幕流暢度：即以每秒60幀(每幀16.6ms)的速度運行，也就是60fps，并且沒有任何延遲或者掉幀;
  • FPS：每秒的幀數(shù);
  • 丟幀：在16.6ms完成工作卻因各種原因沒做完，占了后n個16.6ms的時間，相當于丟了n幀;

2、VSYNC機制

VSync機制：Android系統(tǒng)每隔16ms發(fā)出VSYNC信號，觸發(fā)對UI進行渲染，VSync是Vertical Synchronization(垂直同步)的縮寫，是一種在PC上很早就廣泛使用的技術，可以簡單的把它認為是一種定時中斷。而在Android 4.1(JB)中已經(jīng)開始引入VSync機制;

VSync機制下的繪制過程;CPU/GPU接收vsync信號，Vsync每16ms一次，那么在每次發(fā)出Vsync命令時，CPU都會進行刷新的操作。也就是在每個16ms的第一時間，CPU就會響應Vsync的命令，來進行數(shù)據(jù)刷新的動作。CPU和GPU的刷新時間，和Display的FPS是一致的。因為只有到發(fā)出Vsync命令的時候，CPU和GPU才會進行刷新或顯示的動作。CPU/GPU接收vsync信號提前準備下一幀要顯示的內(nèi)容，所以能夠及時準備好每一幀的數(shù)據(jù)，保證畫面的流暢;

可見vsync信號沒有提醒CPU/GPU工作的情況下，在第一個16ms之內(nèi)，一切正常。然而在第二個16ms之內(nèi)，幾乎是在時間段的最后CPU才計算出了數(shù)據(jù)，交給了Graphics Driver,導致GPU也是在第二段的末尾時間才進行了繪制，整個動作延后到了第三段內(nèi)。從而影響了下一個畫面的繪制。這時會出現(xiàn)Jank(閃爍，可以理解為卡頓或者停頓)。這時候CPU和GPU可能被其他操作占用了，這就是卡頓出現(xiàn)的原因;

二、UI刷新原理流程

1、VSYNC流程示意

當我們通過setText改變TextView內(nèi)容后，UI界面不會立刻改變，APP端會先向VSYNC服務請求，等到下一次VSYNC信號觸發(fā)后，APP端的UI才真的開始刷新，基本流程如下：

setText最終調(diào)用invalidate申請重繪，最后會通過ViewParent遞歸到ViewRootImpl的invalidate，請求VSYNC，在請求VSYNC的時候，會添加一個同步柵欄，防止UI線程中同步消息執(zhí)行，這樣做為了加快VSYNC的響應速度，如果不設置，VSYNC到來的時候，正在執(zhí)行一個同步消息;

2、view的invalidate

View會遞歸的調(diào)用父容器的invalidateChild，逐級回溯，最終走到ViewRootImpl的invalidate

  1. View.java 
  2.  void invalidateInternal(int l, int t, int r, int b, boolean invalidateCache, 
  3.             boolean fullInvalidate) { 
  4.             // Propagate the damage rectangle to the parent view. 
  5.             final AttachInfo ai = mAttachInfo; 
  6.             final ViewParent p = mParent; 
  7.             if (p != null && ai != null && l < r && t < b) { 
  8.                 final Rect damage = ai.mTmpInvalRect; 
  9.                 damage.set(l, t, r, b); 
  10.                 p.invalidateChild(this, damage); 
  11.             } 
  12. ViewRootImpl.java 
  13. void invalidate() { 
  14.     mDirty.set(0, 0, mWidth, mHeight); 
  15.     if (!mWillDrawSoon) { 
  16.         scheduleTraversals(); 
  17.     } 
  18. } 

ViewRootImpl會調(diào)用scheduleTraversals準備重繪，但是，重繪一般不會立即執(zhí)行，而是往Choreographer的Choreographer.CALLBACK_TRAVERSAL隊列中添加了一個mTraversalRunnable，同時申請VSYNC，這個mTraversalRunnable要一直等到申請的VSYNC到來后才會被執(zhí)行;

3、scheduleTraversals

  1. ViewRootImpl.java 
  2.  // 將UI繪制的mTraversalRunnable加入到下次垂直同步信號到來的等待callback中去 
  3.  // mTraversalScheduled用來保證本次Traversals未執(zhí)行前，不會要求遍歷兩邊，浪費16ms內(nèi)，不需要繪制兩次 
  4. void scheduleTraversals() { 
  5.     if (!mTraversalScheduled) { 
  6.         mTraversalScheduled = true; 
  7.         // 防止同步柵欄，同步柵欄的意思就是攔截同步消息 
  8.         mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier(); 
  9.         // postCallback的時候，順便請求vnsc垂直同步信號scheduleVsyncLocked 
  10.         mChoreographer.postCallback( 
  11.                 Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null); 
  12.          <!--添加一個處理觸摸事件的回調(diào)，防止中間有Touch事件過來--> 
  13.         if (!mUnbufferedInputDispatch) { 
  14.             scheduleConsumeBatchedInput(); 
  15.         } 
  16.         notifyRendererOfFramePending(); 
  17.         pokeDrawLockIfNeeded(); 
  18.     } 
  19. } 

4、申請VSYNC同步信號

  1. Choreographer.java 
  2. private void postCallbackDelayedInternal(int callbackType, 
  3.         Object action, Object token, long delayMillis) { 
  4.     synchronized (mLock) { 
  5.         final long now = SystemClock.uptimeMillis(); 
  6.         final long dueTime = now + delayMillis; 
  7.         mCallbackQueues[callbackType].addCallbackLocked(dueTime, action, token); 
  8.         if (dueTime <= now) { 
  9.         <!--申請VSYNC同步信號--> 
  10.             scheduleFrameLocked(now); 
  11.         }  
  12.     } 
  13. } 

5、scheduleFrameLocked

  1. // mFrameScheduled保證16ms內(nèi)，只會申請一次垂直同步信號 
  2. // scheduleFrameLocked可以被調(diào)用多次，但是mFrameScheduled保證下一個vsync到來之前，不會有新的請求發(fā)出 
  3. // 多余的scheduleFrameLocked調(diào)用被無效化 
  4. private void scheduleFrameLocked(long now) { 
  5.     if (!mFrameScheduled) { 
  6.         mFrameScheduled = true; 
  7.         if (USE_VSYNC) { 
  8.             if (isRunningOnLooperThreadLocked()) { 
  9.                 scheduleVsyncLocked(); 
  10.             } else { 
  11.                 // 因為invalid已經(jīng)有了同步柵欄，所以必須mFrameScheduled，消息才能被UI線程執(zhí)行 
  12.                 Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_VSYNC); 
  13.                 msg.setAsynchronous(true); 
  14.                 mHandler.sendMessageAtFrontOfQueue(msg); 
  15.             } 
  16.         }   
  17.     } 
  18. } 
  • 在當前申請的VSYNC到來之前，不會再去請求新的VSYNC，因為16ms內(nèi)申請兩個VSYNC沒意義;
  • 再VSYNC到來之后，Choreographer利用Handler將FrameDisplayEventReceiver封裝成一個異步Message，發(fā)送到UI線程的MessageQueue;

6、FrameDisplayEventReceiver

  1. private final class FrameDisplayEventReceiver extends DisplayEventReceiver 
  2.             implements Runnable { 
  3.         private boolean mHavePendingVsync; 
  4.         private long mTimestampNanos; 
  5.         private int mFrame; 
  6.         public FrameDisplayEventReceiver(Looper looper) { 
  7.             super(looper); 
  8.         } 
  9.         @Override 
  10.         public void onVsync(long timestampNanos, int builtInDisplayId, int frame) { 
  11.             long now = System.nanoTime(); 
  12.             if (timestampNanos > now) { 
  13.             <!--正常情況，timestampNanos不應該大于now，一般是上傳vsync的機制出了問題--> 
  14.                 timestampNanos = now; 
  15.             } 
  16.             <!--如果上一個vsync同步信號沒執(zhí)行，那就不應該相應下一個（可能是其他線程通過某種方式請求的）--> 
  17.               if (mHavePendingVsync) { 
  18.                 Log.w(TAG, "Already have a pending vsync event.  There should only be " 
  19.                         + "one at a time."); 
  20.             } else { 
  21.                 mHavePendingVsync = true; 
  22.             } 
  23.             <!--timestampNanos其實是本次vsync產(chǎn)生的時間，從服務端發(fā)過來--> 
  24.             mTimestampNanos = timestampNanos; 
  25.             mFrame = frame; 
  26.             Message msg = Message.obtain(mHandler, this); 
  27.             <!--由于已經(jīng)存在同步柵欄，所以VSYNC到來的Message需要作為異步消息發(fā)送過去--> 
  28.             msg.setAsynchronous(true); 
  29.             mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS); 
  30.         } 
  31.         @Override 
  32.         public void run() { 
  33.             mHavePendingVsync = false; 
  34.             <!--這里的mTimestampNanos其實就是本次Vynsc同步信號到來的時候，但是執(zhí)行這個消息的時候，可能延遲了--> 
  35.             doFrame(mTimestampNanos, mFrame); 
  36.         } 
  37.     } 
  • 之所以封裝成異步Message，是因為前面添加了一個同步柵欄，同步消息不會被執(zhí)行;
  • UI線程被喚起，取出該消息，最終調(diào)用doFrame進行UI刷新重繪;

7、doFrame

  1. void doFrame(long frameTimeNanos, int frame) { 
  2.     final long startNanos; 
  3.     synchronized (mLock) { 
  4.     <!--做了很多東西，都是為了保證一次16ms有一次垂直同步信號，有一次input 、刷新、重繪--> 
  5.         if (!mFrameScheduled) { 
  6.             return; // no work to do 
  7.         } 
  8.        long intendedFrameTimeNanos = frameTimeNanos; 
  9.         startNanos = System.nanoTime(); 
  10.         final long jitterNanos = startNanos - frameTimeNanos; 
  11.         <!--檢查是否因為延遲執(zhí)行掉幀，每大于16ms，就多掉一幀--> 
  12.         if (jitterNanos >= mFrameIntervalNanos) { 
  13.             final long skippedFrames = jitterNanos / mFrameIntervalNanos; 
  14.             <!--跳幀，其實就是上一次請求刷新被延遲的時間，但是這里skippedFrames為0不代表沒有掉幀--> 
  15.             if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) { 
  16.             <!--skippedFrames很大一定掉幀，但是為 0，去并非沒掉幀--> 
  17.                 Log.i(TAG, "Skipped " + skippedFrames + " frames!  " 
  18.                         + "The application may be doing too much work on its main thread."); 
  19.             } 
  20.             final long lastFrameOffset = jitterNanos % mFrameIntervalNanos; 
  21.                 <!--開始doFrame的真正有效時間戳--> 
  22.             frameTimeNanos = startNanos - lastFrameOffset; 
  23.         } 
  24.         if (frameTimeNanos < mLastFrameTimeNanos) { 
  25.             <!--這種情況一般是生成vsync的機制出現(xiàn)了問題，那就再申請一次--> 
  26.             scheduleVsyncLocked(); 
  27.             return; 
  28.         } 
  29.           <!--intendedFrameTimeNanos是本來要繪制的時間戳，frameTimeNanos是真正的，可以在渲染工具中標識延遲VSYNC多少--> 
  30.         mFrameInfo.setVsync(intendedFrameTimeNanos, frameTimeNanos); 
  31.         <!--移除mFrameScheduled判斷，說明處理開始了，--> 
  32.         mFrameScheduled = false; 
  33.         <!--更新mLastFrameTimeNanos--> 
  34.         mLastFrameTimeNanos = frameTimeNanos; 
  35.     } 
  36.     try { 
  37.          <!--真正開始處理業(yè)務--> 
  38.         Trace.traceBegin(Trace.TRACE_TAG_VIEW, "Choreographer#doFrame"); 
  39.         <!--處理打包的move事件--> 
  40.         mFrameInfo.markInputHandlingStart(); 
  41.         doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos); 
  42.         <!--處理動畫--> 
  43.         mFrameInfo.markAnimationsStart(); 
  44.         doCallbacks(Choreographer.CALLBACK_ANIMATION, frameTimeNanos); 
  45.         <!--處理重繪--> 
  46.         mFrameInfo.markPerformTraversalsStart(); 
  47.         doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos); 
  48.         <!--提交-> 
  49.         doCallbacks(Choreographer.CALLBACK_COMMIT, frameTimeNanos); 
  50.     } finally { 
  51.         Trace.traceEnd(Trace.TRACE_TAG_VIEW); 
  52.     } 
  53. } 
  • doTraversal會先將柵欄移除，然后處理performTraversals，進行測量、布局、繪制，提交當前幀給SurfaceFlinger進行圖層合成顯示;
  • 以上多個boolean變量保證了每16ms最多執(zhí)行一次UI重繪;

9、UI局部重繪

View重繪刷新，并不會導致所有View都進行一次measure、layout、draw，只是這個待刷新View鏈路需要調(diào)整，剩余的View可能不需要浪費精力再來一遍;

  1. View.java 
  2.     public RenderNode updateDisplayListIfDirty() { 
  3.         final RenderNode renderNode = mRenderNode; 
  4.           ... 
  5.         if ((mPrivateFlags & PFLAG_DRAWING_CACHE_VALID) == 0 
  6.                 || !renderNode.isValid() 
  7.                 || (mRecreateDisplayList)) { 
  8.            <!--失效了，需要重繪--> 
  9.         } else { 
  10.         <!--依舊有效，無需重繪--> 
  11.             mPrivateFlags |= PFLAG_DRAWN | PFLAG_DRAWING_CACHE_VALID; 
  12.             mPrivateFlags &= ~PFLAG_DIRTY_MASK; 
  13.         } 
  14.         return renderNode; 
  15.     } 

10、繪制總結

  • android最高60FPS，是VSYNC及決定的，每16ms最多一幀;
  • VSYNC要客戶端主動申請，才會有;
  • 有VSYNC到來才會刷新;
  • UI沒更改，不會請求VSYNC也就不會刷新;

總結

 

關于繪制還有很多知識點，后面會總結陸續(xù)發(fā)出來的;

 

責任編輯：武曉燕 來源： Android開發(fā)編程
Vsync信號機制
相關推薦

2011-07-05 18:40:19

QT 信號 機制

2011-07-05 18:32:52

QT 信號 機制

2024-07-16 10:52:09

2025-02-03 07:00:00

2017-09-14 09:40:32

PythonUbuntu信號機制

2022-11-03 07:35:47

OS內(nèi)核異步

2024-11-19 08:09:09

MySQL數(shù)據(jù)庫數(shù)據(jù)

2017-01-16 15:05:17

Linux信號機制分析

2011-06-09 09:45:35

Linux QT 信號

2017-01-16 14:48:42

Linux信號機制分析

2011-06-23 13:38:27

QT 元對象 信號

2011-07-15 09:57:03

MongoDB緩存刷新

2011-06-23 14:40:13

Qt 信號 槽

2021-08-09 14:32:34

鴻蒙HarmonyOS應用

2021-12-08 06:53:28

Choreograph屏幕機制

2020-07-27 08:44:22

存儲Kafka 流程

2015-03-26 13:14:53

javascriptjs callback實現(xiàn)調(diào)用

2014-04-08 14:19:06

Android開發(fā)UI線程

2011-06-13 10:21:25

QT 信號 槽機制

2018-07-09 14:19:16

儀器
點贊
收藏

51CTO技術棧公眾號