终端系统的数量和种类不断增长，开发者面临着多平台开发的挑战。以往开发者一般只需要维护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中运行，后续再慢慢改造边缘场景呢？