鸿蒙Next的问世带动了众多APP迈向鸿蒙化适配的步伐，与此同时，产品与技术团队也着手制定了游戏电竞直播SDK的鸿蒙适配方案。虽然充足资源投入往往能实现适配目标，但仅技术层面的成果略显单薄——那么，我们该如何进一步提升价值，让鸿蒙适配的效益达到最大化呢？本文将详细阐述以Kuikly框架为基础的HarmonyOS跨平台适配策略，该方案能够确保SDK中的业务代码在三端以及多个游戏应用中达到100%的复用，相较于独立为每个平台开发，此举能够减少超过50%的人力投入，从而大幅提高开发速度。

Kuikly作为腾讯广泛采用的跨平台开发工具，具备以Kotlin语言为基础，实现Android、iOS、HarmonyOS、Web以及小程序等多平台应用开发的强大功能，同时，它也是腾讯端服务联盟中的关键一员。

适配工作现状

游戏电竞直播SDK是一款历史悠久的基础直播组件，广泛应用于CODM、QQ飞车、极品飞车、元梦之星、AOV等众多游戏APP。在这些游戏APP中，其产品形态表现出高度的一致性。为了提高跨平台、跨应用的开发效率，我们正努力实现同一份代码在多种游戏APP中的最大程度复用。

新增工作

预计新增鸿蒙Next平台后引入的工作量增量来源占比

预估适配工作导致的人力开销增幅

开发鸿蒙新版本时，适配环节需投入较多资源以匹配安卓和iOS的功能，而且后续还需持续投入人力进行鸿蒙系统的开发与更新。在这种情势下，团队必须考虑如何挑选适配策略，旨在减少适配费用，甚至提升适配的效益。

适配目标

以提高研发效率为核心目标，该团队确立了适配标准：不仅需以较低成本完成对鸿蒙系统的适配，还需确保适配工作的价值得到充分体现。

团队主要通过技术方案升级和运营手段相辅达成目标。

方案设计

游戏电竞直播SDK与Kuikly技术团队携手合作已近两年时间，在多个项目，包括CODM、QQ飞车以及极品飞车中，Android和iOS平台均已成功采用Kuikly技术，实现了业务的跨端和跨业务线开发。鸿蒙系统方面，Kuikly同样较早实现了适配，同时在浏览器、K歌等多个业务领域进行了验证和优化，因此本次鸿蒙系统的适配工作，正是以公司内部卓越的跨端框架为基石进行构建的。

对Kuikly感兴趣的可以看下这两篇文章：

腾讯推出的开源型多平台开发工具 Kuikly，有效促进了不同平台间的开发速度提升。

腾讯Kuikly框架的鸿蒙版本现已对外公布开源——让我们一同探索其卓越性能的适配历程。

补齐鸿蒙开发能力

相较于Android系统，鸿蒙操作系统的第三方文档资料较为稀缺。鉴于后续技术方案制定过程中可能出现的重大失误，我们决定抽出时间来深入学习鸿蒙的开发基础。ArkTs技术、自定义组件的创建、声明式布局的开发、多线程以及多进程的开发等基础技能，都需要我们提前进行补充和掌握。

如上图所示，这是鸿蒙系统入门所需掌握的基本知识点；只需熟悉这些基础内容。至于更高级的编程技巧，在开发过程中，你可以通过查阅官方文档，或利用元宝AI搜索，这些问题基本上都能得到解决。为了检验学习成果，我们投入大约一天时间，基于鸿蒙UI框架，构建了一个电竞直播SDK的核心框架。这一举措旨在确认学习成果是否达到预期，同时也便于在团队内部进行经验交流。通过这种方式，团队成员可以迅速掌握鸿蒙开发技能，为后续技术方案的协调工作提供便利。

方案对比

如上图中三个分支节点代表三种实现方案。

游戏电竞直播SDK在Android和iOS平台上已广泛采用Kuikly组件，该组件在稳定性、混合开发功能、性能表现以及包体大小等方面均展现出良好的实际使用效果。

经过对多种方案的比较，我们决定采纳“采用KuiklyUI来处理业务功能，而KuiklyBase来构建逻辑组件”的方案，认为它更为适宜。

整体架构设计

