弹幕引擎 (一) 从流式渲染架构与批式渲染架构说起

8 - 渲染引擎, 8.4 - 高性能弹幕引擎 本文总阅读量次

两种渲染架构

这两种架构代表了计算机科学中处理任务的两种截然不同的哲学：“流式”追求实时响应（Latency-Optimized），而“批式”追求吞吐与效率（Throughput-Optimized）。

在 Android 图形系统中，将这两者强行整合在一起，本质上就是在处理“阻抗不匹配”（Impedance Mismatch）问题。

流式架构 (Streaming Architecture) —— “持续交付”

流式架构的核心在于即时性。数据一旦产生，就必须尽快通过管道流向目的地，系统的目标是最小化“端到端延迟”（End-to-End Latency）。

  • 核心原则：Event-Driven（事件驱动）。每一条数据（Frame）都是一个独立处理的事件。
  • 时间观念：基于“数据到达时间”（Event Time）。渲染引擎产生一帧，就意味着该帧必须立即显示。
  • 系统特征：
    • 低延迟：不等待后续数据，无需缓存队列。
    • 恒定开销：渲染引擎需要保持持续的计算负载，无法利用“闲时休息”来节省资源。
    • 不可预测性：数据的到达频率若波动，系统必须能立即响应，否则就会造成抖动。

在你的架构中：OpenGL 渲染线程就是典型的流式架构，它要求“此时此刻”就要渲染出当前状态。

批式架构 (Batching Architecture) —— “批量吞吐”

批式架构的核心在于优化总成本与效率。它故意引入“延迟”，将多次小的操作合并为一次大的操作（Coalescing），目的是摊薄系统调用的开销。

  • 核心原则：Task-Coalescing（任务合并）。等待任务累积到阈值（时间片或数量），再一次性提交。
  • 时间观念：基于“系统时钟”（System Cycle/Tick）。无论任务多早完成，都必须等待下一个“发车时刻”（VSync 信号）。
  • 系统特征：
    • 高效率：通过减少上下文切换、减少 CPU/GPU 切换、利用 CPU 缓存亲和性，降低单次任务的平均成本。
    • 高吞吐：在单位时间内处理更多数据。
    • 容忍延迟：只要最终结果符合预期的交付周期，内部的处理顺序和时机可以灵活调整。

在你的架构中：Android View 系统（ViewRootImpl）就是批式架构，它把所有的 UI 更新请求收集起来，等到 Choreographer 信号到来时，统一进行遍历（Traversal）。

为什么两者会产生冲突？（底层哲学冲突）

这种冲突在工程上被称为 “时域上的不兼容”：

  1. 处理模型的“错位”：
  • 流式架构要求“随时”处理任务。
  • 批式架构要求“准点”处理任务。
  • 当流式产生的数据（OpenGL 帧）试图进入批式系统（View 树）时，它会被强制进入“等待队列”。这种等待，人为地将原本平滑的流打断了。
  1. 吞吐量与延迟的权衡（Trade-off）：
  • Android 系统设计 View 系统的批式处理，是为了让整个 App 的界面渲染更加经济（省电、省 CPU），这是为了全局最优。
  • 但你的渲染引擎是局部优化（追求单组件的极致平滑），这与全局策略产生了利益冲突。

理解这两个架构

**私家车 (Streaming / OpenGL 渲染线程)**：你是驾驶者，追求的是“随到随走”。你的油门由你的引擎逻辑（渲染循环）控制，你希望以恒定的 60km/h（60fps）在路上行驶。

**轮渡 (Batching / Android View 系统)**：这是公共交通系统，它严格遵循“时刻表”运行。轮渡只在固定的时刻（VSync 信号）才会靠岸并进行装载（Traversal 绘制流程）。

码头闸机 (mWillDrawSoon)：这是码头管理处。它的规则是：如果轮渡已经在准备启航了（mWillDrawSoon = true），为了保障航行安全，码头闸机必须关闭，不再允许任何车辆进入码头。

GLSurfaceView 与 GLTextureView 的架构本质对比

首先需要明确一点：Android 原生 SDK 中并没有 GLTextureView 这个类。通常开发者会使用 TextureView 并配合自定义的 OpenGL 渲染逻辑来实现类似的功能。

