Android Perfetto 系列 8：深入理解 Vsync 机制与性能分析

本篇是 Perfetto 系列文章的第八篇，主要深入介绍 Android 中的 Vsync 机制及其在 Perfetto 中的表现形式。文章将从 Perfetto 的角度来分析 Android 系统如何基于 Vsync 信号进行帧渲染和合成，涵盖 Vsync、Vsync-app、Vsync-sf、VsyncWorkDuration 等核心概念。

随着高刷新率屏幕的普及，理解 Vsync 机制变得更加重要。本文将以 120Hz 刷新率为主要叙事线，帮助开发者理解现代 Android 设备中 Vsync 的工作原理，以及如何在 Perfetto 中观察和分析 Vsync 相关的性能问题。

注：本文内容基于 Android 13~16 的公开实现与演进；文中代码以 AOSP main 的"签名对齐精简摘录"为主，少量位置使用 ... 省略非主线逻辑，请以当前分支源码为准。

系列文章目录

1Android Perfetto 系列目录^[1]

2Android Perfetto 系列 1：Perfetto 工具简介^[2]

3Android Perfetto 系列 2：Perfetto Trace 抓取^[3]

4Android Perfetto 系列 3：熟悉 Perfetto View^[4]

5Android Perfetto 系列 4：使用命令行在本地打开超大 Trace^[5]

6Android Perfetto 系列 5：Android App 基于 Choreographer 的渲染流程^[6]

7Android Perfetto 系列 6：为什么是 120Hz？高刷新率的优势与挑战^[7]

8Android Perfetto 系列 7 - MainThread 和 RenderThread 解读^[8]

9Android Perfetto 系列 8：深入理解 Vsync 机制与性能分析^[9]

10Android Perfetto 系列 9 - CPU 信息解读^[10]

11Android Perfetto 系列 10 - Binder 调度与锁竞争^[11]

12视频(B站) - Android Perfetto 基础和案例分享^[12]

13视频(B站) - Android Perfetto 分享 - 出图类型分享：AOSP、WebView、Flutter + OEM 系统优化分享^[13]

如果大家还没看过 Systrace 系列，下面是传送门：

1Systrace 系列目录^[14] ：系统介绍了 Perfetto 的前身 Systrace 的使用，并通过 Systrace 来学习和了解 Android 性能优化和 Android 系统运行的基本规则。

2个人博客^[15] ：个人博客，主要是 Android 相关的内容，也放了一些生活和工作相关的内容。

欢迎大家在关于我^[16] 页面加入微信群或者星球，讨论你的问题、你最想看到的关于 Perfetto 的部分，以及跟各位群友讨论所有 Android 开发相关的内容

什么是 Vsync

Vsync（Vertical Synchronization，垂直同步）是 Android 图形系统的核心机制，它的存在是为了解决一个根本性的问题：如何让软件的渲染节奏与硬件的显示节奏保持同步。

在没有 Vsync 机制之前，常见问题是屏幕撕裂（Screen Tearing）。当显示器读取 framebuffer 的同时，GPU 写入了下一帧，就会在同一次刷新中出现上下两部分不一致的画面。

Vsync 解决什么问题？

Vsync 机制的核心思想非常简单：让所有的渲染工作都按照显示器的刷新节拍来进行。具体来说：

1同步信号：显示器每次开始新的刷新周期时，都会发出一个 Vsync 信号。

2帧节拍与生产：应用侧在 Vsync 到来时由 Choreographer 驱动开始一帧的生产（Input/Animation/Traversal）；CPU 提交渲染命令后，GPU 异步流水执行。SurfaceFlinger 侧在 Vsync 到来时进行 Buffer 的合成操作。

3缓冲机制：使用双缓冲或三缓冲技术，确保显示器总是读取完整的帧数据。

这样，帧的生产与显示以 Vsync 为节拍对齐。以 120Hz 为例，每 8.333ms 会有一个显示机会；应用需要在该窗口前把可合成的 Buffer 提交给 SurfaceFlinger。关键约束是 queueBuffer/acquire_fence/present_fence 的时序；若未赶上本周期，会顺延到下一个周期显示。

Android 中 Vsync 的基本工作原理

Android 系统的 Vsync 实现比基本概念复杂得多，需要考虑多个不同的渲染组件，以及它们之间的协调工作。

Vsync 信号的分层架构

在 Android 系统中，并不是只有一个简单的 Vsync 信号。实际上，系统维护着多个不同用途的 Vsync 信号：

⚡ Vsync 信号的分层架构

