波克城市：基于团结引擎的 OpenHarmony 应用发布实践|unity|分支|安卓|波克城市|虚幻引擎

本次演讲将分享基于团结引擎在 OpenHarmony（OH）平台上的实战开发经验。内容首先聚焦于技术适配与优化，包括如何将 xLua 框架成功适配到 OH 环境、解决 Native 开发中 Worker 线程的内存隔离问题，以及应对手机、平板、折叠屏等多分辨率设备的 UI 适配方案。其次，将介绍结合 Unity 与团结引擎的混合项目管理策略，涵盖高效的多平台多版本分支管理方法和自动化的混合发布管线搭建。最后，将深入探讨团结引擎的性能优化实践，例如异步 Shader 预热技术等关键细节，旨在帮助开发者更高效、稳健地在该生态下进行游戏与应用开发。

田升：非常感谢主办方的邀请，让我有机会在 Unite 2025 技术盛会与大家相聚。我是来自波克城市的 Unity 技术工程师，非常荣幸在这里分享我们团队在团结引擎 OH 平台上的发布经验。我专注于 Unity 技术栈超过7年时间，经历了从 Unity 引擎到团结引擎的技术演进。从 2023 年底，开始主导了公司首款基于团结引擎的 OH 平台的应用接入与发布工作。在跨平台项目管理、架构设计、性能优化方面积累了一些实战经验。今天我分享的主题是《基于团结引擎的 OH 应用发布实践》，将重点介绍我们在实际项目中遇到的挑战、解决方案以及获得的经验教训，希望能为正在或计划使用 Unity/团结引擎进行多平台开发的团队提供参考。

在开始深入技术细节前，先简要介绍今天的演讲内容：

第一部分将分享团结引擎基于 OH 平台的实战经验，重点讲解三个我们遇到的核心问题及解决方案：UI 的屏幕适配、xLua 在 OH 平台的使用，以及 Native 开发时 Worker 的内存隔离问题。

第二部分将探讨 Unity 与团结引擎的混合项目管理方案，包括多平台多版本分支管理方案和多平台自动化发布管线的建设。

第三部分将聚焦团结引擎在体验和性能方面的优化实践，特别是异步 Shader 预热技术的应用效果。

团结引擎发布 OH 的实战经验分享

技术分享前，看一组 2025 年的市场数据。首先“498万”是折叠屏设备的增长，2025 上半年中国折叠屏设备手机出货量达到 498 万部，同比增长 12.6%。第二个是设备尺寸的多元化：50% 是指 6.7 英寸以上的大屏手机在国内安卓市场仍然占据主导地位，达 50%；小于 6.5 英寸的设备，它仍然有 21.5% 的占比。第三个说明的是分辨率的碎片化，1.5K 分辨率已成为安卓阵营的主流选择，占比已经高达 37.2%。超越了 1080P 的 33.8% 和 2K 的 15.3%。这些数据表明，移动设备的形态正呈现多元化的发展趋势。从传统手机到平板再到折叠屏，屏幕比例和分辨率千差万别。同时，操作系统平台也日趋多样化，如何实现高效的多平台发布或将成为我们开发者面临的主要挑战。

UI 的屏幕适配方案

接下来我们看一下 UI 的屏幕适配方案，涵盖了手机、平板、折叠屏。

面对设备碎片化挑战，我们设计了一套安全区偏移适配法。核心思路是：不仅考虑不同分辨率的缩放，更重点关注异形屏、折叠屏等设备的安全区域动态变化。下图展示了我们的适配效果。左侧是异形屏（刘海屏）设备上的适配效果，右侧是平板设备下的适配效果。黄色区域是安全区的边界，在这两种设备上我们的关键元素都能有比较不错的适配效果。

接下来，我们看一下视频演示。

下方视频是屏幕动态比例，演示了常见的横屏及竖屏常见比例的动态适配。关键元素基本都没有出现被遮挡、被裁剪的一些情况。

下方视频是自由屏的比例，是基于左边动态屏幕比例做了一些更激进的演示，我们可以非常定制化地去改我们的屏幕分辨比例，非常灵活。刚刚是横屏，这是竖屏。当然，这里面的背景元素适配，后面我们也会扩展。

接下来是具体的适配方案设计，有三个关键问题：一是安全区域的数据怎么准确的获取？大家也可以看到下图右侧的设计图。设计上将屏幕数据抽离出来成为数据的提供层，以实际情况来采用不同的屏幕数据提供者。例如：通过 Unity 原生 API Screen.safeArea 获取、Native 层自行定制 API 等。另外，可以增加任意的自定义的扩展，来针对一些不支持获取安全区设备时能有一种 Callback 方案。

第二个问题是横竖屏动态切换如何适配？这里需要区分下普通的 UI 元素和 UI 背景，适配方式有所差异。