我们将这一逻辑架构下的组件称为 **GLTextureView**（即自定义封装了 OpenGL 渲染能力的 TextureView）。以下是重写后的对比分析：

如果说 GLSurfaceView 是将“流”直接注入到了图形合成器（SurfaceFlinger）的轨道上，那么 GLTextureView 则是将渲染出的“流”强行塞入了一个 View 系统的“容器”中。

以下是 GLTextureView 作为“批式容器”架构的三个关键原则：

1. 受限的生产自主权（依附于 View 树）

  • 原理：GLTextureView 本质上是一个 TextureView。它的生命周期、测量（Measure）、布局（Layout）和绘制（Draw）完全被 ViewRootImpl 的调度所接管。
  • 对比：GLSurfaceView 拥有独立的 Surface，直接对冲系统合成器；而 GLTextureView 的渲染产出必须作为 View 树的一个 Layer，每一帧都必须经过 View 系统繁琐的 traversal 流程才能上屏。
  • 结论：它无法摆脱 mWillDrawSoon 的锁链。因为它的生产过程必须等待主线程的 View 遍历周期（Traversal），它被迫服从 UI 系统的调度频率，而不是自主的渲染频率。

2. “被动式”的渲染循环（受限于 UI 节拍）

  • 原理：虽然 GLTextureView 内部也可以开辟渲染线程，但它的数据交付（Commit）必须通过 SurfaceTexture 触发 invalidate() 或 requestLayout()。
  • 时序耦合：它的数据上屏时间必须与 UI 主线程的 VSync 信号对齐。当 ViewRootImpl 处于 performTraversals() 的忙碌期时，渲染线程提交的数据会被“搁置”或“合并”。
  • 结论：它是典型的“批式”架构。渲染线程虽然在独立生产，但数据被 View 系统“缓存”在 TextureView 的缓冲区中，必须等到 View 系统允许绘制时，才能通过合成流程输出。

3. 数据流的“二次转运”（非零拷贝）

  • 原理：在 GLTextureView 中，你的 OpenGL 渲染结果先写入 SurfaceTexture，然后需要经过 GPU 拷贝/转换到 View 的 Layer 纹理中（由 UI 系统合成）。
  • 对比：GLSurfaceView 的数据流是“直通”的，它直接作为 Surface 层被合成器读取。而 GLTextureView 存在一个“转运”过程——View 系统必须先获取 SurfaceTexture 的数据，将其合成到整个 App 的 UI 树中，这个过程增加了额外的 CPU/GPU 调度开销，也正是延迟的来源。

GLTextureView 抖动的问题

我们将 GLTextureView 定义为一个“强行塞入批式容器的流式渲染组件”。这种架构上的错位，是导致渲染抖动（Jitter）的根本源头。在高性能弹幕引擎的开发中，这种抖动并非逻辑错误，而是时序调度上的“水土不服”。

渲染流与 UI 循环的“错位”

GLTextureView 的最大痛点在于其双重时钟依赖：

  • 内部时钟（Render Thread）：负责产出渲染帧，通常以恒定速率（如 60fps/120fps）运行。
  • 外部时钟（ViewRootImpl）：负责 UI 的 measure/layout/draw，严格受 VSync 信号驱动，具有极高的间歇性和突发性。

当 OpenGL 线程完成一帧渲染时，它通过 SurfaceTexture 更新回调通知 UI 线程。然而，View 系统并不总是处于“准备好接收”的状态。一旦 View 树中出现了耗时布局（如嵌套过深的 Layout 或频繁的 invalidate），UI 线程就会进入长时间的 performTraversals 周期。

此时，渲染帧被迫“滞后”。对于肉眼而言，这就形成了抖动：上一帧间隔 16ms，由于被拦截，下一帧间隔变成了 32ms，再下一帧为了追赶进度，可能在 10ms 就执行了。这种帧呈现时长（Frame Presentation Time）的剧烈波动，就是用户感知到的“顿挫感”。

调度拦截：mWillDrawSoon 导致的“闸机锁死”

回顾我们提到的“码头闸机”比喻，mWillDrawSoon 就是那个一旦合上就绝不通融的机制。