Android 系统维护着多个不同用途的 Vsync 信号：HW Vsync（硬件层）→ Vsync-app（驱动应用渲染）→ Vsync-sf（驱动 SurfaceFlinger 合成）→ Vsync-appSf（Android 13+ 新增）。理解这个分层是分析性能问题的基础。

硬件 Vsync（HW Vsync） ：

这是最底层的 Vsync 信号，由显示硬件（HWC，Hardware Composer）产生。它的频率严格对应显示器的刷新率，比如 60Hz 的显示器会每 16.67ms 产生一次 HW Vsync，120Hz 的显示器会每 8.333ms 产生一次。（硬件 Vsync 回调由 HWC/SurfaceFlinger 管理，详见 frameworks/native/services/surfaceflinger 相关实现）

但是，HW Vsync 并不是一直开启的。由于频繁的硬件中断会消耗较多的电量，Android 系统采用了一种智能的策略：只有在需要精确同步的时候才开启 HW Vsync，大部分时间使用软件预测的方式生成 Vsync 信号。

Vsync-app（应用 Vsync） ：

这是专门用于驱动应用层渲染的 Vsync 信号。当应用需要进行 UI 更新时（比如用户触摸、动画运行、界面滚动等），应用会向系统申请接收 Vsync-app 信号。

go 复制代码

// frameworks/base/core/java/android/view/Choreographer.java
private void scheduleFrameLocked(long now) {
    if (!mFrameScheduled) {
        mFrameScheduled = true;
        if (USE_VSYNC) {
            // 向系统申请下一个 Vsync 信号
            mDisplayEventReceiver.scheduleVsync();
        }
    }
}

💡 Vsync-app 是按需申请的

如果应用界面是静态的，没有任何动画或用户交互，应用不会申请 Vsync-app 信号。这是 Android 省电的重要机制。

Vsync-app 是按需申请的。如果应用界面是静态的，没有任何动画或用户交互，那么应用不会申请 Vsync-app 信号，系统也就不会为这个应用生成 Vsync 事件。

Vsync-sf（SurfaceFlinger Vsync） ：

这是专门用于驱动 SurfaceFlinger 进行图层合成的 Vsync 信号。SurfaceFlinger 是 Android 系统中负责将所有应用的图层合成为最终画面的服务。

Vsync-appSf（应用-SurfaceFlinger Vsync） ：

Android 13 引入的新信号类型。为消除旧设计中 sf EventThread 既唤醒 SurfaceFlinger 又服务部分 Choreographer 客户端带来的时序歧义，系统将两类职责分离：vsync-sf 专注唤醒 SurfaceFlinger，vsync-appSf 面向需要与 SurfaceFlinger 同步的客户端。

在 Perfetto 中观察 Vsync

Perfetto trace 中包含多个与 Vsync 相关的 Track，理解这些 Track 的含义有助于分析性能问题。

在 SurfaceFlinger 进程中：

1vsync-app

显示应用 Vsync 信号状态，数值在 0 和 1 之间变化。每次数值变化代表一个 Vsync 信号。

2**vsync-sf **

显示 SurfaceFlinger Vsync 信号状态。无 Vsync Offset 时与 vsync-app 同步变化。

3vsync-appSf

Android 13+ 新增，服务于需要与 SurfaceFlinger 同步的特殊 Choreographer 客户端。

4HW_VSYNC

显示硬件 Vsync 开启状态。值为 1 表示开启，值为 0 表示关闭。为节省电量，硬件 Vsync 仅在需要精确同步时开启。

在应用进程中：

FrameDisplayEventReceiver.onVsync Slice Track：

显示应用接收 Vsync 信号的时间点。该事件连接通过 Binder 建链、通过 BitTube/Looper 通道分发事件，时间可能略晚于 SurfaceFlinger 中的 vsync-app。

UI Thread Slice Track：

包含 Choreographer#doFrame 及相关的 Input、Animation、Traversal 等 Slice。每个 doFrame 对应一帧的处理工作。

RenderThread Slice Track：

包含 DrawFrame、syncAndDrawFrame、queueBuffer 等 Slice，对应渲染线程工作。

Android App 每一帧是如何基于 Vsync 工作的

Android 应用的每一帧基于 Vsync 机制完成从渲染到显示的完整过程涉及多个关键步骤。

流程总览（按顺序）

1触发重绘/输入：View.invalidate()、动画、数据变化或输入事件触发 → ViewRootImpl.scheduleTraversals() → Choreographer.postCallback(TRAVERSAL)

2申请 Vsync：Choreographer 通过 DisplayEventReceiver.scheduleVsync() 申请下一次 Vsync（app 相位）

