UUG杭州站 | 团结引擎1.5.0 OpenHarmony新Feature介绍

PPT下载地址：https://u3d.sharepoint.cn/:b:/s/UnityChinaResources/EaZmiWfAAdFFmuyd6c-7_3ABhvZoaM69g4Uo2RrSzT3tZQ?e=2h7RaL

在2025年4月12日的Unity User Group杭州站中，Unity中国OpenHarmony技术负责人刘伟贤带来演讲《团结引擎1.5.0 OpenHarmony新Feature介绍》。

今天带来关于我们在OpenHarmony平台上的一些更新，我会着重介绍团结引擎从1.4.X到1.5.0，在OpenHarmony上做了哪些东西。

OpenHarmony平台基本介绍

首先用一张图简单地表达OpenHarmony、HarmonyOS以及HarmonyOS NEXT的关系。

其实从很早期开始，OpenHarmonyOS就已经是基于OpenHarmony系统内核打造的，当然它本身还与一部分AOSP（安卓）捆绑在一起，这是以前的鸿蒙系统。

OpenHarmony是鸿蒙系统的底座和内核，在新的HarmonyOS NEXT版本里把安卓部分剔除了。我们从2023年就已经开始在适配OpenHarmony系统，到今天为止已经经过了一年多的开发。我们基本上把系统的能力已经全面适配，而且也一直持续地跟进OpenHarmony SDK的适配。

同时，我们在无缝迁移方面做了很多努力，希望能够让很多原有项目快速触达到这个新平台。

我们在OpenHarmony平台上支持直接读取安卓平台的AssetBundle，同时在切换平台时，我们的OpenHarmony平台会无缝将贴图压缩格式读取过来。所以大家如果已经有针对安卓和iOS的成熟项目，现在要切到OpenHarmony的话，只要打开团结引擎这个项目，再切换一下平台去构建，就能直接迁移到这个平台上了。而且，我们还提供了特有的Package的支持。

目前，我们已经有30多款多个品类的游戏移植到了开源鸿蒙平台。不管是MMO、RPG，还是三国杀、捕鱼、跑酷这类轻量级、中重度，或大型游戏，都能够通过团结引擎无缝迁移到开源鸿蒙平台。

因为这一平台的发展速度实在太快了，它的SDK更新迭代也非常快，所以开发者通常都会问我，到底选用哪个团结引擎的版本，或者选用哪个SDK的版本，能够更好地适配这个平台？

我简单地通过这一张图展示了我们整个SDK的对应关系。

从1.0.0开始，我们每一个大版本都在更新SDK。1.5.0版本支持最新的SDK 5.0.2，也就是API 14版本。如果你准备进入或者马上要有项目进入这个平台，推荐大家都选用我们最新的版本，因为这适配了最新的SDK。

从1.4.X到1.5.0

在SDK 5.0之前的版本，可以像安卓一样直接点build得到一个API，并且装在任意一台手机上。但在最新的SDK中，在没有任何证书的情况下，没有办法直接把它build and run到这个设备上。

这就意味着在OpenHarmony平台上，整体发展趋势会越来越趋向于iOS，系统的开放程度可能会与苹果更相近。在这次SDK版本中，大家如果想要把构建后的应用装到手机上，必须要先申请证书，在Editor里我们也提供了这样的配置项，与安卓基本上是一样的keystore的配置界面，大家把从网站上申请的证书配置到这个界面里，就可以直接一键build出安装包，然后装到你的设备上。

在新SDK版本中还有很多变更，一个最重要的变更是它会要求更多地使用ETS。

之前在OpenHarmony上主要的胶水代码语言与安卓不一样，安卓是Java，但在OpenHarmony上是TypeScript（TS）。TS是一种动态语言，它为了提升性能和安全性推出了ETS，ETS做的是把一些动态语言的特性进行了改进，例如把它改成强类型，把很多动态语言本来很灵活的特性固化，通过编译器的优化达到更好的性能。

所以在新的SDK版本里，OpenHarmony会要求胶水层的代码尽可能全部用ETS。上图左边是之前老的适配平台的胶水代码，都是“.ts”后缀，但新的版本里已经从“.ts”后缀全部切换成“.ets”后缀，更加安全，运行效率更加高。

