团结引擎OpenHarmony技术生态，全面解析奉上

Unity 中国已经与开放原子开源基金会达成了平台级战略合作，团结引擎已全面支持 OpenHarmony 操作系统。本月，在 Unity 技术讲堂直播中，Unity 中国高级技术经理刘伟贤和 Unity 中国技术经理李文杰进行了线上分享，帮助开发者快速开发 OpenHarmony 应用程序。

以下为分享汇总。

大家好，今天和大家分享一下我们在 OpenHarmony 的适配情况。

可能大家不是很清楚 OpenHarmony 和 HarmonyOS 的区别。OpenHarmony 是一个开源项目，由开放原子开源基金会进行管理。开放原子开源基金会由华为、阿里、腾讯、百度、浪潮、招商银行、360 等十家互联网企业共同发起组建。

OpenHarmony 是鸿蒙操作系统的底座，而团结引擎是专门为国内开发者所开发的引擎，我们已经全面适配 OpenHarmony 的各项能力。当然除了 OpenHarmony 这个系统以外，未来我们也会适配更多的国产操作系统及硬件。

下图是我们适配 OpenHarmony 的时间轴。其实从今年 2 月份才开始做准备和评估，3 月份正式开始适配 OpenHarmony 的工作。用了很快的时间把第三方库、引擎基础的构建全部处理完，出来一个天空盒的渲染；到 7 月份的时候，基本上完成了引擎基础能力的适配，并且是基于 3.2 的 SDK；8 月份其实我们已经看到了《倩女幽魂》在 OpenHarmony 系统上的实机演示；9 月份，我们已经把引擎的全能力适配完成，并且把 SDK 升级到 4.0 的版本；11 月份，对客户开放了一些邀测；在今年 12 月底，马上只剩下半个月的时间，会把剩下收尾的工作完成。

目前主要是把所有这些数以十几万计的测试用例全部都跑通跑过，确保我们的平台稳定性。对 OpenHarmony 的适配也会将在明年 1 月 1 日跟团结引擎创世版一起正式发布。

下面是部分客户的适配成果展示。这些都是在真正的手机上面的实录，而且能够看出来，整体的性能及画面是跟原来的安卓完全一模一样的。这里面的项目有一些是从老版本升级上来的，譬如倩女，也有刚刚上线的钢岚，这一切都也足以证明团结引擎在适配原有项目上的兼容性能力。

同时，团结引擎也能快速帮大家拓展到 OpenHarmony 的平台，以及未来的 HarmonyOS Next。我手上也有一台 mate 60 pro，上面跑的是我们的 Boat Attack DEMO。

大家很关心的是怎么适配 OpenHarmony，但是适配流程对于大家来说只需要关注上面的部分就可以了。大家只需要把自己的逻辑、第三方库，这里的第三方库主要是自己用到的除了引擎外的第三方库，做一些编译。当然如果引擎有一些定制的修改，要联系我们做一些适配。除了这部分以外，你需要关注的就是 SDK 的适配，不过也不用担心，因为游戏中心的同学帮忙提供支持及 SDK。对于大家来讲，只需要大家拿到团结引擎，打开大家的项目，切换到 OpenHarmony 平台，就可以直接用了。

下面我会快速介绍 Editor 的工作流和技术细节。可以从这张图看到，我们保留了原来的工作流，多了一个 OpenHarmony 的 Build Target，兼容老版本所有的项目。同时可以支持导出 Deveco Studio 原生 Ability Project，也支持一键出包。在开发的便利性上，我们也支持连接设备 Patch And Run，包括 Build And Run 都是完整支持的。

除了这些之外，我们也会针对 OpenHarmony 提供平台专有配置。比如这里有我们针对 Player 和 Graphics 相关的设置，也有 Quality 相关的面板没有展示出来。

这张图主要是展示我们经过团结引擎导出来的原生 Ability Project。我们其实可以一键出包，也可以导出原生的工程。可以看到具体的一些引擎库，包括 TS 的代码和后面的一些资源。同时因为我们支持导出 Deveco Studio Ability Project，所以对于大家的调试都是非常非常方便的。