原生层开发是不可或缺的任务，在此过程中，我们决定对通用逻辑进行跨平台处理，采纳了KMP的开发模式。其核心宗旨在于寻求共性，保留个性差异。

我们将“大同”的模块采用Kotlin进行开发，以此实现跨平台调用功能；“小异”部分则选用专门的平台层编程语言进行编写。

页面层级设计

图中清晰可见，最底层仅存在一个相当“单薄”的鸿蒙原生界面，该界面由Entry装饰的page组件构成，而非Ability。

其他所有可见的页面都是Kuikly化。

Kuikly层业务框架设计

如上图所示，电竞直播SDK的业务层整体框架设计引人注目，特别是其页面路由设计独具匠心。它并非采用Kuikly官方的路由组件，而是独立封装的，基于KuiklyNativeView实现的页面路由。Kuikly的灵活性使得开发人员能够将任何原生View按照Kuikly协议转换成Kuikly能够布局的KuiklyView，这一转换过程被简称为KuiklyNativeView。

原生组件Kuikly化

为了确保游戏电竞直播业务实现全面跨平台兼容，我们必须将原有的业务模块整合进Kuikly平台。依托于Kuikly平台的自定义组件接口协议，我们已将一些关键组件封装并应用于Kuikly。

原生View映射为KuiklyNativeView

这表明将KuiklyPage集成至鸿蒙原生View中，业务方得以以View为最小单元运用KuiklyPage，同时遵循KuiklyPage的规范，将其封装为KuiklyNativeView，从而在KuiklyPage内部实现KuiklyPage的嵌套使用，形成类似套娃的效果。类似Android的Fragment组件的功能。这种用法是Kuikly官方未曾提供的特性，而在Android系统中，我们已成功通过Fragment实现了相似效果，并积累了丰富的经验，验证了其稳定性。在HarmonyOS上，我们则直接复制了这一能力。这一特性使得电竞直播SDK的主页面能够灵活地容纳多个不同尺寸、位置和层级的KuiklyPage，以实现需求开发，同时也为后续提到的需求特性模块化共享提供了技术保障。

原生全屏透明弹窗映射为Kuikly页面容器

电竞直播SDK大厅的业务大多需占据整个屏幕，此外，还存在一种非全屏的特殊应用场景，即在Unity游戏页面中，活动页面以非全屏的浮层形式展现，类似于广告弹窗等。鉴于在鸿蒙系统上实现透明页面需要依赖Ablity层级的组件，而这些组件对于游戏电竞直播SDK来说过于庞大，因此选择了弹窗的形式来呈现。

根据图中呈现的层级结构，采用鸿蒙系统的原生自定义全屏透明弹窗作为承载KuiklyNativeView的容器，这样Kuiky业务便能自主选择将哪些内容展示于游戏画面之中，同时还能灵活调整透明区域的尺寸与位置。

播放器组件Kuikly化

游戏电竞直播SDK的关键功能之一涉及游戏赛事的实时直播，这一过程中播放器将频繁被调用。针对Android和iOS平台上的既有项目，我们采取了融合开发策略，确保播放页面依旧利用原生的Activity/ViewController进行构建，并在其基础上集成Kuikly的插件模块。该方案存在诸多不足，比如原生与Kuikly间的交互问题，双向调用过程相当复杂，不得不编写大量连接性代码，而且桥接层的负担较重。

在本次鸿蒙系统的适配工作中，我们采取了逆向思考的方式，将所需的原生组件巧妙地融入到了Kuikly页面上。具体来说，就像图中展示的那样，我们借鉴了KuiklyNativeView的设计理念，将播放器所对应的视图直接整合进Kuikly系统，从而创建了一个名为KuiklyPlayerView的新视图。播放器的生命周期、层级、尺寸以及摆放位置均由宿主KuiklyPager负责管理。

弹幕&WebView组件Kuikly化

弹幕作为一种关键的运营手段，对于业务闭环的运营至关重要。为了便于操作，我们将其封装并映射为Kuikly组件，使其与播放器具有相同的操作方式。

需求特性模块化共享

如图中所示，这款游戏电竞直播SDK具备显著的运营优势，常常将A游戏中成效显著的运营策略推广至其他游戏之中。在此情形下，将玩法特性根据需求适配至不同游戏对应的电竞直播SDK中显得尤为关键。以下将详细介绍该特性在跨产品线配置化方面的实现途径。