针对普通 UI 元素，我们用 Unity UGUI 自带的锚点适配以及 Canvas Scaler 适配就能做到比较好的效果。

针对背景 UI 元素，我们有以下三种方案：

两套标准，动态切换。什么叫两套标准？我们在设计时按照手机的分辨率以及平板的分辨率，两套分辨率分别出图。制作时我们的动态根据屏幕的宽高比切换需要使用到的图片。优点是我们的室内结果会更出色，我们在手机或者说在平板上都能有一个比较好的一个表现效果。缺点是我们美术和程序端都会多一些这工作量。

一套标准、设计兼容。这个“设计兼容”是指按照手机和平板都兼容的分辨率出图。缺点是内容可能有些紧张，优点是适配方案和开发上难度都不高。

一套标准、适配兼容+Aspect Ratio Fitter。这“一套标准”是指，例如：我们的主要用户是在手机上，我们按照手机分辨率设计图、不用考虑平板的情况。但是怎么去兼容平板呢？我们借助 Unity 的 Aspect Ratio Fitter 组件进行组件适配。优点是制作过程更快捷，缺点是我们是需要程序适配，而且通用性它会带来一些普遍缺点，我们在平板上的一个画面表现可能会比较一般。
另外，适配后的界面内部分元素，如果不需要适配要怎么处理？这里给到的是一个“安全区偏移适配法”。什么时候会出现这种情况？比如界面内部分需要适配安全区、部分不需要适配安全区。例如某些美术设计师，他们的设计是非常好的。例如全屏背景下，可能会增加一些跟屏幕有一些交互的线条或者一些边缘的效果。这个情况下，这些边缘效果是不应该去受到安全区的控制的，这个时候我们就需要让它跟基于屏幕的边缘去适配，所以我们这边采用的是安全区适配法。

大家可以在下图中看到虽然黄色线框是安全区域，但是红色和绿色表示 UI 元素并没有被约束在黄色线框内。怎么做到？我们拿到准确的安全区数据之后，安全区距离屏幕每条边的距离是可以计算出来的。这些距离数据，即为安全区域和原屏幕尺寸的偏移值。只要设计一个智能化的偏移组件，我们就可以对此偏移尽量做一个反向的距离或者尺寸的应用。如果是对位移进行偏移，大家可以看到绿色的 UI 元素效果，只会修改位移；如果是对尺寸进行偏移，我们可以得到红色表示的 UI 效果，会基于原尺寸做一个拉伸的效果。这种方法保证了关键 UI 元素既不会超出安全区，又能充分地利用屏幕空间。

xLua 在 OH 平台的适配方案

我们一个已上线项目采用 AOT 部分是 C#、资源热更部分是 xLua 的技术栈。在面向 OH 平台发布时，遇到了 xLua 框架代码异常的问题。问题的根源是什么？因为 xLua 虽然是一个相当成熟的热更新框架，但是团结引擎、OH 平台发布时间都较 xLua 晚，所以 xLua 的 Assets/Plugins 目录下不存在 OH 平台的 so 库。那怎么解决呢？其实 xLua 设计之初就考虑到了此问题，官方文档内其实能找得到 Plugins 的源码。只要有了源码，那么接下来就很简单了。使用 cmake 编译源码到 OH 平台即可，最终我们需要生成的是一个如下图所示的 libxlua 的一个 so 库，集成到项目中，就可以提供给 OH 平台正常使用。这个过程虽然简单，但几乎是所有采用类似技术栈的项目在发布到 OH 平台时都会遇到的“必经之路”。

OH Native 开发时 Worker 的内存隔离解决方案

在 OH 平台打包发布的最后阶段，我们发现由 C# 调用 Native 函数后，Native 侧运行时的数据异常，表现为一些值未初始化或返回的值是默认值。跟第二个问题一样，几乎我见过所有的团队在发布 OH 期间都有碰到过，问题就是 OH Native 开发时 Worker 存在内存隔离。

发布 OH，我们必须知晓一个概念，Worker。Worker 可以理解为一个多线程的运行环境，Worker 的子线程和宿主线程拥有相同的实例，包含基础设施、对象、代码段。Worker 子线程和主线程之间的通信，主要是基于消息传递的。当我们知晓了这个概念之后，我们相信这个内存隔离问题也比较好去解决了。

我们 Native 开发时，中台部门开发了一个通用的 SDK 其实是在主线程内使用的，例如：登录、支付等功能界面，而 Tuanjie 调用的 Native 代码在其实是在子线程，所以会产生 OH 的 Worker 内存隔离问题。