在 GLTextureView 中，invalidate() 逻辑是其更新 UI 的唯一入口。当 OpenGL 线程频繁调用 invalidate() 请求更新时：

  • 如果 UI 线程正在执行布局任务：ViewRootImpl 会将 mWillDrawSoon 置为 true。
  • 拒绝服务：此时 TextureView 发出的重绘请求会被系统判定为“冗余”，直接丢弃或合并。
  • 视觉后果：OpenGL 线程以为这一帧已经提交成功，但实际上它在缓冲区（BufferQueue）中被“锁”住了，直到 UI 线程完成当前循环并处理下一个 traversal。这种强制的等待，使得原本流畅的弹幕运动轨迹在某一瞬间“卡”住了。

缓冲区失衡：挤压与丢帧的博弈

由于 GLTextureView 本质上是一个 TextureView，它必须通过 BufferQueue 与 SurfaceFlinger 握手。这里的生产与消费关系极易失衡：

  • BufferQueue 挤压 (Congestion)：如果你的 OpenGL 渲染引擎产出过快（例如渲染线程没有设置 Frame Rate 限制），BufferQueue 会迅速填满。此时，如果 TextureView 的消费能力跟不上，会导致系统阻塞 Producer 或产生明显的输入延迟（Input Lag）。用户会感觉弹幕“跟手性”很差，仿佛有一层厚厚的阻尼感。
  • 帧丢弃 (Frame Drop)：如果系统为了维持 App 的整体流畅度，配置了 DROP_OLDEST 策略，那么当 BufferQueue 满载时，旧帧会被直接丢弃。对于弹幕引擎来说，这意味着弹幕位置的“跳跃”——上一秒弹幕还在屏幕左侧，下一秒直接出现在了右侧，运动轨迹的连续性被彻底破坏。

这是一个非常经典的“时序冲突”模型。通过“私家车、轮渡、码头闸机”的比喻，我们可以清晰地看到卡顿（Jitter）是如何从“微观等待”演变成“宏观视觉抖动”的。

让我们把这个过程拆解为三个阶段，来看看你的“私家车”是如何在码头被迫经历那场“抖动”的。

第一阶段：完美的节奏 (平滑渲染)

  • 状态：码头（View 系统）一切正常，轮渡（VSync）准时靠岸。
  • 过程：你的私家车（渲染帧）以 60km/h（16.6ms/帧）的速度匀速行驶。每一辆车到达码头时，闸机（mWillDrawSoon）都是打开的。
  • 结果：车子顺利开上船，轮渡准时出发。观众看到的是均匀平滑的动画。

第二阶段：闸机锁死 (卡顿发生的瞬间)

  • 状态：轮渡（UI 线程）突然变得极其忙碌。因为它是“公共交通”，它不仅要装你的车，还要处理一大堆复杂的“乘客”（View 树的 Measure/Layout 布局计算）。
  • 冲突：当你的车（新的一帧）准时到达码头时，闸机管理员（ViewRootImpl）看了一眼忙碌的甲板，大喊一声：“轮渡已经准备发船了，现在是 mWillDrawSoon = true，闸机关闭！”
  • 过程：你的车被迫停在码头干等。虽然引擎（OpenGL 线程）还在轰鸣，但你被拦在了闸机外。

第三阶段：抖动 (Jitter 的视觉真相)

抖动并不是因为你“停下”了，而是因为你被迫改变了行驶节奏。

  1. 车 1：顺利上船，第 0ms 出发。
  2. 车 2：到达时闸机已关闭，被迫在码头等到了第 32ms，才赶上下一班轮渡。
  3. 车 3：轮渡恢复正常，第 48ms 出发。

视觉上的“抖动”感由此产生：

  • 节奏断裂：观众看到的画面间隔是：16ms -> 32ms -> 16ms。
  • 这种不一致才是“抖动”的本质。如果所有的车都等 32ms，那画面看起来只是“慢”（30fps）；但因为你一会儿 16ms，一会儿 32ms，这种节奏的剧烈突变，导致人眼立刻捕捉到了弹幕轨迹的“顿挫”或“瞬移”。

深入理解：为什么闸机关闭会导致“抖动”？