传统实现方式

图A展示了……，而图B则呈现了……。

如图A所示，若ABCD四个特性代码均存储于同一Activity中，起初，首位研发者可能会努力确保各特性实现间的低耦合度。然而，随着代码被多个人修改，原本的“弱耦合”代码逐渐转变为“强耦合”，最终可能变得混乱不堪，形成一团债务的乱麻。

弱耦合实现方式

如图B所示，宿主页面呈现为一个独立的全屏KuiklyPager界面，而ABCD四个特性UI界面同样各自独立，均为KuiklyPager。得益于前文所述的KuiklyNativeView功能，KuiklyPager能够嵌套使用KuiklyPager。

KuiklyPager具备一个显著特性，那就是在两个KuiklyPager之间进行数据交换的成本相对较高。它们不能直接通过静态变量来传递信息。官方推荐的解决方案是利用启动参数进行数据共享，或者通过事件总线来交换数据和事件。此外，两个KuiklyPager之间也不能通过获取对方的引用来调用接口。这种门槛较高的数据共享机制，因其禁止对象间相互持有属性，自然而然地促成了KuikyPager之间的松散连接。因此，研发人员即便想要生成毛球代码也变得相当困难。

如上文所述，这是Kuikly官方文档中对Pager生命周期所作的介绍。鉴于每个特性都对应一个独立的KuiklyPager，因此，所需的基本要素都得到了满足，从而很少需要对其他模块的代码进行耦合。此外，其轻量级的底层架构设计还确保了额外的资源消耗可以忽略不计。

ABCD之间的耦合度较低，那么它们之间的交互是如何实现的呢？这里采用了业界较为成熟的解决方案，即采用Schema跳转技术。电竞直播SDK中的Schema路由跳转功能，在1.0版本中首次被引入并投入使用，展现了其便捷的运营和可配置化特点；而在2.0版本中，进一步强化了Schema配置管理端的建设，有效减轻了Schema数量激增后的管理维护压力。

迭代规范化

众多事务遵循二八定律，只需投入微小的努力，建立一套标准化的运营更新流程，便能轻松应对那些通常需要巨额资源投入的技术难题。众多历史遗留问题源于迭代过程中的逐渐累积，目前我们已成功实施Kuikly业务的松耦合开发标准，展望未来，我们将着手制定更多规范。

基建能力原子化开发

Kuikly框架适用于多种平台进行用户界面设计，然而，其中某些系统接口的功能实现，仍需借助原生代码的桥接层。

如上图所示，该设计遵循惯性思维，将原生层的API应用于Kuikly的业务层，并提前编写了大量if-else语句。这导致原生层变得较为臃肿，同时，绑定业务的原生API也难以在其他业务特性中得到有效复用。

图示中的设计经过优化，旨在原生层面尽可能提供必需的原子接口，以此使得原生层能够更加简洁和精炼。

业务Kuikly规范化

鉴于之前所提及的各类特性，业务应尽量提升至Kuikly层级进行实现，原生部分仅需提供必要的原子接口。此外，还需结合Schema配置管理端、流水线发布规范以及需求评审流程规范等。该套流程已在游戏电竞直播SDK中稳定运行超过一年，而鸿蒙项目亦在持续采用并复制此研发流程。

初步效果

本次鸿蒙平台适配工作中，所有业务代码均以Kuikly跨端技术为支撑，强化了基础设施建设，规范了操作流程，从而确保了业务代码在三端设备以及多个应用程序间的100%共享。Kuikly框架在鸿蒙平台适配方面的全面性、高效性、动态性以及稳定性等方面的出色表现，不仅助力我们迅速完成了初版适配，而且在性能和用户体验上均达到了预期目标。

鸿蒙的适配工作不仅针对鸿蒙系统本身，还旨在提升其他项目在稳定性和效率方面的表现。

鸿蒙端CODM电台大厅

Android端CODM电台大厅

iOS端CODM电台大厅

关于Kuikly

Kuikly现已实现开源，对于有意向或需求的产品，您可以通过以下途径获取详细信息或进行接入体验：

通过以下Kuikly文档和仓库，快速体验：

官方文档

Github仓库

关注和联系他们