27、游戏引擎集成：Unity/Unreal引擎图形管线适配、NativeWindow交互、EGL context管理
说实话，游戏引擎集成这块，是我在Android图形系统优化里踩坑最多的地方。Unity和Unreal这两个大家伙，它们的图形管线跟咱们原生Android应用完全不是一个思路。你想想看，原生应用顶多是个SurfaceView或者TextureView，但游戏引擎一上来就要接管整个渲染流程，从EGL context创建到帧缓冲区管理，全都要自己说了算。
我记得第一次接手一个Unity手游项目时，对方反馈说在部分机型上黑屏。我查了半天，最后发现是EGL context的共享模式没处理好。嗯，今天咱们就把这块彻底讲透。
Unity/Unreal的图形管线适配
先说清楚一个核心问题：Unity和Unreal在Android上是怎么工作的？
它们本质上都是通过NativeWindow直接与SurfaceFlinger交互。什么意思呢？就是它们不走Java层的Canvas绘制，而是直接操作ANativeWindow，把渲染好的帧提交给显示系统。
Unity的渲染管线大致是这样的：
Unity引擎 → 图形API(OpenGL ES/Vulkan) → EGL context → ANativeWindow → SurfaceFlinger → HWC → 屏幕Unreal也差不多，但它对Vulkan的支持更激进一些。我个人习惯在Unreal项目里优先用Vulkan，因为它的多线程渲染优势在Android上特别明显。
这里有个关键点：Unity和Unreal都会创建自己的EGL context，而且通常是多个。比如Unity的主线程一个context，渲染线程又一个context。这就涉及到context共享的问题了。
核心要点：游戏引擎的图形管线适配，本质上是把引擎的渲染输出与Android的显示系统对接起来。这个对接点就是ANativeWindow和EGL context。
NativeWindow交互
NativeWindow是Android原生窗口的C层接口。Unity和Unreal通过它来获取窗口的宽高、格式、变换矩阵等信息。
我给大家看一段Unity底层实际使用的代码片段（简化版）：
// Unity引擎中NativeWindow交互的核心逻辑
ANativeWindow* window = ANativeWindow_fromSurface(env, surface);
ANativeWindow_setBuffersGeometry(window, width, height, WINDOW_FORMAT_RGBA_8888);
// 获取窗口属性
int32_t width = ANativeWindow_getWidth(window);
int32_t height = ANativeWindow_getHeight(window);
int32_t format = ANativeWindow_getFormat(window);
// 提交帧缓冲区
ANativeWindow_Buffer buffer;
ANativeWindow_lock(window, &buffer, NULL);
// ... 渲染内容到buffer ...
ANativeWindow_unlockAndPost(window);
这里有个坑，我曾经遇到过：ANativeWindow的宽高不一定等于屏幕分辨率。为什么？因为系统可能会根据设备的density和orientation做调整。Unity和Unreal在初始化时如果拿到的宽高不对，渲染出来的画面就会拉伸或者裁剪。
避坑指南：我曾经在一个折叠屏项目上，因为没监听onNativeWindowResized回调，导致展开屏幕后画面撕裂。解决方案是在引擎层注册一个窗口变化监听器，每次窗口大小变化时重新设置buffers geometry。
EGL context管理
EGL context管理是游戏引擎集成里最容易被忽视但又最关键的部分。说白了，EGL context就是OpenGL ES的“工作环境”，它决定了渲染命令在哪个线程、哪个窗口上执行。
Unity和Unreal的EGL context管理策略：
| 引擎 | Context数量 | 共享策略 | 典型问题 |
|---|---|---|---|
| Unity | 2-3个（主线程、渲染线程、加载线程） | 共享资源（纹理、缓冲区） | 多线程同步、资源竞争 |
| Unreal | 3-5个（游戏线程、渲染线程、RHI线程、加载线程） | 共享上下文（share context） | Context切换开销、内存泄漏 |
我给大家画一张图，看看EGL context在游戏引擎里是怎么流转的：
看到这张图了吗？Unity和Unreal虽然线程模型不同，但核心逻辑是一样的：多个EGL context之间通过共享资源来协作。这个共享机制，说白了就是让不同线程的context能访问同一块纹理或者缓冲区。
EGL context创建与销毁的最佳实践
我给大家总结一下EGL context管理的几个关键点：
- 创建时机：最好在引擎初始化阶段就创建好所有context，不要运行时动态创建。我见过一个项目在加载场景时临时创建context，结果导致卡顿了几百毫秒。
- 共享模式：使用eglCreateContext时，第二个参数传共享context。这样纹理、缓冲区就能跨线程访问。
- 线程绑定：每个线程只能有一个当前context。切换context时要用eglMakeCurrent，但这个操作开销不小，尽量减少切换次数。
- 销毁顺序：先销毁依赖的context，再销毁被依赖的。我曾经因为销毁顺序搞反了，导致一个纹理被释放后还在被引用，直接crash。
警告：千万不要在渲染线程正在渲染时，从主线程销毁EGL context。这会导致渲染线程访问到野指针。正确的做法是先让渲染线程停止渲染，再统一销毁。
实际项目中的坑与解法
我记得有一次，一个Unreal项目在华为手机上出现严重的掉帧。我排查后发现，问题出在EGL context的切换上。Unreal的RHI线程和渲染线程频繁切换context，每次切换都要几百微秒，累积起来就卡了。
解法是什么？我建议他们使用双缓冲context策略：
// 双缓冲context策略示例
// Context A：用于渲染线程
// Context B：用于RHI线程
// 两个context共享资源，但各自独立执行
// 初始化时
EGLContext contextA = eglCreateContext(display, config, EGL_NO_CONTEXT, attribs);
EGLContext contextB = eglCreateContext(display, config, contextA, attribs); // 共享contextA
// 渲染循环中
// 渲染线程使用contextA
eglMakeCurrent(display, surface, surface, contextA);
// ... 渲染命令 ...
// RHI线程使用contextB
eglMakeCurrent(display, surface, surface, contextB);
// ... RHI命令 ...
这样两个线程就不用频繁切换context了，性能提升很明显。
总结一下
游戏引擎集成这块，说白了就是三件事：
- 图形管线适配：让引擎的渲染输出能正确到达SurfaceFlinger
- NativeWindow交互：处理好窗口的创建、大小变化、缓冲区提交
- EGL context管理：多线程环境下的context创建、共享、销毁
嗯，这些内容看起来简单，但实际做起来细节特别多。我建议大家在实际项目中，先把EGL context的创建和销毁流程画清楚，再动手写代码。这样能避免很多后期的问题。
个人建议：如果你在集成Unity或Unreal时遇到黑屏、花屏、掉帧问题，先检查EGL context的共享模式对不对，再检查NativeWindow的宽高是否匹配。这两个地方解决了，80%的问题都能搞定。
公众号:蓝海资料掘金营，微信deep3321