鸿蒙 Harmony 的跨端技术方案

这两年要说技术上最火的关键字，我想肯定离不开“鸿蒙”两个字。

不管是技术社区还是身边的开发者多多少少都在关注鸿蒙的发展趋势，特别是 HarmonyOS NEXT 版本将进入独立生态体系，不再兼容安卓应用，在开发者和各个企业间激起了不小的话题。

HarmonyOS NEXT 系统底座作为华为完全自研的，是一个与 iOS、安卓将完全独立的多终端智能操作系统。摒弃了传统的 Linux 内核和 AOSP 等代码，仅支持鸿蒙内核和鸿蒙系统的应用。

最底层的原因还是华为设备的持续增长突破 7 亿大关以及官方政策的导向，企业已有的 App 需要及时构建一套基于鸿蒙原生 App 的服务，以保障鸿蒙用户的业务连续性。

但是对于企业或开发者来讲，成本确实巨大的。

终端系统的数量和种类不断增长，开发者面临着多平台开发的挑战。以往开发者一般只需要维护 iOS、Android、MacOS、Windows 几个主流核心终端操作系统即可，但是随着信创化的趋势，统信、麒麟、鸿蒙等操作系统也开始崛起，后续可能还会涌现 HyperOS、BlueOS 等等操作系统，如果这么多的操作系统终端，每个终端都用不同的语言维护，研发成本将是巨大的。

根据鸿蒙提供的信息，第一批兼容支持的跨平台框架会是 React Native、Flutter、Weex 等等，「目的也是为了提供开发生态中的历史资产复用，降低开发者的兼容门槛」，但是例如 React Native ，针对 Harmony 平台，software mansion 社区版本会新增一个 OpenHarmony Renderer 去将前端标签转化为 ArkUI 里的控件进行渲染，而在需要通过 JSI 沟通的 Plugin Module 场景，在 OpenHarmony 上会通过原生的 NAPI 去适配，可以看出来这是一个妥妥的苦力活，而适配 Openharmony 的 Flutter 版本现在由社区开发维护，这个版本的第三方 packages 也在逐渐迁移适配，这样的话可能会同时存在两个版本的 Flutter，而这两个版本间的插件生态的兼容性会比较麻烦。

那有没有更优的跨端技术选型呢？

FinClip 是一个行业领先的小程序容器技术，FinClip SDK 已全面适配鸿蒙 OS 原生开发（HarmonyOS NEXT），通过 FinClip 技术，任何企业或者开发者都可以将现有小程序场景直接上架至鸿蒙 App 中，实现场景快速迁移，同时，还能通过 FinClip Studio 将现存小程序反向生成鸿蒙 App。

而且 FinClip 完全拥抱微信生态，兼容微信语法， 也就是说企业或者开发者可以将已有微信小程序代码在 FinClip 中进行项目导入，从而导出为 Harmony OS 中可用的工程文件,并上架至鸿蒙应用市场。由于导出的工程文件自动集成了 FinClip SDK ，所以直接拥有小程序的运行能力，后续可在所导出的 App 上继续上架更多小程序，丰富 App 上的使用场景。

FinClip 为鸿蒙提供小程序运行能力，出于以下原因：

以 Web 类型技术实现应用，而不是以传统原生手段（例如在 iOS 上基于 Swift/ObjC、在 Android 上基于 Kotlin/Java），更符合市场刚需。鸿蒙在操作系统层面对 Web 技术的支持是原生的（例如开发语言采用 TypeScript，一种 JavaScript 的超集），用小程序替代原生 App 高度可行。

小程序天然跨端，对于各个平台都是由各平台原生语言开发，将各平台的差异抹平到同一水平线，然后由 webview 来承担页面的渲染，将各平台的差异降到最低。然后再在基础库这一层面做一些兼容逻辑，最后在上层的小程序开发者基本就感知不到平台的差异，可以专注于开发业务逻辑。

小程序作为应用程序，也将极大程度丰富鸿蒙的数字生态，也将帮助鸿蒙社区无缝对接海量的小程序技术开发工程师。

企业几乎都有自己的小程序内容，将可以无缝迁移到鸿蒙上，而无需再采用另一种技术去重新实现。企业在过去的多年里，自行在自己的融合型 App 中打造的融合 HTML5 碎片的“热更新”技术，其底层迁移至鸿蒙，依然需要重新开发与调试。在一个持续优化更新、本身还在快速发展的操作系统如鸿蒙上，此工作并不简单，开发人员需要重新培训，知识体系与 Android 并不一样。

现在留给我们的时间不多了，如果企业有鸿蒙 App 改造的需求，是不是可以将 App 鸿蒙化的改造排个优先级？先把关键的、需要适配的核心功能，自研团队集中精力适配了，其他核心业务场景通过小程序化改造，或者让第三方开发商提供小程序版本，以极低的门槛植入到自有 App 中，先保证关键业务能在鸿蒙 NEXT 中运行，后续再慢慢改造边缘场景呢？