问题原因明确过后呢，这里提供一个简单的方案来处理：首先，针对行为（例如：唤起登录、支付等无需实时同步的状态数据返回的情况），直接调用线程的异步通信即可；其次，针对数据，提前在与引擎交互的 Worker 子线程中提前缓存数据。像我们一般会去调 Native 获取的数据，主要就是一些设备信息，这些信息我们提前缓存的话，我们在后续的调用中就可以做到同步的实时性。这样在实际需要用到数据的时候，即可以达到同步返回的及时性；当然，我们需要统一入口点，确保所有 Native 调用都通过同一 Worker 线程处理。

以上是第一部分的内容。接下来，分享第二部分。

Unity + 团结的混合项目管理方案

项目管理严格来说涉及的领域和模块都比较泛，例如版本管理、开发管理、发行管理、运营管理等等。今天没办法从头到尾跟大家理清楚这里面的全部门道，我们挑了几个跟技术相关的命题，涉及的主要是“开发管理”。以下是多平台多版本的分支管理和多平台的自动化发布管线。

多平台多版本的分支管理

有一句话说在前面：分支管理方案，没有最好的、只有最适合的。我相信如果有这部分分支管理经验的老师，应该也深有感悟。我们的分支管理都是经过多次迭代之后，才有了当前的高效方案。废话不多说，同上一部分类似，我也通过实际问题的解法向大家分享一下。在此之前，我们先备注一下使用工具。我们这里是基于 SVN 的 Unity 分支管理。当然也有其他优秀的分支管理（例如 Git），这里我们暂不展开。

我们先看看常规的分支管理方案，存在主干、版本分支、发布分支、修复分支等。常规开发时可能会先创建对应的版本分支，开发完后会立即合并到主干，同时创建发布分支用于发布。当线上出现 Bug 的时候可能会创建修复分支去修复 Bug，再合回发布分支发布。正常对于非游戏客户端来说是一个比较标准的管理方案，但是对于例如 Unity 的游戏开发、特别是涉及到资源量级特别大、版本多且复杂的一些项目的时候，过多的分支对于开发并不是很友好。

首先，美术同学对于 SVN 熟练度是存在差异的。过去有一段时间我经常帮美术同学处理各种更新冲突，分支 checkout 不下来等问题。

其次，美术开发模式和程序开发模式是有区别的。这里要说个前提，这个是我们的一些实际经验，不代表所有人都会碰到这个问题。什么区别呢？就是程序正常是按照版本排序去制作的，但是美术在此基础上会再去按照功能模块进行排期。我们有看到美术内部管理时可能会有内部的功能排期表，列了每个人员按照时间线、按照功能模块，一一排得比较明确。当然，不同项目组可能是不一样的。

最后，就是我们可能在美术人力富余的情况下存在一些美术先行的制作方式。这个情况可能也不是特别全面适用，因为举个例子，比如版本制作排期正常假如说不会超过3个月，但是我们项目设计路线可能考虑得比较完善，考虑到未来半年、甚至未来一年内的规划。那么美术，特别是针对一些美术开发工作量比较大的内容，我们可能就要去提前规划、去设计好。

第二是用该分支管理方案，其实并没有考虑到多 trunk 的形式。什么情况下会用到？假如线上同时存在运营多个版本的情况下，而且我们每个版本之间是不兼容的。但是不兼容的版本之间，它仍然需要有不同的开发路线。例如我们 1.0 的 APP，我们要开发 2.0 的资源。2.0 的 APP，也要开发 2.0 的资源，甚至也要同时开发 3.0 的资源。针对这种情况，这个分支是不太适合的。

第三是部分团队对代码的保密要求比较高。如果是分支对美术开放，那代码权管控上可能会不太方便。

接下来，针对美术开发的差异及代码保密的要求，我们迭代了第二个分支管理方案，即双分支管理方案。

当前这里前提说的是一个弯路，是基于我们经验的一个判断。我们将工程拆为程序工程和美术工程，两边各自维护。中间通过 SVN 外链的形式，将美术对应版本的资源外链接到程序工程内，然后程序工程使用程序工程发布。听到这里大家也能够想像出该方案的优缺点。优点是我们可以解决美术研发模式差异的问题。因为美术分支变成了美术资源库的概念，美术超前研发的内容也完全内聚在美术分支，并不会影响到程序内的内容。其次也可以解决美术访问权限问题。因为美术单独分支，程序可以通过代码加密或者其他方式提供美术使用。缺点是什么呢？就是复杂，分支管理极度复杂。我们每次创建分支发布时，需要操作两边的分支同时进行，而且需要专人或者说比较熟练的人员来处理分支合并。如果外链异常，可能会导致资源体提交到错误的分支上。外链如果中断了，可能会导致一些版本存档的丢失。特别是后面我们增加了 OH 平台的支持之后，这些问题更加尖锐了。