3接收 Vsync：DisplayEventReceiver.onVsync() 收到 Vsync 后，向主线程消息队列投递异步消息

4主线程帧处理：Choreographer.doFrame() 按顺序执行五类回调：INPUT → ANIMATION → INSETS_ANIMATION → TRAVERSAL → COMMIT

5渲染提交：RenderThread 执行 syncAndDrawFrame/DrawFrame，CPU 记录 GPU 命令，queueBuffer 提交到 BufferQueue

6合成显示：SurfaceFlinger 在 vsync-sf 到来时合成（GPU/或HWC），生成 present_fence，输出到显示

7帧完成度量：通过 FrameTimeline（PresentType/JankType）与 acquire/present_fence 判定是否按期显示

下面分别展开每一步的关键实现与 Perfetto 观测点。

App 什么时候会申请 Vsync 信号

应用并不是时刻都在申请 Vsync 信号的。Vsync 信号是按需申请的，只有在以下情况下，应用才会向系统申请下一个 Vsync：

触发申请 Vsync 的场景 ：

UI 更新需求 ：当 View 调用 invalidate() 时
动画执行 ：ValueAnimator、ObjectAnimator 等动画开始时
用户交互 ：触摸事件、按键事件等需要 UI 响应时
数据变化：RecyclerView 数据更新、TextView 文本改变等

App 申请 Vsync 的完整流程

当应用需要更新 UI 时，会通过以下流程申请 Vsync 信号：

go 复制代码

// 1. UI 组件请求重绘
// frameworks/base/core/java/android/view/View.java
public void invalidate() {
    // 标记为需要重绘，但不立即执行
    mPrivateFlags |= PFLAG_DIRTY;

    if (mParent != null && mAttachInfo != null) {
        // 向父容器请求重绘
        mParent.invalidateChild(this, null);
    }
}

// 2. ViewRootImpl 调度遍历
// frameworks/base/core/java/android/view/ViewRootImpl.java
void scheduleTraversals() {
    if (!mTraversalScheduled) {
        mTraversalScheduled = true;
        // 关键：向 Choreographer 注册回调，等待下一个 Vsync
        mChoreographer.postCallback(
            Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
    }
}

// 3. Choreographer 申请 Vsync
// frameworks/base/core/java/android/view/Choreographer.java
private void postCallbackDelayedInternal(int callbackType,
        Object action, Object token, long delayMillis) {
    final long now = SystemClock.uptimeMillis();
    final long dueTime = now + delayMillis;
    mCallbackQueues[callbackType].addCallbackLocked(dueTime, action, token);

    // 重点：不只 TRAVERSAL，任意"到期回调"都可能触发下一帧调度
    if (dueTime <= now) {
        scheduleFrameLocked(now);
    }
}

private void scheduleFrameLocked(long now) {
    if (!mFrameScheduled) {
        mFrameScheduled = true;
        if (isRunningOnLooperThreadLocked()) {
            scheduleVsyncLocked();
        } else {
            Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_VSYNC);
            msg.setAsynchronous(true);
            mHandler.sendMessageAtFrontOfQueue(msg);
        }
    }
}

TRAVERSAL 仍然是最常见触发源，但从 AOSP main 实现看，并非"只有 TRAVERSAL 才申请 Vsync"。

主线程如何监听 Vsync 信号

应用主线程通过 DisplayEventReceiver 来监听 Vsync 信号。这个过程涉及几个关键步骤：

1. 建立连接：

go 复制代码

// frameworks/base/core/java/android/view/Choreographer.java
private final class FrameDisplayEventReceiver extends DisplayEventReceiver
        implements Runnable {

    public FrameDisplayEventReceiver(Looper looper, int vsyncSource, long layerHandle) {
        super(looper, vsyncSource, /* eventRegistration */ 0, layerHandle);
        // 在构造时建立与 SurfaceFlinger 的连接
    }
}

2. 接收 Vsync 信号：

go 复制代码

@Override
public void onVsync(long timestampNanos, long physicalDisplayId, int frame,
        VsyncEventData vsyncEventData) {
    // 接收到 Vsync 信号，但注意：这里并不直接执行 doFrame
    mTimestampNanos = timestampNanos;
    mFrame = frame;
    mLastVsyncEventData.copyFrom(vsyncEventData);

    // 关键：将工作 post 到主线程的 MessageQueue 中
    Message msg = Message.obtain(mHandler, this);
    msg.setAsynchronous(true);  // 设为异步消息，优先处理
    mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);
}

