1. 为什么这次要动 render 新框架
先把背景说清楚。上一篇把 Mesa3D 的基础移植链路打通了，OpenHarmony 上能跑起来 GL 程序，但那只是“能跑”。真正到了产品级验证，问题就冒出来了：原本那套渲染路径还是照着 Linux 传统模式做的设计，在 OpenHarmony 这套以显式 buffer 生命周期管理为核心的图形栈上，明显水土不服。
具体表现就是三件事。第一，buffer 来回拷贝严重，绘制一帧要经历 GPU 写内存、CPU 再读回、合成器再拷贝一次，每帧延时肉眼可见。第二，渲染线程和提交线程耦合太紧，Mesa 内部老框架中的提交逻辑会在 fence 等待上阻塞整个渲染管线的执行，一旦 GPU 驱动响应慢，整个应用卡住。第三，合成管理和 buffer 所有权交接的边界模糊，导致我在对接 OpenHarmony 自带的合成器时，经常出现同一块 buffer 被两边同时操作的情况，轻则闪烁，重则黑屏。
所以这次做 render 新框架，本质上是把渲染提交链路从“能跑”改造成“能流畅跑、能对接显示链路、能把 buffer 生命周期交给系统统一调度”。这个改造思路不是拍脑袋，而是 OpenHarmony 图形栈从架构上就和 Linux 传统的 DRM/Mesa 协作模式有差异，需要我们主动去适配，而不是把 Linux 那一套硬塞进来。
这篇就是完整记录我怎么拆的、怎么对接的、踩了哪些坑，以及最后稳定下来的框架结构。适合正在做 OpenHarmony GPU 适配、Mesa 移植、或者想理解现代渲染框架如何跟系统图形栈协作的朋友参考。有基础的同学可以直接跳到第三节看实操，新手建议从第一节看完，因为后面所有的取舍都基于框架认识。
2. render 框架选型：旧框架哪里不行，新框架强在哪
2.1 旧框架的核心问题：隐式同步和全局锁
Mesa 传统的渲染路径里，buffer 的生命周期管理相对松散，一个 buffer 拿到之后，谁在用、什么时候用完成，靠的是 Fence（栅栏对象）来隐式同步。这个机制在 Linux 桌面环境很成熟，因为那边的合成器和驱动之间有完善的 dma-buf 同步协议。
但 OpenHarmony 的图形栈设计思路不太一样，它有自己的一套显式 buffer 生命周期管理机制：buffer 从分配、填充、提交到回收，每一步都有明确的状态转移，系统级的合成器需要按照状态来决策何时取用 buffer。旧框架那种“谁需要谁拿、用完再同步”的方式，在 OpenHarmony 上就会出现 buffer 状态机和系统预期不一致的情况。再加上旧框架里 Mesa 内部的一个大锁，渲染线程和提交线程同时跑的时候，锁竞争会让 GPU 的并行能力完全发挥不出来。
我在标准测试场景下实测过，旧框架跑复杂场景，GL 线程占用率经常冲到接近满值，但 GPU 的实际利用率只有不到一半。问题就出在渲染线程要等提交线程释放锁才能继续下一帧，CPU 和 GPU 是串行工作的。
2.2 新框架的核心设计：显式状态机加线程隔离
新框架的改造重点，我总结下来有三块。
第一块是显式化 buffer 状态机。把原本靠隐式同步解决的 buffer 使用冲突，改为在每个 buffer 上维护一个明确的状态标记：空闲、渲染中、待提交、合成中、已展示。Mesa 侧在任何一次绘制和提交动作前，都要先确认 buffer 状态合法，否则直接报错返回。这么做之后，buffer 所有权一目了然，系统合成器能在安全的时间点拿到 buffer，不再有踩踏。
第二块是渲染线程和提交线程彻底隔离。渲染线程只管往 buffer 里画图，画完把 buffer 交给提交线程，提交线程负责等待 fence、通知合成器。两个线程之间通过无锁队列传递 buffer 句柄，最大限度减少相互等待。这个设计和现代游戏引擎的渲染架构是一个思路，只是落地到 Mesa 里，需要把原有一大坨耦合代码拆开。
第三块是 fence 管理的集中化。新框架不再由各个模块分别创建和等待 fence，而是统一由一个 fence 管理器维护所有 buffer 的同步对象。渲染线程画完，fence 管理器为这个 buffer 创建 GPU fence；提交线程发现 GPU fence 信号后，再为显示合成创建 present fence。两层 fence 各管各的职责，避免一遇到同步问题就扯不清是谁在等谁。
2.3 为什么坚持用 Mesa 而不是另写一套渲染库
可能有朋友会问，既然 OpenHarmony 有自己的图形栈，为什么不直接对接系统自带渲染，而是非要移植 Mesa？我个人的思考是这样的：Mesa 的价值在于它是一个完整的 OpenGL ES / EGL 实现，自带状态跟踪器、着色器编译器、驱动抽象层，而且它对多种 GPU 架构做了适配，可移植性极强。OpenHarmony 系统层的图形接口虽然完善，但它不会给你一个现成的 OpenGL ES 实现，应用层生态依然需要这个标准接口。
另外，从驱动适配角度讲，Mesa 的 Gallium 框架天然适合对接新平台：只需要实现 winsys 层的若干接口，就能把一个已有的 GPU 驱动集成进来。这次移植也验证了这个优势，真正要写的对接代码量比预期少很多，大部分工作量放在了 buffer 状态协调上，而不是驱动本身。
3. 新框架的整体设计和模块划分
3.1 核心模块边界图（文字示意）
新框架落地后的模块划分，可以用下面这张图来理解：
应用层 | | OpenGL ES API 调用 | EGL 层（EGL 状态管理、context 管理、buffer 匹配） | | 标准 Gallium 内部接口 | Gallium 状态跟踪器 | - 着色器编译 | - draw/clear/texture 状态管 | 驱动层（含 winsys 抽象） | - GPU command submission | - fence 管理 | OpenHarmony 图形适配层（新增核心代码） | - buffer 状态跟踪 | - Gralloc 对接 | - 显示合成器对接 | - 提交线程调度可以看到，我并没有推翻 Mesa 原有的内部结构，而是在驱动层外围加了一层“OpenHarmony 图形适配层”。这一层做两件事：一是把 Mesa 内部要的 buffer 转换成 OpenHarmony 图形栈能识别的 buffer；二是把 Mesa 提交渲染结果的流程转换成系统合成器能接受的流程。这也是移植类工作最常见的架构方式，尽量少动原系统的核心逻辑，把适配集中在外围。
3.2 这个划分的好处和取舍点
这样划分最大的好处是职责单一。Mesa 内部的状态跟踪、着色器编译、draw 调用这些逻辑完全不用动，保留了 Mesa 的稳定性和性能；OpenHarmony 侧的 buffer 管理、合成器调度也不用侵入式修改，两边各干各的。以后无论是升级 Mesa 版本，还是适配新 GPU，改动范围都被限制在这一层适配层里，出问题也能快速定位。
取舍点在于：适配层是性能关键路径，数据传输不能有额外拷贝，函数调用层级也不能太深。我在实现时用了直接函数指针跳转，没有用抽象接口类，虽然牺牲了一点面向对象的优雅，但每一帧调用路径上少了两三次间接跳转，性能上赚回来了。
另外，线程模型的实现放在了适配层内部，没有动 Mesa 原有的线程管理。渲染线程和提交线程的创建、销毁、唤醒逻辑都是适配层自己控制，Mesa 侧只通过一个轻量级的提交接口感知到另一个线程存在。这样 Mesa 本身依然可以保持无状态的线程模型，不会引入额外的复杂性和 bug 风险。
4. 核心对接细节：EGL、Gralloc、合成链路逐项拆解与落地
4.1 EGL 层的关键扩展实现
EGL 层是应用直接接触的第一层，它的核心职责是把应用申请的 WindowSurface 转换成 Mesa 能绘制的 buffer。在新框架里，这一步的逻辑变复杂了，因为 buffer 需求来自两个地方：应用要求绘制尺寸和格式（比如 EGL_RED_SIZE 8、EGL_ALPHA_SIZE 8），系统合成器则要求 buffer 必须满足显示链路对对齐、压缩格式的要求。
我实现的具体流程是这样的：
分配 buffer 时，先用 OpenHarmony 图形栈的 buffer 分配接口申请一块满足显示要求的 buffer，然后把它的句柄导入到 Mesa 的驱动层。Mesa 拿到句柄后，会创建对应的资源结构，并把它和 EGLSurface 绑定。后续应用的每次 eglMakeCurrent 和 glSwapBuffers 都直接操作这块 buffer，不再额外申请。
在这个过程中，EGL 层还要维护一个 buffer 匹配逻辑：应用期望的格式不一定和系统实际分配的格式完全一致，比如应用要 RGB565，但系统为了显示效率可能分配成 RGBA8888。EGL 层要在这里做透明转换，应用拿到的绘制格式是它自己申请的，但实际写入的 buffer 是系统指定的格式。转换原理就是在 Mesa 内部设置一个 RGA 格式转换步骤，用 GPU 完成色彩格式和排列的转换，避免 CPU 参与。这部分代码我调整了三次才稳定，第一次是没考虑行对齐 padding，第二次是没处理双缓冲切换时的格式一致性问题，后来把 check 逻辑放在每次 swap 前重新验证一次，才算稳定下来。
4.2 winsys 层：如何把 Gralloc 的 buffer 导入到 Mesa 驱动
winsys 层是 Mesa 驱动和系统图形内存打交道的窗口。在 Linux 上，通常是通过 GEM/DRI 接口导入 fd 完成；在 OpenHarmony 上，需要用自身的 buffer 管理接口导入句柄。
这里有一个重要的概念：文件描述符（fd）和系统 buffer 句柄的区别。Linux 上大家习惯用 fd 来共享 buffer，OpenHarmony 的图形栈则使用自己定义的 buffer 句柄机制。为了打通两个世界，我在 winsys 层实现了两个方向的转换：
- Mesa 绘制完成后，把内部 buffer 以 fd 形式导出，再通过 OpenHarmony 的导入接口封装成系统句柄，交给合成器。
- 系统合成器想要复用 buffer 时，把系统句柄重新导入到 Mesa，包装成 GPU 可访问的对象，继续下一轮绘制。
这个 fd 和句柄的转换核心工作是维护一张 buffer 映射表：一端指向 Mesa 的资源对象，另一端指向系统句柄。映射表必须保证同一个 buffer 在 Mesa 侧和系统侧是同一个物理内存，不能出现复制。我在实现时直接使用了物理内存复用方式，只传递内存信息，不做数据拷贝，这样性能损失基本为零。
4.3 fence 管理框架：两段式同步的精要
新框架的 fence 管理是整个性能优化的关键，也是踩坑最多的部分。不夸张地说，没有两段式 fence 设计，新框架的线程隔离就是空的，因为线程不等 fence 就没有安全性。
两段式指的是 GPU fence 和显示 fence 分开管理：
第一段是 GPU fence。渲染线程完成一次 glSubmit 之后，驱动为每块 buffer 生成一个 GPU fence，标识“GPU 到此还在写这块 buffer”。提交线程在把它交给合成器之前，必须等待这个 fence 信号完成。
第二段是 present fence。合成器取走 buffer 并完成显示扫描后，会生成一个显示 fence，标识“这块 buffer 可以再次被渲染使用了”。渲染线程下一轮拿这块 buffer 前，要检查这个显示 fence 是否已经信号。
这样的设计让每一块 buffer 在任何时刻都有明确的使用者归属，不会发生 CPU 读取一块 GPU 还在写的 buffer 这类低级错误。我在调试时曾经因为漏等了显示 fence，导致画面出现周期性撕裂条纹，后来发现就是双缓冲切换时，渲染线程提前拿到了上一帧还没显示完的 buffer。加入显示 fence 检查之后，这个现象彻底消失。
4.4 显示合成链路对接：提交线程怎么和合成器协作
新框架里，提交线程承担了和系统合成器通信的职责。它的主循环如下：
- 从无锁队列里拿一块渲染完成的 buffer（渲染线程放进去的）。
- 对该 buffer 对应的 GPU fence 进行等待，超时机制设为系统最大帧间隔的一半，约 8 毫秒。如果等待超时，提交线程强制跳过该 buffer，并打日志告警，防止卡死整个管线。
- fence 信号完成后，提交线程把 buffer 句柄写入合成器的输入队列，并触发合成器合成。
- 合成器完成显示后，合成器通过回调函数通知提交线程序幕已经显示，此时提交线程负责把 buffer 归还给渲染线程的可用队列。
这里最关键的设计是第 3 步，写入合成器输入队列的时机不能太早、也不能太晚。太早了合成器还没准备好接收 buffer，会触发内部报错；太晚了显示链路会出现空档，造成帧率下降。我在实现时做了一个动态背压机制：提交线程通过查询合成器的队列占用情况，决定是否等待片刻再写入。实测下来，合成器队列保持 1 到 2 个待合成 buffer 是最佳状态，太少会让屏幕偶尔闪动，太多会累积延迟。
还有一个细节是渲染线程和提交线程之间的无锁队列怎么保证不丢 buffer。我的方案是使用一个固定大小的环形数组，渲染线程写入时递增提交索引，提交线程读取时递增消费索引。环形数组的大小直接决定可以同时在途的 buffer 数量，我设置为 6，足够覆盖三缓冲加系统合成延迟，又不会占用太多内存。后续如果你想调优，这个参数是关键，可以根据实际 GPU 性能和合成器延迟来调整。
5. 实操：渲染新框架接入的完整配置与参数选择
5.1 环境准备和基础配置
开始接线之前，需要确认你手里的 OpenHarmony 版本和 Mesa 源码版本。我的验证基于某厂商发行的 OpenHarmony 稳定版本和 Mesa 的某个发布分支，整体改动集中在图形适配层，对 Mesa 本身的改动非常少，所以如果你用其他版本，大概率也能参考。
必要的基础环境包括：
- OpenHarmony SDK 和对应的系统源码（用于编译和集成）
- 目标设备的编译工具链（交叉编译用）
- 一个可用的 GPU 驱动源码或驱动二进制库（只要你准备对接那个 GPU）
- 足够的内存和编译资源，Mesa 编译比较吃配置，建议至少 8G 内存
配置时有一个容易忽略的点：OpenHarmony 的 dsoftbus 等周边模块会和图形栈有间接耦合，如果编译时缺组件，优先查图形服务模块是否完整，而不是去查 Mesa 侧。我在第一次集成时，系统编译一直报一个缺少graphic_utils头文件的错误，排查到最后发现是图形服务模块没编进去，白白浪费了一下午。
5.2 winsys 对接步骤：从启动到第一帧（代码级）
整个对接流程最核心的步骤就是用代码打通 winsys。这里我给出一个简化版的关键路径，工具是 C 语言风格的伪代码加注释说明。
第一步，注册 winsys 到 Mesa：
// 注册 OpenHarmony winsys，在 Mesa 初始化时调用 struct pipe_screen *ohos_create_screen(struct drm_device *dev) { // 初始化 winsys 内部状态 struct ohos_winsys *ws = calloc(1, sizeof(*ws)); // 设置回调函数，所有 Mesa 驱动需要的操作都挂到这里 ws->base.screen_create = ohos_screen_create; ws->base.buffer_from_handle = ohos_buffer_from_handle; ws->base.buffer_to_fd = ohos_buffer_to_fd; ws->base.fence_create = ohos_fence_create; ws->base.fence_wait = ohos_fence_wait; // 把 winsys 挂到 Mesa 的全局驱动列表 return &ws->base; }第二步，实现 buffer 导入函数，把系统句柄转换成 Mesa 资源：
struct pipe_resource *ohos_buffer_from_handle(struct pipe_screen *screen, struct winsys_handle *whandle) { // whandle->handle 是从 Gralloc 拿到的系统 buffer 句柄 int fd = ohos_gralloc_export_fd(whandle->handle); // 调用 Mesa 的通用导入逻辑，把 fd 变成 GPU 可见的资源对象 struct pipe_resource *res = NULL; struct pipe_resource tmpl = {0}; tmpl.width0 = whandle->width; tmpl.height0 = whandle->height; tmpl.format = whandle->format; // 这里是关键：必须复用内存，不能做 memcpy res = screen->resource_create(screen, &tmpl); // 将 fd 绑定到资源对象上 screen->resource_from_fd(screen, res, fd); return res; }第三步，实现 fence 创建和等待：
struct pipe_fence *ohos_fence_create(struct pipe_screen *screen, int fd) { // fd 是 GPU 驱动返回的同步对象 fd struct ohos_fence *fence = calloc(1, sizeof(*fence)); fence->fd = fd; // 注册到框架的 fence 管理器 ohos_fence_manager_add(fence); return &fence->base; } boolean ohos_fence_wait(struct pipe_fence *fence, uint64_t timeout) { // 等待 GPU 完成工作 int ret = poll(NULL, 0, 0, timeout); // 简化示意 return ret >= 0; }这只是最简路径，实际代码还要处理错误处理、资源释放、buffer 复用管理，但核心链路就是这个。先把这三步跑通，能稳定出现第一帧画面，剩下的事情基本都是围绕细节打磨。
5.3 渲染新框架配置参数对照表
为了让移植工作更可控，我把常用的配置参数整理成了一张表，方便你按需调整：
| 配置项 | 默认值 | 说明 | 调优建议 |
|---|---|---|---|
| 环形队列深度 | 6 | 渲染线程提交时使用的在途 buffer 数 | GPU 负载高时适当调大，但不要超过显示链路延迟上限 |
| GPU fence 超时 | 8ms | 提交线程等待 GPU 完成的最大时间 | 如果频繁超时，优先查驱动性能，不要盲目加大数值 |
| 合成器队列深度 | 2 | 提交线程写入合成器队列的 buffer 数 | 屏幕偶尔闪动时降低，延迟偏大时提高 |
| buffer 格式匹配模式 | 自动转换 | EGL 层对应用格式和系统格式做自动转换 | 如果能确保应用和系统格式一致，可以关闭自动转换省开销 |
| fence 管理器线程 | 独立线程 | 等待 fence 并回调通知提交线程 | 如果 CPU 核数充足，保持独立线程；核数紧张时并入提交线程 |
这里我想强调的是，配置参数不是越大越好，也不是越小越好，一定结合具体的使用场景。比如环形队列深度，你画 2D 简单场景的时候，6 个 buffer 完全够用，但如果你跑 3D 游戏，帧率一高，队列深度不够就会导致渲染线程无法及时提交新帧，帧率反而下降。我在复杂 3D 场景下试过 8 个队列深度，帧率稳定性和 6 个没有显著差异，但内存占用增加了，所以最终保留了默认值 6。
5.4 可信的验证方法和基准数据
配置完成后，验证是必不可少的。最基础的验证是跑一个简单的 GLES 动画程序，观察三点：帧率是否稳定、是否出现闪烁撕裂、CPU 占用率是否正常。这个验证通过后，再上强度，用持续变化的复杂场景压测。
我实测的基准数据供参考：某个中等复杂度的 3D 场景，新框架下帧耗时稳定在 11 到 13 毫秒，CPU 占用率在 25% 到 35% 之间波动；旧框架同时期的数据是帧耗时 16 到 19 毫秒，CPU 占用率 40% 到 50%。性能提升的主要来源不是 GPU 更快了，而是 CPU 等待时间大幅缩短，渲染和提交真正并行起来了。这也说明，新框架的核心价值在于让 CPU 和 GPU 协作效率更高，而不是单纯某一块变快。
6. 问题排查：移植过程中踩过的典型坑和解决方法
6.1 遇到的实际问题与解决过程
移植过程中遇到问题很正常，关键是每个问题背后有没有系统性的排查思路。下面是我的真实踩坑记录，按出现频率排序：
第一个高频问题是 eglSwapBuffers 之后 CPU 要等很久才能拿到下一帧 buffer。排查后发现是 fence 等待超时设置太保守，GPU 任务已经完成，但 fence 没有及时查看。解决方法是让提交线程的 fence 等待变成中断驱动，而不是轮询，这样 GPU 完成时提交线程能立刻被唤醒。这个改动之后，CPU 等待时间从平均 5 毫秒降到了 0.5 毫秒左右。
第二个问题是合成器偶发报 buffer 状态错误。这个问题的根源是 buffer 状态切换的时序不对，合成器已经接受了 buffer，但适配层还没来得及把状态从“待提交”改成“合成中”。解决方式是引入一个轻量级的状态提交锁，只保护状态切换这一小段代码，不影响整个渲染路径。加上这个锁之后，合成器报错频率直接降为零。
第三个问题是首次接入时画面完全黑屏，没有任何输出。查到最后发现是 EGL 层和 winsys 的 buffer 尺寸匹配出了问题，我拿到 buffer 的实际尺寸是系统对齐后的，而 Mesa 内部的 framebuffer 尺寸还是应用原始尺寸，导致绘制内容只出现在 buffer 左上角一小块区域。解决方法是 winsys 层把系统对齐后的真实尺寸回传给 EGL 层，EGL 层用真实尺寸做 framebuffer 裁剪。这个问题说明，移植时不能只看逻辑尺寸，系统硬件对齐参数必须透传到 Mesa 侧。
6.2 常见问题速查表
| 错误现象 | 可能原因 | 排查工具/方法 | 解决方案 |
|---|---|---|---|
| 屏幕黑屏无输出 | EGL 与 winsys 尺寸不匹配 | 打印 EGL 设置的尺寸和 winsys 返回的 buffer 尺寸做对比 | 统一用系统对齐后的真实尺寸创建 framebuffer |
| 画面周期性撕裂 | 渲染线程提前拿到未显示完成的 buffer | 检查 fence 状态日志 | 引入 present fence 等待机制 |
| 帧率突然掉一半 | 环形队列深度不足或 fence 超时 | 统计队列满的次数和 fence 等待超时次数 | 按场景调整环形队列深度和 fence 超时 |
| 合成器报 buffer 状态非法 | 状态切换时序和合成器不匹配 | 开启合成器 debug 日志 | 加状态提交锁保护状态切换 |
| CPU 占用率居高不下 | fence 轮询等待占用太多 CPU | 性能分析工具看热点函数 | 改为中断驱动等待 |
| 内存无明显增长但画面卡顿 | buffer 泄漏，帧率下降 | 检查 buffer 分配和释放日志 | 完善 buffer 映射表的销毁逻辑 |
6.3 一条通用的排查方法论
有个经验值得单独拿出来分享：遇到图形栈问题，永远先分边。一个问题出现时，先判断是应用侧问题、Mesa 侧问题、驱动侧问题，还是系统图形栈问题。怎么判断？开对应的 debug 日志，同时观测 CPU 侧调用链和 GPU 侧任务耗时，任何一边异常都能快速定位方向。最忌讳的就是一个问题同时怀疑好几个模块，东改改西改改，最后问题还在。
我自己的习惯是问题出现后第一步打印三个时间点：应用发出 swap 的时间、Mesa 内部提交完成的时间、合成器完成合成的时间。三个时间点之间的间隔，直接告诉你延迟耗在哪个环节。比如 swap 到 Mesa 提交完成消耗过大，问题大概率在 Mesa 的绘制路径上；Mesa 提交完成到合成器完成消耗过大，问题大概率在 buffer 交接或 fence 等待上。这个方法在我的移植过程中解决了至少八成问题。
7. 一个容易被忽略的关键点：debug 日志体系
移植这套框架时，我还投入了不少时间搭建 debug 日志体系，这件事前期看起来不紧急，后期帮了大忙。建议你一定要在一开始就搭好，不然后面出了问题再补，debug 成本成倍增长。
我的日志体系分为三层：
第一层是进入退出日志。每次进入 EGL 关键函数、每次 swap、每次 fence 等待时打一行 ACK 日志，记录当前时间戳。这一层帮助快速判断哪个环节延迟大。
第二层是状态机日志。所有 buffer 状态切换的瞬间打日志，记录 buffer id、旧状态、新状态和触发者。这层帮你在 buffer 状态异常时迅速回溯是谁在什么时间把状态改错了。
第三层是性能快照日志。每隔一定帧数统计一次平均帧耗时、最长帧耗时、fence 等待次数、队列满的次数。这层帮你判断优化方向和确认优化效果。
这三层日志在正式发布时可以用配置开关关闭，不会影响线上性能；但开发调试期间必开，尤其是前两周刚接入阶段。我在接入阶段因为这些日志少走了很多弯路，比如有一次平台层偶现画面冻结，靠状态机日志发现某驱动在某个时间点漏发了一个 fence 信号，后续我直接和驱动团队确认了这个问题，修在驱动侧，比在框架侧绕来绕去高效得多。
8. 移植完成后的体验和建议
整套新框架跑通之后，再回头看这次移植工作，我最大的体会是：移植工作最难的往往不是技术本身，而是对两个系统的理解深度。OpenHarmony 图形栈和 Linux 图形栈乍一看很像，功能都有，但底层的设计哲学和协作模型差异很大，照搬裁剪只能做到能跑，做不到好跑。
具体说，如果你也想做类似工作，有几点建议可以节省你的时间：
第一，动手前先花时间把 OpenHarmony 图形栈的 buffer 状态流转文档读透，尤其是 buffer 从分配到展示的完整生命周期。不要像我一开始那样，边写边查，后面返工改数据结构，浪费时间。
第二，最好能拿到一个 GPU 驱动的开发调试版本，允许你在驱动层打日志和打断点。fence 相关的问题如果只能在应用层观察，往往要多花好几倍时间。
第三，把 Mesa 源码里 winsys 层的代码从头读一遍，理解每个函数在正常流程里什么时候被调用、谁调用、参数含义。这个阅读工作看起来枯燥，但对接时你会感谢自己读了，不然很多异步调用关系你想不明白。
这套 render 新框架接入完成后，我验证过的场景包括常规 GLES 动画、复杂 3D 场景、多窗口合成和视频硬解叠加，整体都稳定达标。如果你手头正在做类似的移植工作，遇到具体问题也可以按照我上面分享的分边排查法去定位，十之八九能快速找到方向。后面如果有机会，我再单独写一篇关于 fence 管理和性能调优的深入内容，把这次调优过程中的一些更细的数据和参数演进过程展开聊聊。