除了这些，大家在日常开发或者是在 Editor 工作流中经常会用到的一个工具，在安卓叫 ADB，在 OpenHarmony 叫 HDC。下图都是常用的命令，看起来和 ADB 有一些类似，但有一些也还是不大一样的。

下面介绍一下在 OpenHarmony 这个平台上，我们引擎的一些能力。从整体的架构来讲，还是沿用和安卓一样的架构。引擎线程与 UI 线程是分离的，我们在 ts 创建 worker.ThreadWorker 来驱动引擎的 Loop，通过 libuv 事件驱动，是和安卓有挺大差异的。同时，我们也保持了既支持单线程渲染，也支持多线程渲染。当然我们也支持 Job System/C# Job System。

在渲染能力上，支持内置渲染管线及 URP。图形 API 支持 OpenGLES 3.x，以及 Vulkan（适配完成，测试中）。纹理压缩格式支持与安卓一致，默认使用 ETC2，当然也可以使用 ASTC。

在文件系统上，其实 OpenHarmony 底下和安卓一样分为包内文件与包外文件。OpenHarmony 安装包为 hap，也是一个压缩包，包内文件会被压缩，hap 安装后也是压缩包形式，类似安卓安装后有 packagename/base.apk。这里面有一个部分可能会和安卓有些差异，就是它目前没有办法配置包内的部分文件，不压缩。不过我相信这个功能很快就可以跟进上。

文件读写与安卓一样，C# File 文件无法读写包内文件，都是要通过 WWW,UnityWebRequest,Assetbundle 的接口来读取。Application 底下的路径变量都已经映射到 OpenHarmony 底下的应用沙箱路径。

音视频能力，音频引擎使用 OpenSL ES，如果大家的项目有用到第三方 Wwise 插件或者原生 Fmod 插件，需拿 OpenHarmony 的 SDK 自行重新编译。

视频支持原生 ts 接口及硬解码。ts 层提供 VideoPlayer 组件直接使用原生 ts 接口播放视频，所以说可以在应用启动的时候很快进行视频播放。同时，native 层 VideoPlayer 已经通过硬解码获得视频画面用于引擎渲染。如果大家有用到常见的第三方插件，可能都需要针对这个平台做重新的编译。

脚本能力是我们下了很大功夫的模块。对于众多开发者来讲，大家最熟悉的还是 C# 语言，所以我们针对 C# 与 ts 交互做了非常多的易用性改造，这个模块是我们下功夫最多的一个模块。

在 OpenHarmony 底下，我们会把文件分成两个，一个叫 .tslib 文件，用于设置导出对象给 C# 使用。这里有一个样例 TestClass.tslib，需要写一个方法 RegisterTestClass，把需要导出给 C# 的 ts 对象注册上去，C# 就可以用到这些对象。原来的 .ts/.ets 文件作为 Plugins 的代码直接带入到原有项目。这个文件的形式有点类似于 Web GL。做的原因也是和安卓有些差异的地方，因为 ts 并没有像 JAVA 有反射的调用，所以我们必须要像 Web GL 平台一样通过导出的行为告诉引擎到底哪些 ts 的接口可以给 C# 来调用。

在 C# 侧我们还提供了很多 class，比如 C# 侧有 OpenHarmony JS Class，用于直接调用 Static Function。还提供了 OpenHarmonyJSObject，用于 ts 导出对象的表达。

接下来是一个简单的样例，比如我在 ts 内部里面导出了 StaticClassTest，在 C# 里面就可以 new 一个对应的 Class，并且可以去 Call Static Function。JSObject 其实也是类似的。

C# 侧在导出完之后，可以直接调用 ts 的系统接口，同时我们在 C# 也提供了 OpenHarmony JS Callback，用于支持异步接口回调。这一套接口下来，相信能方便大家在 SDK 的部分或和 ts 代码打交道的时候，有更方便的形式。