@Override
public void run() {
    // 这里才真正开始执行一帧的工作
    doFrame(mTimestampNanos, mFrame, mLastVsyncEventData);
}

几个遗留问题

Q1：为什么不在 onVsync() 中直接执行 doFrame()？

•线程边界：在 Choreographer 场景下，onVsync() 回调运行在其绑定的 Looper（通常就是主线程）；通过消息队列再进入 doFrame()，可统一调度并保持帧处理时序一致

•调度控制：通过 sendMessageAtTime() 精确对齐执行时刻

•队列语义：进入主线程 MessageQueue，确保与其他高优先级任务协同

Q2：Vsync 消息来了但主线程在忙，会丢吗？

•不完全是"不会丢"。单次 scheduleVsync() 只请求一次事件；主线程长期繁忙时会出现"跳过多个硬件节拍、最终只处理较新的一帧"的现象。实际分析应结合 FrameTimeline 判断是否产生可见卡顿。

•AOSP DisplayEventDispatcher::processPendingEvents 明确会用"后到达的 vsync 覆盖先到达的 vsync"（只保留最近一次用于分发）。

**Q3：CPU/GPU 是否必须在单个 Vsync 周期内完成？**如果任何一个环节超过 1 个 vsync ，都会导致掉帧？

•现代 Android 系统采用多缓冲（通常是三缓冲）机制：

•应用端：Front Buffer（显示中）+ Back Buffer（渲染中）+ 可能的第三个 Buffer

•SurfaceFlinger 端：也有类似的缓冲机制

•这意味着即使应用的某一帧超过了 Vsync 周期，也不一定会立即掉帧。

•GPU 异步流水；关键是 queueBuffer 是否赶上 SF 合成窗口，多缓冲可掩盖单帧延迟但可能引入额外时延，可以看到下图里面，App 端的 BufferQueue 和 SurfaceFlinger 端的 Buffer 都是充足的，且有冗余，所以没有掉帧。

•但是如果 App 在之前没有堆积 Buffer ，则还是会出现掉帧。

Q5：GPU 和 CPU 是怎么协同的？：

•GPU 渲染是异步的，这带来了额外的复杂性：

•CPU 工作正常，GPU 成为瓶颈：即使应用主线程在 Vsync 周期内完成工作，GPU 渲染耗时过长仍会导致掉帧

•GPU Fence 机制 ：在 Buffer 被 SF latch 的阶段，关键同步点通常是 acquire fence（Buffer 何时可安全读取）；present fence 更偏向"该帧何时真正送显"的完成信号。根据系统 Latch Unsignaled Buffers 策略，SurfaceFlinger 在特定条件下可先推进流程，再在真正需要时等待 fence 信号，以此隐藏部分延迟。

Q6：Vsync Phase（相位差）的真正作用是什么？：

•提升跟手性：通过调整 sf vsync 的相位差，可以让应用从开始绘制到显示在屏幕上的时间从 3 个 Vsync 周期缩短到 2 个 Vsync 周期。这对于触摸响应等交互场景非常重要。

•解决应用绘制超时问题：当应用绘制超时时，合理的 sf 相位差可以为应用争取更多的处理时间，避免因为时序不当导致的掉帧。

•VsyncWorkDuration 更接近调度预算（workDuration/readyDuration）的可视化，不等价于单一 appOffset 数值；分析时建议结合 vsync-app/sf 与 FrameTimeline 联动判断。

•下图中显示的时间段就是我手上的手机配置的 app offset （13.3ms）

Vsync Offset / WorkDuration 的技术实现

在当前 AOSP main 中，配置入口是 VsyncConfiguration 抽象接口，返回的是按场景组织的 VsyncConfigSet。实现上 PhaseOffsets 属于旧路径，WorkDuration 是新路径中更常见的实现之一：

go 复制代码

// frameworks/native/services/surfaceflinger/Scheduler/VsyncConfiguration.h
class VsyncConfiguration {
public:
    virtual ~VsyncConfiguration() = default;
    virtual VsyncConfigSet getCurrentConfigs() const = 0;
    virtual VsyncConfigSet getConfigsForRefreshRate(Fps fps) const = 0;
    virtual void setRefreshRateFps(Fps fps) = 0;
    virtual void reset() = 0;
};

class WorkDuration : public VsyncConfiguration {
public:
    explicit WorkDuration(Fps currentRefreshRate);
    // 内部根据 sf/app 的 workDuration 构造不同场景下的 offset 配置
};

关键概念 ：