另外还有一点是，OpenHarmony SDK 5.0.2的SDK本身可能有一些问题，导致现在无法直接Build And Run。这个问题我们也已经反馈给厂商，他们会在后续版本快速修复。同时，大家可以在这个新版本里使用Commnadline Tools里的SDK来避免这个问题。

这都是SDK5.0.2之后变更的影响，接下来我们介绍团结引擎在这些部分的主要更新。

第一，贴图压缩格式继承。在老项目迁移时有很多问题，例如从安卓平台切换到OpenHarmony平台，原来在安卓平台里所有的setting到OpenHarmony里都变成了default setting。

这不利于我们将一个老的安卓应用快速迁移到新平台，所以我们做了改进，在导入这些老项目的时候，当你切换OpenHarmony平台，它会自动把安卓平台这些texture settings全部写到OpenHarmony平台上。

其次，在这个版本里我们还做了很多系统接口的调用优化。因为在OpenHarmony早期版本里，很多系统接口并没有在Native层开放，更多在TS层。跨语言调用一直以来都是一个性能开销的大头，在后面的这些版本里，OpenHarmony的SDK开放了更多Native接口，所以我们的引擎可以直接在C++层直接调用到它的Native接口。

这里列举了其中的一些例子，例如DisplayInfo、Sensor、DeviceInfo等，频繁地获取一些与设备、系统交互的接口，然后从TS接口转到原生接口，能够大大地提升整体的调用效率。

最后，我们为了方便大家在打包项目的时候进行配置或者自定义，我们在这个版本中推出自定义支持Ability文件，这个ability就相当于安卓层面的activity。

以前如果你要去改一个UnityPlayerActivity，可能只能export project到安卓studio里改。但现在如果你已经有一个自己写好的UnityPlayerActivity或者团结PlayerActivity，可以直接通过我们的Editor工具进行替换。

我们也支持了Module.json5，Module.json5也是OpenHarmony的一个配置文件，类似于安卓的Manifest，但是它没有配置文件与配置文件中的合并功能，我们在Editor里把这部分功能进行了完善。大家可以通过我们的Editor方便地自定义这些平台相关模板。

最后，我们在这个版本里也做了一个原来没有的功能，就是支持命令行的传参。

在这个版本里，我们可以通过hdc的命令，去hdc shell，然后aa start。这个命令行与安卓有点像，但hdc就像安卓的adb，命令其实都一样。如果通过他们的DevEco Studio，即IDE工具，大家可以通过配置面板将这个启动的命令行参数配置进去。

另外，在这个版本里，我们还针对VSync做了优化。

在早期的系统版里，VSync的支持比较弱，而引擎帧与帧之间的计算基本上还是依赖引擎，根据系统获取的时间进行帧之间的时间运算。在新系统版本里，他们开放了更多VSync接口回调，我们把这一部分系统能力对接到了引擎里。所以我们能够非常好地对齐系统的VSync信号。

这样游戏在OpenHarmony平台上帧率会更加平滑。从这张图可以看到，30帧的时候，基本上每隔一个VSync就可以对应一个引擎的上频。

此外，在之前的版本里，我们的游戏最多支持60帧，但是在1.5.0的版本上已经支持高刷了。

我们在新的版本里，可以支持高达90FPS或120FPS。开启自定义绘制帧率很简单，只要关闭垂直同步，设置targetFrameRate为90或者120，就能达到高刷帧率。如果targetFrameRate<0的话，它将使用跟安卓一样的设置，默认是30FPS。

除此以外，我们在OpenHarmony平台上对new input system进行了更加完善的支持，补全了之前部分缺失逻辑，特别在平板或者其他设备的输入上。

最后，我们还有一个非常重要的更新，在OpenHarmony平台上支持像安卓一样的UAAL的模式，也就是Used As A Library。

这对于所有的应用开发者都是非常重要的功能，意味着我们可以很容易把一个3D引擎通过模块化放到一些原生的应用上。

