问题背景：

了解surfaceflinger的vsync同学都可能知道vsync属于一个节拍器，主要用来控制有节奏的渲染，不至于会产生什么画面撕裂等现象。
一般vsync都有会有2部分：
app部分vsync，控制各个app可以有节奏的上帧
surfaceflinger部分vsync,控制surfaceflinger的一个合成画面送显示的节奏

上面2部分其实大家了解vsync都知道，但是近期再看android 13的surfaceflinger trace时候发现有如下情况：

老版本：
systrace查看发现老版本其实只有app和sf的VSYNC情况

新版本
systrace出现了3个，多了一个VSYNC-appSf：

这个地方就有学员朋友在群里问这个问题，刚好我近期也在修炼surfaceflinger相关，针对这个问题，其实大部分人我估计态度都是忽略哈，，网上也基本找不到答案，哪怕问人也很难问到哈。
那么这个VSYNC-appSf到底是啥，为啥老版本没有新版本会有这个？这个就是本blog要讲解的重点 。

更多framework干货课程优惠获取相关可以+V（androidframework007）
视频：https://www.bilibili.com/video/BV1ah411d7Y3

线索追踪及官方解释

在对appSf的修改进行git log追踪时候发现有如下一个commit，这个commit有专门写明原因哈：

appSf产生原因，官方解释：

SurfaceFlinger: decouple EventThread from SF wakeup
    
    Today we have two instances of EventThread:
    1. 'app' - used to wake up Choreographer clients
    2. 'sf' - used to wake up SF mian thead *and*
              Choreographer clients that uses sf instance
    
    Now this creates an ambiguity when trying to reason about the expected
    vsync time and deadline of 'sf' EventThread:
     - SF wakes up sfWorkDuration before a vsync and targets that vsync
     - Choreographer users wakes up with SF main thread but targets the
       vsync that happens after the next SF wakeup.
    
    To resolve this ambiguity we are decoupling SF wakeup from 'sf'
    EventThread. This means that Choreographer clients that uses 'sf'
    instance will keep using the EventThread but SF will be waking up
    directly by a callback with VSyncDispatch. This allows us to correct
    the expected vsync and deadline for both.
    
    Test: Interacting with the device and observe systraces
    Test: new unit test added to SF suite
    Bug: 166302754
    
    Change-Id: I76d154029b4bc1902198074c33d38ff030c4601b

不过比较遗憾哈，全是英文的，这个要看懂可能不难哈，但是要完全领悟贯通那就要很了解surfaceflinger的vsync了。不然那就只能停留在字面意思啦，根本无法理解精华。
下面马哥带大家来理解一下吧，都把相关翻译写下来啦，不一定全对哈。
带马哥注释理解

  SurfaceFlinger: decouple EventThread from SF wakeup
  //标题就是把EventThread分离出sf，大概意思就是不想让EventThread管sf相关vsync
    
    Today we have two instances of EventThread:
    //这个是解释修改前的现状和背景，目前有两个EventThread实例，一个app一个sf
    1. 'app' - used to wake up Choreographer clients //app的EventThread属于用来唤醒app端
    2. 'sf' - used to wake up SF mian thead *and* 
              Choreographer clients that uses sf instance
   //sf的EventThread有2个责任，一个是自己来唤醒Sf的主线程，另一个也是关键一点，有对应的clients端也需要使用
   
   //下面讲述修改背景，本质就是说sf的EventThread因为有2个责任，一个是自己sf的唤醒，一个是client端唤醒，二者共用情况，可能会有时候排查vsync会有模棱两可的情况，即没办法准确确认vsync问题原因
    Now this creates an ambiguity when trying to reason about the expected
    vsync time and deadline of 'sf' EventThread:
     - SF wakes up sfWorkDuration before a vsync and targets that vsync
     - Choreographer users wakes up with SF main thread but targets the
       vsync that happens after the next SF wakeup.
    //为了解决这类可能导致模棱两可的情况，那么就需要吧sf的EventThread进行相关的分离，sf原本负责的2个功能拆开，把sf自己唤醒自己的转移到了直接让VSyncDispatch进行callback调用，另一个对于client端的功能就保留在EventThread中，这样就不会造成上面的模棱两可疑惑。也就是我们看到的会多了一个appSf
    To resolve this ambiguity we are decoupling SF wakeup from 'sf'
    EventThread. This means that Choreographer clients that uses 'sf'
    instance will keep using the EventThread but SF will be waking up
    directly by a callback with VSyncDispatch. This allows us to correct
    the expected vsync and deadline for both.
    
    Test: Interacting with the device and observe systraces
    Test: new unit test added to SF suite
    Bug: 166302754
    
    Change-Id: I76d154029b4bc1902198074c33d38ff030c4601b