workDuration/readyDuration：调度时的"工作预算"和"就绪提前量"，用于计算回调唤醒时刻
app/sf offset：仍可作为常用分析口径，但本质是配置集合与调度模型共同作用的结果
常用口径里"app/sf offset 差值"指两者相位差（通常看 |sfOffset - appOffset| 的绝对值，具体符号以设备实现与统计口径为准）

实际的优化效果

以 120Hz 设备为例，配置 3ms Offset 的效果：

无 Offset（传统方式） ：

T0：应用和 SurfaceFlinger 同时接收 Vsync
T0+3ms：应用完成渲染
T0+8.333ms：下一个 Vsync，SurfaceFlinger 开始合成
T0+16.666ms：用户看到画面（总延迟 16.666ms）

有 Offset（优化方式） ：

T0+1ms：应用接收 Vsync-app，开始渲染
T0+3ms：应用完成渲染，提交 Buffer
T0+4ms：SurfaceFlinger 接收 Vsync-sf，立即开始合成
T0+6ms：SurfaceFlinger 完成合成
T0+8.333ms：用户看到画面（总延迟 8.333ms）

⚡ Vsync Phase 优化效果

通过合理配置 Offset，可以将延迟从 16.666ms 减少到 8.333ms，提升一倍的响应性能。

实际的时间预算分配：

以 120Hz 设备为例（8.333ms 周期）：

理想情况 ：应用 4ms + SurfaceFlinger 2ms + 缓冲 2.333ms
但实际可以接受 ：应用 6ms + SurfaceFlinger 3ms（如果有足够的 Buffer 缓冲）
GPU 限制：在低端设备上，GPU 渲染可能需要 10-15ms，成为真正的瓶颈

掉帧的真正原因 ：

应用端超时 + Buffer 耗尽 ：连续多帧超时导致 BufferQueue 没有可用 Buffer
GPU 渲染超时 ：即使 CPU 工作正常，GPU 渲染超时也会掉帧
SurfaceFlinger 超时 ：系统级合成超时，影响所有应用
系统资源竞争：CPU/GPU/内存等资源被其他进程占用

Vsync 信号的完整代码流程

Vsync 信号从硬件传递到应用层的完整链路如下。

按 AOSP main 分支对齐的关键代码（精简摘录）

下面片段都按当前 AOSP main 分支的方法签名整理，省略了与主线无关的分支与日志代码。

1）Choreographer 申请下一次 Vsync（Java）

go 复制代码

// frameworks/base/core/java/android/view/Choreographer.java
private void scheduleFrameLocked(long now) {
    if (!mFrameScheduled) {
        mFrameScheduled = true;
        if (USE_VSYNC) {
            if (isRunningOnLooperThreadLocked()) {
                scheduleVsyncLocked();
            } else {
                Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_VSYNC);
                msg.setAsynchronous(true);
                mHandler.sendMessageAtFrontOfQueue(msg);
            }
        }
    }
}

private void scheduleVsyncLocked() {
    mDisplayEventReceiver.scheduleVsync();
}

2）Choreographer 接收 Vsync（Java）

go 复制代码

// frameworks/base/core/java/android/view/Choreographer.java
// TODO(b/116025192): physicalDisplayId is ignored because SF only emits VSYNC
// for the internal display and scheduleVsync only allows requesting internal VSYNC.
@Override
public void onVsync(long timestampNanos, long physicalDisplayId, int frame,
        VsyncEventData vsyncEventData) {
    mTimestampNanos = timestampNanos;
    mFrame = frame;
    mLastVsyncEventData.copyFrom(vsyncEventData);
    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, mLastVsyncEventData);
}

3）JNI 层桥接：DisplayEventDispatcher（C++）

go 复制代码

// frameworks/base/core/jni/android_view_DisplayEventReceiver.cpp
class NativeDisplayEventReceiver : public DisplayEventDispatcher {
public:
    NativeDisplayEventReceiver(JNIEnv* env, jobject receiverWeak, jobject vsyncEventDataWeak,
            const sp<MessageQueue>& messageQueue, jint vsyncSource,
            jint eventRegistration, jlong layerHandle);

private:
    void dispatchVsync(nsecs_t timestamp, PhysicalDisplayId displayId, uint32_t count,
            VsyncEventData vsyncEventData) override;
    void dispatchHotplug(nsecs_t timestamp, PhysicalDisplayId displayId, bool connected) override;
};

4）Native 收发通道：DisplayEventReceiver + BitTube（C++）

go 复制代码

