浅析：HarmonyOS 一次开发多端部署

万物互联时代，应用的设备底座将从几十亿手机扩展到数百亿设备。全新的全场景设备体验，正深入改变消费者的使用习惯， 同时应用开发者也面临设备底座从手机单设备到全场景多设备的转变，通过全场景多设备作为全新的底座，为消费者带来万物互联时代更为高效澝便捷的体验。新的场景同时也带来了新的挑战澞开发者不仅要支持更加多样化的设备，还要支持跨设备的协作。不同设备类型意味着不同的传感器能力、硬件能力、屏幕尺寸、操作系统和开发语言，还意味着差异化的交互方式。同时跨设备协作也让开发者面临分布式开发带来的各种复杂性，例如跨设备的网络通信、数据同步等。若采取传统开发模式，适配和管理工作量将非常巨大。当前移动应用开发中遇到的主要挑战包括：

• 针对不同设备上的不同操作系统，重复开发，维护多套版本；
• 多种语言栈，对人员技能要求高；
• 多种开发框架，不同的编程范式；
• 命令式编程，需关注细节，变更频繁，维护成本高。

为了更好的抓住机遇，应对万物互联所带来的系列挑战，新的应用生态应该具备如下特征：

• 单一设备延伸到多设备：应用一次开发就能在多个设备上运行，软件实体能够从单一设备转移到其他设备上，且多个设备间能够协同运行，给消费者提供全新的分布式体验；
• 厚重应用模式到轻量化服务模式：提供轻量化的服务，最小化资源消耗，一步直达， 快速完成消费者特定场景的任务；
• 集中化分发到 AI 加持下的智慧分发：为消费者提供智慧场景服务，实现“服务找人”；
• 纯软件到软硬芯协同的 AI 能力：提供软硬芯协同优化的原生 AI 能力，全面满足应用户高性能诉求；

以上就是鸿蒙生态应用开发白皮书里万物互联时代应用开发的机遇、挑战和趋势章节里的描述，代表了鸿蒙人的思考和出发点，接下来我们就简单解读下这些挑战和趋势是什么？

简单解读

具体挑战是什么？

• 移动端我们有android，ios两种主流操作系统，开发语言，接口，所有技术细节都不一样，找两者都会的工程师难，那应用厂商若是要做APP跑不同设备上就得用两套班子，人力成本大；第二，android，ios分裂产品形态多，手表，PAD，手机，车机，电视，PC，未来可能更多，那同理对APP开发维护就是更大的挑战，不同的交互，不同的UI，不同版本，不同团队，如何保证产品一致，稳定，同步，体验，挑战巨大；第三再设想下未来，音箱，灯光，空调，冰箱，甚至是广告牌，监视器，摄像头，无人机，机器人所有的联网智能设备，这种面向未来的开发我们要做什么准备？

下面我们就对这三进行具体分解，也就是上段所指的具体特征：

在应用开发侧

• 对应用开发者，最直接的问题就是UI问题，如布局，样式，交互等，这个其实大家都有方案，比如说自适应布局，当外部容器大小发生变化时，元素可以根据相对关系自动变化以适应外部容器变化的布局能力。相对关系如占比、固定宽高比、显示优先级等。当前自适应布局有4种： 线性布局、 层叠布局、 弹性布局、 相对布局。自适应布局能力可以实现界面显示随外部容器大小连续变化；响应式布局，当外部容器大小发生变化时，元素可以根据断点、栅格或特定的特征（如屏幕方向、窗口宽高等）自动变化以适应外部容器变化的布局能力。当前响应式布局能力有2种： 媒体查询、 栅格布局。这部分基于华为丰富应用场景的支撑，以及对内容的深入理解，使用过程中大家应该能发现有些空间更智能，更好用；
• 对应用模型来说，原来android和ios上的原生应用都是厚重的，现在有些应用几个G，10几个G都有，平均尺寸也有几百兆，而鸿蒙化的HAP则提出了新的设计方式，HarmonyOS的用户应用程序包以APP Pack（Application Package）形式发布，它是由一个或多个HAP（HarmonyOS Ability Package）以及描述每个HAP属性的pack.info组成。HAP是 Ability的部署包，HarmonyOS应用代码围绕Ability组件展开。HAR（HarmonyOS Ability Resources）可以提供构建应用所需的所有内容，包括源代码、资源文件和config.json文件。HAR不同于HAP，HAR不能独立安装运行在设备上，只能作为应用模块的依赖项被引用。HSP（HarmonyOS Shared Package）：这是一种新增的编译产物。HSP 使得模块可以以运行态复用的形式共享。相较于 HAR，当有多个 HAP 包依赖于同一个 HSP时，最终的打包产物中，HSP 只会存在一份。除了这三种应用包的格式，为了应用轻量化，HarmonyOS提出元服务概念，什么意思？简单类比就是小程序，形式还是HAP的形式，但是用卡片方式展现，归应用程序框架管理，入口多，易被唤出。最后，应用还分出各种Ability，这是应用程序框架中最基本的抽象单位，代表最小的应用功能单元。在现在主推的Stage模型中，Ability也分两大类：
• UIAbility：应用的主入口，对应桌面上的图标。一个 UIAbility 实例对应一个任务。一个 UIAbility 中的通常包含多个ArkUI页面；
• ExtensionAbility：ExtensionAbility 有多个具体的子类型，例如：FormExtension 用来开发万能卡片， InputMethodExtensionAbility 用来开发输入法等。