总结一下：
简单说就是吧以前的sf的EventTread功能中，自己唤醒触发vsync的部分移除EventTread，让VSyncDispatch直接进行（后面有机会讲解vsync再深入分析），不在使用EventThread来搞对于的sf的vsync了。
但是sf还有一个功能就是对待客户端的，这个部分保留在EventTread中，变成我们看到的appSf

哈其实你是不是有点懂又还是没彻底领悟，特别是为啥sf还有两个功能？以前不是说了只是来产生sf的vsync么？正常哈，因为上面的结论其实都是相当于一个结论哈，要彻底理解还需要其他相关的补充哈。

千里马实战解读理解appSf

理解sf为啥会有两个功能，以前不是只有一个产生sf端的vsync么?
我们注意看看人家的解释哈：

1. 'app' - used to wake up Choreographer clients 
2. 'sf' - used to wake up SF mian thead *and* 
          Choreographer clients that uses sf instance

sf另一个功能是 Choreographer clients 需要使用这个sf的EventThread,这里应该是大家最不可以理解的地方。这里看看上面的app也是用的Choreographer clients ，表面意识就是Choreographer的客户端，其实就是各个需要上帧的应用的Choreographer客户端。
那么这里说的 Choreographer clients that uses sf instance，难道是sf的也有对于的客户端吗？Choreographer也有直接指定sf这个EventTread线程的？哈哈其实确实有的具体可以看以下代码：

    private Choreographer(Looper looper, int vsyncSource) {
        mLooper = looper;
        mHandler = new FrameHandler(looper);
        mDisplayEventReceiver = USE_VSYNC
                ? new FrameDisplayEventReceiver(looper, vsyncSource)
                : 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();
        }
        // b/68769804: For low FPS experiments.
        setFPSDivisor(SystemProperties.getInt(ThreadedRenderer.DEBUG_FPS_DIVISOR, 1));
    }

大家注意没有这个Choreographer构造时候就有个vsyncSource，这个是不是大家都没有注意过哈，它到底有哪些值呢？

  /**
     * When retrieving vsync events, this specifies that the vsync event should happen at the normal
     * vsync-app tick.
     * <p>
     * Needs to be kept in sync with frameworks/native/include/gui/ISurfaceComposer.h
     */
    public static final int VSYNC_SOURCE_APP = 0;

    /**
     * When retrieving vsync events, this specifies that the vsync event should happen whenever
     * Surface Flinger is processing a frame.
     * <p>
     * Needs to be kept in sync with frameworks/native/include/gui/ISurfaceComposer.h
     */
    public static final int VSYNC_SOURCE_SURFACE_FLINGER = 1;

可以看到有两个
一个最常见的的app
另一个就是sf的
sf这个，也就是app端可以指定vsync是跟随surfaceflinger的合成vsync的，所以这里也就是被叫做Choreographer clients ，这里大家就可以理解了吧，具体有没有谁使用呢？
可以看看有谁使用Choreographer getSfInstance方法:

可以看到还是有一些场景就是使用的sf的vsync，自然使用vsync就会涉及到回调获取vsync和请求vsync。所以这里就是上面的说的client可能会使用相关的sf vsync情况，sf自身也有请求获取情况，所以这个两个业务混一起了，那确实有时候一些问题就不好排查了。

结合systrace验证

1、确定是不是真的有有clinet链接到了sf的EventThread
这个其实可以通过相关的dumpsys SurfaceFlinger来实现，看看是否appSf是否有对于的connection，不过比较遗憾哈，默认的dumpsys并没有吧appSf的EventThread打印，只打印了app的EventTread，所以这里就需要我们修改一下相关dumpsys如下：