痛定思痛，我们重新整理了思路，坚持了以解决开发效率为核心的目标。如果说不影响开发效率的开发问题，那么我们可以想其他办法解决或者说根本就无需解决。

最终的管理方案，大家可以看到我们精简了分支种类，只存在trunk、master、branch 和 OH branch。Trunk 和 OH branch 可以暂时忽略，我们主要的两条线路就是版本主干和版本分支。

正常来说线上兼容版本不会有特别多的情况，正常 master 一根线就可以了。特点是什么呢？就是我们的分支数量减少，管理复杂度大大降低了。还有就是我们美术和程序研发模式的差异问题怎么去解决？我觉得我们还是要去正确的对待这个差异。美术最终其实也是要去为版本发布服务的。明确了这一核心目的之后，美术就正常按照程序的版本分支走就可以了。

针对美术超前研发内容，我们开发了一个“超前研发分支”即可。美术权限访问问题，其实我们也相当于跟自己和解了。做代码全控的目的是什么？目的是安全。这个部分的风险，我们采用职责转移的方式来作为一个方案，交由部门内强大的 IT 权控、法务等部门做风险控制。当然，中间我们也可以做到一些代码加密，来提前做一些防护。

最后为了匹配这个方案，其实我们实际也会增加开发环境内的一些对应的版本分支选择。例如客户端 1.0 就连接 1.0 的服务器，使用 1.0 的资源。接下来，后面大家看到灰色的线，其实我们增加了 OH 平台的发布路线之后，就是新增了这样一条线路。

但是问题是什么呢？是因为团结引擎的 Meta 文件的 GUID 管理方式跟 Unity 有所差异，导致我们没有办法将团结引擎的工程纳入到正常的版本研发模式内。

这里我们提供两个管理方案：一是目前的解决方案，就是类似图里所示，每次版本发布上线前也创建对应的 OH 发布分支，这是因为我们有一点历史包袱在，我们是一个已经上线多年的项目，没有办法完全迁移进团结引擎。

这里就引入到了第二个管理方案，就是我们可以将整个开发引擎全部换为团结引擎。这点其实也可以考虑，经过几年的时间，目前团结引擎还算是比较稳定，作为 Android、iOS 等平台的发布工程也可以。我们综合评估下来也可以，但是我们现在也仍然在一个测试过程中。

还有一个细节要跟大家分享，就是Excel 配置表，如何进行多版本管理？

常规情况下，Excel 的版本管理就应该跟普通的资源文件一样的，不同的工程存在不同的配置表。但是会存在一个问题，当我们碰到 Excel 合并冲突的时候怎么办？可能有人都能碰到过，每一个单元格的合并简直是痛苦，简直是灾难，特别是单元格还存在公式的情况下，你就需要一个非常强大的 Excel 合并工具。但是经过我们的尝试，该解法非常复杂。我们使用过一些常用的工具，例如：Beyond Compare、xlCompare 等工具，但实际的开发体验和带来的效果都不是很理想。

最后我们换了一个角度来解决这个问题。我们将冲突合并的痛点转移到了导出工具之上，这个难度就比较低了。我们开发导出工具的难度，大大是低于开发 Excel 合并工具的难度的。

可以看到下图中右侧的表格。Excel 表的每一列可以单独新建一列，然后增加对应的版本标记。最后，我们在下面的“导出工具”内设置好对应的版本号，我们就可以导出对应版本的行列。这样的话，我们在源头上就去规避了 Excel 合并冲突的问题。

分享以上经历并不是说推荐使用我们采用的方式，还是那句话，版本分支管理方案只有最适合的。我们核心目的是分享解决问题的思路，对复杂的内容往往需要化繁为简：首先需要明确问题是什么，以及目标是什么。只有明确了目标，我们才能找到解决问题的关键路径。还有就是我们要去从多维度看待问题，例如 Excel 这个合并工具。有些问题换个角度看，其实可能根本就不算问题，可能就迎刃而解了。

多平台的自动化发布管线

这个往往是比较繁琐，且到后期可能是趋于一些重复的事情。从提效角度上思考，我们不得不把自动化发布管线落实。自动化发布是提升团队效率的关键。我们的发布管线主要包含资源发布管线和应用发布管线。
资源发布管线包含一些核心环节：资源预测处理、自动化测试、自动化分发。从下图右侧可以看到，点击 Jenkins 打包按钮就可以开始自动化操作。我们可能先更新代码资源、解决冲突，最后做一些代码预处理、资源预处理。最后，等到构建完成，通知到对应的执行人。接下来会触发 QA 的自动化测试任务，减少人工测试。最后点击“发布”，就可以执行自动化的发布操作，最后再去提交“运维工单”就可以了。这是我们的资源发布管线。