这里面是一个 Sensor 的调用，比如导出了一个 Sensor 对象，去 Call Sensor.on，这都是 ts 层提供的系统 API，可以有回调回来，获取里面的 Sensor 丢回来的数据。

除了比较常见的 API，在数据类型方面我们也做了进一步的适配。对于 ts 里面特有的 ArrayBuffer，我们在 C# 侧提供 OpenHarmonyJSArrayBuffer 用于支持 ts 的 ArrayBuffer。可以很方便让大家在 C# 里面读取，通过系统接口比如 OpenFile 读取文件内容，这里面的调用都是走的 ts 的接口。

最后还会讲一下 Profiler 的能力，也是我们比较下功夫的模块。内置的 Profiler 的能力与原来一样，真机可用。另外我们还针对 OpenHarmony 平台接入了对应的 Profiler 及抓帧工具——SmartPerf。

SmartPref 中 hitrace 支持，profiler tag 也可以直接输出，在 development build 下默认生效。意味着我们打一个 development build，可以用到原生的工具来看整个引擎的情况。

还有一些权限获取的部分，我们全部都在 C# 层封装好了接口，大家都是开箱即用。

除了脚本能力之外，剩下的就是系统相关。我们已经把很多系统能力都对接上了，比如说位置服务、Sensor，陀螺仪、屏幕、Webview 支持，OpenUrl 等等。

最后讲一下团结引擎在适配 OpenHarmony 里面技术细节，更多都是和系统比较相关的。首先，OpenHarmony 底下的应用模型为 Stage 模型，而这里面我们在适配的过程当中主要打交道的就是 UIAbility，这相当于是安卓的 Activity。这中间提供了一些应用的事件回调，譬如 onWindowStageCreate，onForegraound，onBackgroud，以及 onDestroy 等等，用于告知引擎是否在前后台，是否退出。

另外是比较特有的部分 ArkUI 和 XCompnonent。ArkUI 是方舟开发框架为 OpenHarmony 应用的 UI 开发提供的完整基础设施，包括简洁的 UI 语法、丰富的 UI 功能（组件、布局、动画以及交互事件），以及实时界面预览工具等，可以支持开发者进行可视化界面开发。它的语法跟 Fultter 挺相似的。左图是一个团结的 Ability 整个 UI 的布局，会有一个 XCompnonent 也就是 TuanjiePlayer，上面还会有一层 Webview，SplashScreen 和 VideoPlayer，一层一层做 UI 的排布。

而 XCompnonent 就是可用于 EGL/OpenGLES 和媒体数据写入，并显示在 XComponent 组件。这里的 XComponent 就有点类似安卓 texture view 跟 surface view 的集合体。Xcomponent 的 type 分成了三种，surface，component，texture。这三种模式在引擎里面主要是用到 surface 的模式。

文件系统主要是应用沙箱，这个应用安装了以后，你写的文件是有一个沙箱的路径，以及一个真实的物理路径。这些信息都是在开发文档里面的，大家到时候可以详细下载下来看。

最后，在 OpenHarmony 中还有一个很重要的点 Napi，用于做跨语言调用。C API 中的 N-API 接口可以实现 ArkTS/TS/JS与C/C++ 之间的交互。N-API 提供的接口名与三方 Node.js 一致，目前支持部分接口。ArkTS/TS/JS 侧通过 import 引入 native 侧的 so 文件，如：import hello from 'libhello.so'，意为使用 libhello.so 的能力，并将名为 hello 的 ArkTS/TS/JS 对象给到应用的 ArkTS/TS/JS 侧，开发者可通过该对象，调用到在 cpp 中开发的 native 方法。

我们快速地把 OpenHarmony 系统的一些比较关键的适配需要注意的细节给大家展示了一下。我今天关于 OpenHarmony 的技术内容分享就到这里，谢谢大家。

长按关注

Unity 官方微信

第一时间了解Unity引擎动向，学习进阶开发技能

 每一个“在看”，都是我们前进的动力