在技术层面，这个过程有三个细节决定了抖动的严重程度：

  1. “被迫排队”的后坐力：
    当闸机（mWillDrawSoon）最终打开时，轮渡（View 系统）可能会因为刚才的积压，导致下一次发船更加匆忙。这种“忽快忽慢”的调度节奏，会将你的私家车（OpenGL 帧）的交付周期彻底搞乱。

  2. BufferQueue 的“洪峰效应”：
    在闸机关闭期间，你的 OpenGL 引擎并没有停下来，它还在持续不断地往码头输送“车流”。如果你的缓冲区（BufferQueue）有限，闸机一打开，可能会瞬间涌入好几辆车。系统为了追赶进度，可能会直接丢弃中间的车，这就会导致“跳帧”——你原本打算显示的弹幕运动过程，被直接跨越了，导致视觉上的“瞬间跳跃”。

  3. 不确定性的“黑盒”：
    最可怕的是，作为“私家车”驾驶员（渲染线程），你根本不知道码头闸机什么时候关，什么时候开。你唯一的感知就是：我明明踩着油门，速度却被这个码头的交通规则强制修正了。

总结

抖动，其实就是你的渲染引擎（私家车）试图维持恒定节奏，却被系统的调度规则（码头闸机）强行改写了发车时间。

反压机制（抖动变卡顿）

反压（Backpressure） 是计算机科学中用于处理“生产者速度过快，而消费者消费速度跟不上”这一矛盾的调节机制。

简单来说，当系统无法处理此时到达的流量时，通过某种手段“向上游”发出信号，让上游放慢速度。

通过人工手段将一个异步、非确定性的系统（Async/Unpredictable），强行转化为一个同步、确定性的“步进系统”（Lock-step）。

从工程学的角度来看，“将不可控的抖动（Jitter）转化为可控的卡顿（Stutter）”，在很多高性能实时系统（如游戏引擎的帧率锁定）中，是一个非常经典的优化策略。

实现方案

在 TextureView 中添加一个 mHasContentToDraw，监听到有待绘制的下一帧或者 swapBuffer 之后，设置为ture，阻止新的帧绘制，在 onSurfaceTextureUpdated 之后设置为 false，这样，把抖动变成卡顿

mHasContentToDraw = true

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
@Override
public void onSurfaceTextureAvailable(SurfaceTexture surface, int width, int height) {
    try {
        Field listenerField = SurfaceTexture.class.getDeclaredField("mOnFrameAvailableListener");
        listenerField.setAccessible(true);
        final SurfaceTexture.OnFrameAvailableListener originalListener = (SurfaceTexture.OnFrameAvailableListener) listenerField.get(surface);
        surface.setOnFrameAvailableListener(new SurfaceTexture.OnFrameAvailableListener() {
            @Override
            public void onFrameAvailable(SurfaceTexture surfaceTexture) {
                mHasContentToDraw = true;
                if (originalListener != null) {
                    originalListener.onFrameAvailable(surfaceTexture);
                }
                postInvalidate();
            }
        });
    } catch (Exception e) {
        Log.e(TAG, "Fail to hijack ST", e);
    }
    mGLThread.surfaceCreated();
    onSurfaceTextureSizeChanged(surface, width, height);
}
1
2
3
4
5
6
7
8
9
10
11
public int swap() {
    if (! mEgl.eglSwapBuffers(mEglDisplay, mEglSurface)) {
        return mEgl.eglGetError();
    }
    GLTextureView view = mGLTextureViewWeakRef.get();
    if (view != null) {
        view.mHasContentToDraw = true;
        view.postInvalidate();
    }
    return EGL10.EGL_SUCCESS;
}

mHasContentToDraw = false

1
2
3
4
@Override
public void onSurfaceTextureUpdated(SurfaceTexture surface) {
    mHasContentToDraw = false;
}

原生的状态：Producer（GL 线程）和 Consumer（UI 线程）处于“失联”状态，GL 线程只管拼命生产，UI 线程只管按自己的频率消费。这种异步导致了 BufferQueue 经常发生竞态条件（Race Condition），从而产生了抖动。

改进的方案：渲染管线从“异步并发”变成了“同步串行”。这种步进式（Step-by-step）的渲染，确实消除了随机的时序错乱（Jitter），将其变成了固定的帧处理间隔。

8 - 渲染引擎, 8.4 - 高性能弹幕引擎