// frameworks/native/libs/gui/DisplayEventReceiver.cpp
DisplayEventReceiver::DisplayEventReceiver(gui::ISurfaceComposer::VsyncSource vsyncSource,
        EventRegistrationFlags eventRegistration, const sp<IBinder>& layerHandle) {
    sf->createDisplayEventConnection(vsyncSource, ..., layerHandle, &mEventConnection);
    mDataChannel = std::make_unique<gui::BitTube>();
    mEventConnection->stealReceiveChannel(mDataChannel.get());
}

status_t DisplayEventReceiver::requestNextVsync() {
    mEventConnection->requestNextVsync();
    return NO_ERROR;
}

ssize_t DisplayEventReceiver::getEvents(Event* events, size_t count) {
    return gui::BitTube::recvObjects(mDataChannel.get(), events, count);
}

5）SurfaceFlinger 调度与分发（C++）

go 复制代码

// frameworks/native/services/surfaceflinger/Scheduler/VSyncDispatch.h
virtual std::optional<ScheduleResult> schedule(
        CallbackToken token, ScheduleTiming scheduleTiming) = 0;

go 复制代码

// frameworks/native/services/surfaceflinger/Scheduler/EventThread.cpp
void EventThread::onVsync(nsecs_t vsyncTime, nsecs_t wakeupTime, nsecs_t readyTime) {
    mPendingEvents.push_back(makeVSync(mVsyncSchedule->getPhysicalDisplayId(), wakeupTime,
            ++mVSyncState->count, vsyncTime, readyTime));
}

void EventThread::threadMain(std::unique_lock<std::mutex>& lock) {
    ...
    const auto scheduleResult = mVsyncRegistration.schedule({
            .workDuration = mWorkDuration.get().count(),
            .readyDuration = mReadyDuration.count(),
            .lastVsync = mLastVsyncCallbackTime.ns(),
            .committedVsyncOpt = mLastCommittedVsyncTime.ns()});
    LOG_ALWAYS_FATAL_IF(!scheduleResult, "Error scheduling callback");
    ...
}

关键时序点分析

通过上述代码流程，我们可以看到完整的时序链路：

1HWC 产生硬件 Vsync → SurfaceFlinger Scheduler 获取硬件节拍

2Scheduler 计算唤醒窗口 → VSyncDispatch::schedule(...)

3EventThread 生成/派发事件 → 写入 DisplayEventReceiver::Event（通过 BitTube）

4App 侧 Native 收到事件 → DisplayEventDispatcher::dispatchVsync(...)

5Java FrameDisplayEventReceiver 回调 → 异步消息切到 Looper 队列

6**Choreographer#doFrame(...) 执行** → Input/Animation/Traversal/Commit

各环节的职责和优化点不同，理解完整流程有助于在 Perfetto 中分析 Vsync 相关性能问题。

FrameTimeline

App 和 SurfaceFlinger 都有 FrameTimeline

•轨道：Expected Timeline、Actual Timeline

•PresentType/JankType：

•PresentType 指示本帧呈现方式（例如 On-time、Late），JankType 指示卡顿类型来源

•常见 JankType：AppDeadlineMissed、BufferStuffing、SfCpuDeadlineMissed、SfGpuDeadlineMissed 等

•操作步骤（Perfetto UI） ：

在应用进程选择目标 Surface/Layer 或使用 FrameToken 过滤
对齐 Expected 与 Actual，查看偏移与颜色编码
向上钻取：Choreographer#doFrame、RenderThread、queueBuffer、acquire/present_fence

•误判规避：

•仅凭 doFrame 时长判断掉帧不可靠；以 FrameTimeline 的 PresentType/JankType 为准

•多缓冲可能掩盖单帧超时，需要看连续帧与 Buffer 可用性

刷新率/显示模式/VRR 对 Vsync 与 Offset/预测的影响

•模式切换 ：刷新率变更会重新配置 VsyncConfiguration，影响 app/sf Offset 与预测模型；

•Perfetto：查 display mode change 事件与随后的 vsync 间隔变化

•VRR（可变刷新率）：目标周期不恒定，软件预测更依赖 present_fence 反馈校准；

•Perfetto：观察 vsync 间隔分布与 present_fence 偏差

•多显示/外接显示 ：硬件层可按 physicalDisplayId 上报 vsync；但应用侧 Choreographer 通常仍以内屏/pacesetter 时序为主（实现细节随版本演进）。分析时先确认你看的到底是 HWC/SF 轨道，还是 app 轨道；

•版本差异：官方文档明确 Android 10 及以下"Per-display VSYNC 不支持"；Android 11+ 该限制在框架/HWC 能力层面已移除，但应用侧 Choreographer 的请求路径在 main 分支仍有"internal display"相关注释，需结合目标系统分支实测判断