以上这两点就是从功能和形式上解决了适配不同屏的问题，解决了应用大的问题，也解决了应用形态的问题，Ability的提出跟解决了界面和功能的问题。鸿蒙运用了解构的方式把大问题拆解成立一些小问题，然后加以实现和演进。当然这后面还包括工程、上架，这部分说起来就是另外一块事情了，我们今天就不再深入分析。简答分析下场景：

• 模式 1：应用或服务的 UI 自适应不同尺寸的设备屏幕，并且在不同设备的功能相同，可以实现多设备共享一个 HAP 包。这种场景下建议开发者通过一个模块来开发，并配置该模块支持多设备，然后再编译构建生成一个 HAP，分发到不同类型的设备上运行。
• 模式 2：应用或服务的 UI、功能在不同设备间存在差异，无法实现 HAP 包多设备归一。可根据实际情况设置不同模块适用的设备类型，编译构建多个 HAP 包，一起上架。HUAWEI AppGallery Connect 会自动提取 HAP 中的设备类型的配置信息，为对应的设备自动分发正确的 HAP 包组合。

在系统开发侧

• 事件归一抽象：不同设备间的交互方式等存在差异，如触摸、键盘、鼠标、语音、手写笔等，鸿蒙系统将不同设备的输入映射成归一交互事件，从而简化开发者适配逻辑。以缩放交互为例，通过多指触控的张合来完成缩放动作，在多设备场景下，缩放交互会出现多种不同的操作输入方式，比如手表就是表冠旋转，鼠标就是滚轮。
• 组件归一响应：当应用部署在不同设备上供用户使用时，需要支持多种 I/O 设备，界面呈现出相应的状态为用户提供正确的视觉引导。例如触摸时显示按压状态，鼠标特有的悬停状态，键盘走焦状态。渇蒙系统默认提供多种交互方式的组件实现，方便开发者支持多种输入方式。
• 设备能力抽象：不同设备间的软、硬件能力等存在差异，如设备是否具备定位能力、是否具备摄像头、 是否具备蓝牙功能等，鸿蒙系统需要对设备能力进行逻辑抽象，并提供接口来查询设备是否支持某种能力，方便开发者进行不同软、硬件能力的功能适配。在鸿蒙系统中，使用SystemCapability（简写为 SysCap）定义每个部件对应用开发者提供的系统软硬件能力。应用开发者基于统一的方式访问不同设备的能力。
• 元服务开发：元服务是鸿蒙系统提供的一种全新的应用形态，具有独立入口，用户可通过点击、碰一碰、扫一扫等方式直接触发，无需显式安装，由程序框架后台静默安装后即可使用，可为用户提供便捷服务。元服务入口多，在服务中心可见，也能通过语音，NFC，摄像头等联动唤入，然后可以用户无感安装和卸载，即用即走；元服务还支持流转，通过分布式软总线的加持，元服务支持跨端迁移（将软件实体从一个设备转移到另一个设备，比如手机视频迁移到智慧屏）或多设备协同（多个物理设备上的软件共同完成一件事情，比如电视投屏+手机遥控，但是这个细分也好几种，比如显示协同，不同大屏和小屏显示不同东西；交互协同，手机输入，智慧屏显示；算力协同）。

系统侧开发想尽办法提供一站式解决方案，抽象输入，抽象交互，抽象数据，抽象硬件，无线压缩所有的可见路径，让应用只聚焦业务。所以这部分对应用开发者来说就是统一接口，统一工程，统一规范；对系统开发者来说就是一个足够具象的微服务森林，没一个端到端的功能都需要仔细梳理并有弹性和生命力。系统侧其实做了太多的工作，软总线，分布式，ArkUI，应用管理，SA化，大量的细化，解耦工作才能使得应用即服务这样的能力在系统层生根发芽。这部分说起来简单，管理起来那正是千头万绪，而且随着接入硬件形态的不断增加、复杂，如何做兼容性，如何保证体验，如何减低整个系统的可维护性，才是最大的挑战。可以看出来，鸿蒙覆盖千行百业的决心和勇气，也可以预见系统的庞杂和勃勃生机。接入厂商的增多，鸿蒙原生应用的增多，希望大家能碰撞出更多的、更实用的场景和一多能力。