在OpenHarmony底下左边有一个开发的tad视图，右边是一个编译后的包视图。我们在早期适配时，更多是直接粗暴地把我们所有代码塞到一个Entry Module里，它基本上和所有的应用业务或逻辑都是混淆在一起的，这不利于原生应用的直接接入。

所以在1.5.0版本里，我们把这一块单独全部拎出来做了一个新的Module，叫TuanjieLib。

可以看到左边是原有的结构，它基本上在entry module下，把所有东西都塞在里面。但现在我们除了entry module外，还有一个TuanjieLib module。有了这个Module，我们就可以直接把这一整块Module拷到其他一些原生的3D应用里面去。

而且，我们已经把所有的控件都做了封装和改进。对于所有的开发者来讲，只需要把Module拷到原生的ability project里，并且在这个配置文件里把这个依赖加上，就可以在页面index的ETS上直接把TuanjiePlayer View加上。这样你就完成了一个3D player的接入，就能够让原生应用得到一个3D的能力。

最后，我们对ETS胶水代码做了大量的重构，提供了更加便利的Module注册方式。我们也有了更加统一的C#/ETS的跨语言调用。特别是我们在做ETS时，需要关注线程间的调用能力，因为我们的引擎是跑在另一条线程上的，它本身的UI又在一条UI线程上。从UI线程到我们引擎的主线程，中间会有非常多线程间的调用能力。

我们提供了一个叫POST_MESSAGE_TO_HOST和POST_MESSAGE_TO_WORKER。POST_MESSAGE_TO_HOST就是send message to host，host就是我们的UI或者main线程，指应用本身的主线程；send message to worker，这个worker就是我们的tuanjie main的线程。

接下来再介绍一下OpenHarmony专有的两个Package。

第一个Package叫OpenHarmony SDK Kit Package，早期的SDK Kit的Package基本上只涵盖登录和游戏服务，涵盖了API和推送。在最新版本的SDK Kit Package里，我们把包括消息通知、ADS的能力都完整地放到了SDK Kit Package里。所以大家如果想到这个平台，但是TS、ETS对大家来讲有一定的学习成本，可以下载这个Package，里面有我们封装好的一系列C# API，也有一些内置的Demo Scene，可以通过这个Demo Scene快速完成这个平台SDK的接入工作。

下面我们可以通过一个视频来看一下，这是真机实录的视频。

看到的这些demo和样例，都可以通过SDK Kit Package来提供，所以把SDK Kit Package装到你的项目里，就可以把这些Demo Scene build出来，看到里面怎么样使用C#接口，完成平台的账号登录、内购、广告、推送、消息提示等等能力。

另外一个专有的Package叫OpenHarmony Hilog Package。这个Package更多是针对开发者的，能够通过Editor直连真机，在真机里面实时看log。

另外，如果出现闪退，我们可以提供一个工具帮你还原堆栈，同时还支持显示实时内存占用，还可以抓取ArkUI的Dump。这个工具可以把整个应用UI的Layout都Dump下来，然后看到里面的Layout层级到底是什么样的。

白色的都是我们最早的版本提供的能力，在新的版本里面，我们提供了Native Performance Tools的支持。我们把一系列这个平台特有的真机profiling工具都集成在Editor里，可以拿到真实CPU的用量、电池的用量、GPU的用量等数据。

下面我们通过两个视频，来看一下OpenHarmony Hilog Package能做的事情。

第一个是直接连接真机，查看log，还支持筛选Bug level，支持自定义查询。这里还有Stacktrace Utility，可以快速把一个闪退的堆栈进行还原，最后还有一个实时内存占用的工具，查看这一部分的内存状况，而这些都是基于真机获取的一些信息。

最后，这里面是dump出来的ArkUI的一个Dump，可以看到整个layout到底是怎么样的。

下面一个视频，展示了Hilog Package里面关于Native Performance的一些功能，它也需要连接真机，可以拿到Device name、电量、温度、网络等信息。同时还新增了一个Performance界面，可以将GPU Usage、GPU Frequency这些信息都抓取到，这意味着大家不用使用原生工具，就可以获得同样的体验，而这些东西都在这个Package里可以使用。包括一些特定时刻的详细数据，都能够很详细地展开。大家只需要在Package Manager里面搜索Hilog，即可下载体验。