•Perfetto：按显示 ID 过滤相关 Counter/Slice

💡 Perfetto 实战 Checklist

以下是分析 Vsync 相关性能问题时建议按序查看的关键项目。

Perfetto 实战 Checklist（建议按序查看）

1Vsync 信号与周期

2vsync-app / vsync-sf / vsync-appSf 间隔是否稳定（60/90/120Hz 对应周期）

3是否存在异常密集/稀疏的 Vsync（预测抖动）

4Vsync 相位差配置

5VsyncWorkDuration 是否符合机型预期的 app/sf Offset

6app 与 sf 的先后是否匹配"先绘制后合成"的策略

7FrameTimeline 判读

8先看 PresentType，再看 JankType；确认是 app 还是 SF/GPU 侧问题

9选择目标 Surface/FrameToken 定位具体帧

10应用主线程与渲染线程

11Choreographer#doFrame 各阶段耗时（Input/Animation/Traversal）

12RenderThread 的 syncAndDrawFrame/DrawFrame 耗时是否异常

13BufferQueue 与 Fence

14生产者：RenderThread queueBuffer 之后，Buffer 进入可消费队列；但 SF 是否能立刻 latch 还要看 acquire fence。present fence 主要用于确认该帧实际送显完成时间。新版本在特定策略下可对 unsignaled buffer 先推进，再在需要时等待 fence。

15消费者 SF 与 BufferTX：SF 在每个合成节拍会尝试为目标 layer 取最新可用 Buffer。若某 layer 的 BufferTX 为 0，通常表示该 layer 暂无新 Buffer，SF 会沿用旧内容继续合成；对这个 App 来说表现为画面停滞/卡顿，但不代表 SF 全局"停止合成"。

16合成策略与显示

17SF 是否频繁走 ClientComposition；HWC validate/present 是否异常

18多显示/模式切换/VRR 时是否伴随明显预测偏差

19资源与其他干扰

20CPU 竞争（大核占用）、GPU 忙、IO/内存抖动（GC/compaction）

21其他前台应用/系统服务是否占用关键资源

参考文档

1Android Graphics Architecture^[17]

2VSYNC Implementation Guide^[18]

3Frame Pacing^[19]

4Perfetto Documentation^[20]

5Android Perfetto 系列 5：Android App 基于 Choreographer 的渲染流程^[21]

6Android Perfetto 系列 6：为什么是 120Hz？高刷新率的优势与挑战^[22]

7Vsync offset 相关技术分析^[23]

8Android 13/14高版本SurfaceFlinger出现VSYNC-app/VSYNC-appSf/VSYNC-sf剖析^[24]

9AOSP - Choreographer.java（main）^[25]

10AOSP - android_view_DisplayEventReceiver.cpp（main）^[26]

11AOSP - DisplayEventDispatcher.h（main）^[27]

12AOSP - DisplayEventReceiver.cpp（main）^[28]

13AOSP - VSyncDispatch.h（main）^[29]

14AOSP - EventThread.cpp（main）^[30]

15Android Multi-display（官方文档）^[31]

16AOSP - VsyncConfiguration.h（main）^[32]

17AOSP - DisplayEventDispatcher.cpp（main）^[33]

18Unsignaled buffer latch（官方文档）^[34]

关于作者

交流与讨论

欢迎到微信群或知识星球交流讨论 Android 性能优化相关话题。

一个人可以走的更快 , 一群人可以走的更远

参考链接

