纯血鸿蒙来了！鸿蒙 App 开发需如何提速

国家与国家之间错综复杂，在谷歌的安卓操作系统“断供”后，鸿蒙系统的市场化 &独立化的道路便显而易见了。

2024 年 1 月 18 日，华为宣布，不再兼容安卓的“纯血鸿蒙”--HarmonyOS NEXT 鸿蒙星河版最终面世，并与 2024 年 Q4 正式上商用版本。

华为鸿蒙操作系统独立，这次是真的了。

鸿蒙 App 该如何开发？

正常的学习路径：开发者从 0 开始学习新的技术语言（ArkTS 语言）

• 优势：能在有限的时间内，学到一门能长期坚持的“手艺活”

• 劣势：如果时间只有今年为数不多的几个月，那企业就需要面对“时间紧、任务重、资源少、基数大”等四座大山的巨大压力，鸿蒙 App 面对从 0-1 的开发，可能会导致最终成品上线赶不上鸿蒙系统商业化的节奏。

捷径的学习路径：使用混合 App 的开发技术，将大部分已有小程序或者 H5 的业务与原生 App 及必要 SDK 组件分离，即“二八原则”，20%的鸿蒙原生开发，80%的 H5 或者小程序业务场景开发（一端开发，多端上架）。

一些市场数据：据 2023 年 Q4 中国手机市场数据来看，华为手机激活量为 1146.57，以市场份额 15.3%排名第三位。这意味着，在销售的新机当中，搭载鸿蒙系统的占比至少有 15%。如果华为的“纯血鸿蒙”操作系统正式推出，那么没有就绪的企业，很有可能会失去中国 15%（甚至更多）的移动互联网的用户市场份额，这个业务量，估计换企业的任意一个部门都是无法承担的后果。如何做技术选型，相信大家内心都会有一些初步的答案了吧？

鸿蒙 App 开发新思路：小程序+适配鸿蒙操作系统的容器技术+转 App 技术

值得一提的是，一个操作系统的成败，生态建设至关重要。鸿蒙生态的早期建设是依靠元服务卡片的“众包开发”形式聚积平台的第三方应用，多年来累计 220W 的开发者加入，但原子化服务的数量仅 5W+个。今年虽然有“纯血鸿蒙”在背后支持，但短期的生态爆发仍需要时间积累。

相对应的，微信小程序生态显得更加庞大。截至 2021 年上半年，全网小程序数量突破 700 万个，其中，微信小程序是行业主流，数量超过 430 万个，占比高达约 61.43%。根据微信公开课和腾讯财报披露的数据，2022 年小程序 DAU 已经突破 6 亿，同比增长超 30%。

技术层面，小程序技术在中国的发展已经达到了一个全球示范田的作用，并受到全球互联网技术标准协会 W3C 的青睐，还起草了「小程序标准化白皮书」从上述信息来看，小程序的技术认知已经被中国开发者，甚至全球广泛认可。

小程序容器 &转 App 技术

得益于小程序场景生态的发展，小程序的跨智能终端应用开始被一些企业研究。于是乎，小程序容器技术应需而生。

当 App 集成了小程序容器 SDK 之后，不论是 iPhone, Android, Flutter,React Native, 电脑、电视、车载或物联网设备，都能够让不同的应用或终端设备快速具备运行小程序的能力，而且同一个小程序场景可以分发到不同终端中运行，不需要针对不同终端编写不同代码，这类小程序容器技术可以借鉴一下FinClip。

转 App 技术

本人是亲自测试过FinClip小程序管理平台，类似微信小程序开放平台，能够将上传至平台上的小程序进行统一的管理，也能够邀请第三方的开发者，对于小程序开发全生命流程参与到某一个开发环节中来。

平台自带的、与现有 App 进行关联绑定后，已有 App 便能具备运行小程序的能力。另外，自带的转 App 功能，本质上是将 App 的基本要素，结合平台上已有的小程序，一并打包生成一个具备丰富内容的小程序套壳 App。

如果您所在企业的应用，已经有部分业务内容小程序，不妨试试这个办法，快速应对鸿蒙操作系统独立的进程。如果还没有任意小程序，那么可以考虑从 1-2 个高频迭代的应用开始，进行小程序化的改造，从成熟的 Andriod 或 IOS 系统开始试用起来。混合 App 开发已经是现今技术的一种趋势，或者说优势所在，其中，「App+小程序」的 App 混合开发模式更优：

• 远超过 H5 的体验（支持本地缓存，Webview，有丰富的组件与支持库）；

• 能获取更多系统权限，完成更加丰富的产品设计；

• 可以避免 DOM 泄露（不使用常用的 window 对象与 document 对象）；

• 包尺寸有效减少，节省流量和存储

也不排除很多复杂的，面相终端消费者的 App 开发是更为复杂的“四不像”技术开发。但只要能满足业务的快速发展，流量-留量的双向互通，同时不影响用户的体验，那 App 是“纯血”还是“混血”，也不是那么纠结的事情。

鸿蒙元年已来，中国企业数字化进程的又一波红利期，就看我们用何种方式抓住机会，个人是建议先用简单的技术方式先适配，至少保证业务在鸿蒙独立的操作系统上运作，然后再考虑逐渐的进行鸿蒙化原生改造。又或者，直接考虑长期将越来越多的业务模块云化或者小程序化，以满足业务快速运行、市场化需求为主，一方面降低多端的维护成本，一方面提高开发效率，真正做到技术上降本增效。