test@test:~/nx563j_xiaomi/frameworks/native/services$ git diff surfaceflinger/SurfaceFlinger.cpp
diff --git a/services/surfaceflinger/SurfaceFlinger.cpp b/services/surfaceflinger/SurfaceFlinger.cpp
index b1b31bbd76..04f5b63dc0 100644
--- a/services/surfaceflinger/SurfaceFlinger.cpp
+++ b/services/surfaceflinger/SurfaceFlinger.cpp
@@ -5180,6 +5180,7 @@ void SurfaceFlinger::dumpVSync(std::string& result) const {
                   mDebugDisplayModeSetByBackdoor ? "yes" : "no");
 
     mScheduler->dump(mAppConnectionHandle, result);
+    mScheduler->dump(mSfConnectionHandle, result);//加入一行吧appSf相关EventTread信息也打一下
     mScheduler->dumpVsync(result);
     StringAppendF(&result, "mHWCVsyncPendingState=%s mLastHWCVsyncState=%s\n",
                   to_string(mHWCVsyncPendingState).c_str(), to_string(mLastHWCVsyncState).c_str());

结果如下：

app: state=Idle VSyncState={displayId=0, count=548}//正常只有这个打印
  pending events (count=0):
  connections (count=16):
    Connection{0x747b86b730, VSyncRequest::None,1000}
    Connection{0x747b879e30, VSyncRequest::None,1000}
    Connection{0x747b86ffd0, VSyncRequest::None,1000}
    Connection{0x747b8784d0, VSyncRequest::None,1000}
    Connection{0x747b86c1b0, VSyncRequest::None,10110}
    Connection{0x747b8856d0, VSyncRequest::None,10110}
    Connection{0x747b882db0, VSyncRequest::None,10110}
    Connection{0x747b87fd90, VSyncRequest::None,10110}
    Connection{0x747b8839f0, VSyncRequest::None,10111}
    Connection{0x747b883bb0, VSyncRequest::None,1000}
    Connection{0x747b8728f0, VSyncRequest::None,1000}
    Connection{0x747b870350, VSyncRequest::None,10111}
    Connection{0x747b882870, VSyncRequest::None,10142}
    Connection{0x747b880570, VSyncRequest::None,10144}
    Connection{0x747b871150, VSyncRequest::None,10144}
    Connection{0x747b86da30, VSyncRequest::None,10141}
appSf: state=Idle VSyncState={displayId=0, count=165}//额外加上这个打印
  pending events (count=0):
  connections (count=4)://client链接数量
    Connection{0x747b86ca70, VSyncRequest::None,1000}
    Connection{0x747b8833d0, VSyncRequest::None,1000}
    Connection{0x747b877190, VSyncRequest::None,1000}
    Connection{0x747b87cc90, VSyncRequest::None,10110}
VsyncController:

发现确实appSf也有4个链接，uid 1000是system和10110 是systemui

结合trace打印查看appSf相关的：

回想一下app端如果要请求vsync时候最后是跨进程调用到了如下代码：

frameworks/native/services/surfaceflinger/Scheduler/EventThread.cpp

binder::Status EventThreadConnection::requestNextVsync() {
    ATRACE_CALL();
    mEventThread->requestNextVsync(this);
    return binder::Status::ok();
}

这里trace中只有个方法的输出，这里可以添加一下，用来区分app还是appSf的EventTread，修改如下：

 std::string toString(const DisplayEventReceiver::Event& event) {
@@ -194,7 +194,10 @@ binder::Status EventThreadConnection::setVsyncRate(int rate) {
 
 binder::Status EventThreadConnection::requestNextVsync() {
     ATRACE_CALL();
+    ATRACE_BEGIN(((impl::EventThread*)mEventThread)->toNameString());//主要线程名字打出到Trace中
+    ALOGE(" EventThreadConnection::requestNextVsync() threadName %s calluid %d",((impl::EventThread*)mEventThread)->toNameString(),(int)mOwnerUid);
     mEventThread->requestNextVsync(this);
+        ATRACE_END();
     return binder::Status::ok();
 }

然后再看trace情况如下：
看sf的clinet端请求vsync

这里因为tag太小做个标记方便寻找
下面来看具体的apSf的vsync到来