1\] Android Perfetto 系列目录: https://www.androidperformance.com/2024/03/27/Android-Perfetto-101/#/Perfetto-%E7%B3%BB%E5%88%97%E7%9B%AE%E5%BD%95 \[2\] Android Perfetto 系列 1：Perfetto 工具简介: https://www.androidperformance.com/2024/05/21/Android-Perfetto-01-What-is-perfetto/ \[3\] Android Perfetto 系列 2：Perfetto Trace 抓取: https://www.androidperformance.com/2024/05/21/Android-Perfetto-02-how-to-get-perfetto/ \[4\] Android Perfetto 系列 3：熟悉 Perfetto View: https://www.androidperformance.com/2024/05/21/Android-Perfetto-03-how-to-analysis-perfetto/ \[5\] Android Perfetto 系列 4：使用命令行在本地打开超大 Trace: https://www.androidperformance.com/2025/02/08/Android-Perfetto-04-Open-Big-Trace-With-Command-Line/ \[6\] Android Perfetto 系列 5：Android App 基于 Choreographer 的渲染流程: https://www.androidperformance.com/2025/03/26/Android-Perfetto-05-Chorergrapher/ \[7\] Android Perfetto 系列 6：为什么是 120Hz？高刷新率的优势与挑战: https://www.androidperformance.com/2025/04/26/Android-Perfetto-06-Why-120Hz/ \[8\] Android Perfetto 系列 7 - MainThread 和 RenderThread 解读: https://androidperformance.com/2025/08/02/Android-Perfetto-07-MainThread-And-RenderThread/ \[9\] Android Perfetto 系列 8：深入理解 Vsync 机制与性能分析: https://androidperformance.com/2025/08/05/Android-Perfetto-08-Vsync/ \[10\] Android Perfetto 系列 9 - CPU 信息解读: https://www.androidperformance.com/2025/11/12/Android-Perfetto-09-CPU/ \[11\] Android Perfetto 系列 10 - Binder 调度与锁竞争: https://www.androidperformance.com/2025/11/16/Android-Perfetto-10-Binder/ \[12\] 视频(B站) - Android Perfetto 基础和案例分享: https://www.bilibili.com/video/BV1oi82efE4D/?vd_source=0c6d2191e785de0a36dc21a9da7e664e \[13\] 视频(B站) - Android Perfetto 分享 - 出图类型分享：AOSP、WebView、Flutter + OEM 系统优化分享: https://www.bilibili.com/video/BV17A6bBLECu/ \[14\] Systrace 系列目录: https://www.androidperformance.com/2019/05/26/Android_Systrace_0/#/%E7%B3%BB%E5%88%97%E6%96%87%E7%AB%A0%E7%9B%AE%E5%BD%95 \[15\] 个人博客: https://www.androidperformance.com/ \[16\] 关于我: https://www.androidperformance.com/about/ \[17\] Android Graphics Architecture: https://source.android.com/docs/core/graphics \[18\] VSYNC Implementation Guide: https://source.android.com/docs/core/graphics/implement-vsync \[19\] Frame Pacing: https://source.android.com/docs/core/graphics/frame-pacing \[20\] Perfetto Documentation: https://perfetto.dev/docs/ \[21\] Android Perfetto 系列 5：Android App 基于 Choreographer 的渲染流程: https://www.androidperformance.com/2025/03/26/Android-Perfetto-05-Chorergrapher/ \[22\] Android Perfetto 系列 6：为什么是 120Hz？高刷新率的优势与挑战: https://www.androidperformance.com/2025/04/26/Android-Perfetto-06-Why-120Hz/ \[23\] Vsync offset 相关技术分析: https://cloud.tencent.com/developer/article/1905184 \[24\] Android 13/14高版本SurfaceFlinger出现VSYNC-app/VSYNC-appSf/VSYNC-sf剖析: https://blog.csdn.net/learnframework/article/details/133964332 \[25\] AOSP - Choreographer.java（main）: https://android.googlesource.com/platform/frameworks/base/+/refs/heads/main/core/java/android/view/Choreographer.java \[26\] AOSP - android_view_DisplayEventReceiver.cpp（main）: https://android.googlesource.com/platform/frameworks/base/+/refs/heads/main/core/jni/android_view_DisplayEventReceiver.cpp \[27\] AOSP - DisplayEventDispatcher.h（main）: https://android.googlesource.com/platform/frameworks/native/+/refs/heads/main/libs/gui/include/gui/DisplayEventDispatcher.h \[28\] AOSP - DisplayEventReceiver.cpp（main）: https://android.googlesource.com/platform/frameworks/native/+/refs/heads/main/libs/gui/DisplayEventReceiver.cpp \[29\] AOSP - VSyncDispatch.h（main）: https://android.googlesource.com/platform/frameworks/native/+/refs/heads/main/services/surfaceflinger/Scheduler/VSyncDispatch.h \[30\] AOSP - EventThread.cpp（main）: https://android.googlesource.com/platform/frameworks/native/+/refs/heads/main/services/surfaceflinger/Scheduler/EventThread.cpp \[31\] Android Multi-display（官方文档）: https://source.android.com/docs/core/display/multi_display/three-hardware-displays \[32\] AOSP - VsyncConfiguration.h（main）: https://android.googlesource.com/platform/frameworks/native/+/refs/heads/main/services/surfaceflinger/Scheduler/VsyncConfiguration.h \[33\] AOSP - DisplayEventDispatcher.cpp（main）: https://android.googlesource.com/platform/frameworks/native/+/refs/heads/main/libs/gui/DisplayEventDispatcher.cpp \[34\] Unsignaled buffer latch（官方文档）: https://source.android.com/docs/core/graphics/unsignaled-buffer-latch