一文带你看懂HarmonyOS如何适配多种终端

HarmonyOS是一款面向万物互联时代的、全新的分布式操作系统。在传统的单设备系统能力基础上，HarmonyOS提出了基于同一套系统能力、适配多种终端形态的分布式理念。

为了实现“基于同一套系统能力、适配多种终端形态”，HarmonyOS采用了“组件化”的设计方案，实现根据设备的资源能力和业务特征灵活裁剪，满足不同形态终端设备对操作系统的要求。

一、为什么采用“组件化”设计方案？
分层架构是最为流行、应用最为广泛的软件架构设计方式，将整个软件系统自顶而下垂直划分成若干个层级，对每一层的系统能力、特定行为进行抽象。层级之间单向依赖，上层使用下层的各种服务，而下层对上层不感知。每一层对自己的上层提供接口的同时，隐藏内部实现细节。

对于中小规模系统，基于架构分层可以较好地解决系统架构解耦和跨团队协作问题，每一层提供一定的业务功能，可以由不同的小团队负责每一层不同的业务交付。然而，对于操作系统这么庞大的软件系统，只有架构分层还是远远不够的，因为每一层都很复杂，同一分层内不同模块之间相互依赖、无序调用。如果没有进一步的组件化架构，绝对会给软件工程和项目管理带来巨大的灾难。

图1 架构分层

基于以上原因，HarmonyOS采用了组件化的设计方案，先对复杂的操作系统进行架构分层，再对每一层进行组件化。

下面我们就来具体看看HarmonyOS的“组件化”设计方案。

二、“组件化”设计方案详解
1. HarmonyOS架构分层
首先，我们来看看HarmonyOS系统是如何架构分层的。

图2 HarmonyOS架构分层

如图2所示，HarmonyOS划分为以下层级：

• 应用层：由应用开发者交付，向最终消费者提供UI接口，为消费者体验负责。应用层向下仅依赖于框架层提供的API，应用开发仅依赖于HarmonyOS发布的SDK。
• 框架层、系统服务层和内核层：这三个层级属于HarmonyOS基础平台，由HarmonyOS平台开发者交付，面向北向应用生态提供API和SDK，面向南向设备生态提供Driver InteRFace和DDK（Driver Development Kit，驱动开发包）。
• 驱动层：由设备开发者交付，向HarmonyOS提供器件驱动实现。驱动层仅依赖于驱动框架提供的Driver Interface，驱动开发仅依赖于HarmonyOS发布的DDK。
  

我们通过架构分层对HarmonyOS操作系统进行大颗粒系统解构，方便不同的生态参与方。参与方既可以相对独立，又可以相互协作，共同构建形形色色的智能终端设备和丰富的应用软件，为消费者带来全场景智慧服务体验。

2. HarmonyOS基础平台组件化
HarmonyOS基础平台涉及框架层、系统服务层和内核层三部分，HarmonyOS对这三个层级进行了进一步的组件化设计。

• 内核层组件化
  如图3所示，内核层包括LiteOS、Linux和驱动框架三个组件。
  

• LiteOS和Linux组件可以按需部署在不同设备之上。这两个组件向系统服务层提供POSIX（Portable Operating System Interface，可移植操作系统接口）和CMSIS（Common microcontroller Software Interface Standard，通用微处理器软件接口标准）接口，用于屏蔽不同的内核实现差异。
• 驱动框架组件向驱动层提供了Driver Interface和DDK，向系统服务层提供标准化的硬件操作接口HDI（HarmonyOS Driver Interface）。
  

图3 内核层组件化

• 框架层/系统服务层组件化
  

HarmonyOS系统架构分层根据功能定位区分了系统服务层和框架层，系统服务层是所有系统服务的汇总，通过框架层向应用暴露API。单个系统能力实现通常分布在系统服务层和框架层，考虑到系统服务和框架紧密耦合，在HarmonyOS中未统一定义系统服务层和框架层之间的层间接口。如图4所示，HarmonyOS将同一个功能实现的系统服务和框架组合在一起，形成一个个独立的“组件”，每个组件提供一个的系统能力和对应的API接口。组件之间基于InnerSDK完成解耦，支持组件独立代码下载、独立编译、独立测试和组件拼装。

图4 框架层/系统服务层组件化

三、HarmonyOS如何在多终端部署？
通过“组件化”设计后，HarmonyOS支持根据设备的资源能力和业务特征灵活裁剪，满足不同形态终端设备对操作系统的要求。也就是说，一套HarmonyOS可以部署到不同的终端设备上。

为了部署在不同形态的终端设备上，HarmonyOS细分为以下四种基本系统规格：

• 轻量系统（mini system）
  面向MCU（Micro Control Unit，微控制单元）类处理器的设备，支持的设备最小内存为128KiB，如智能家居领域的连接类模组、传感器设备、穿戴类设备等。
  可以提供多种轻量级网络协议，轻量级的图形框架，以及丰富的IoT总线读写组件等。
• 小型系统（small system）
  面向应用处理器的设备，支持的设备最小内存为1MiB，如智能家居领域的IP Camera、电子猫眼、路由器以及行车记录仪等。
  可以提供更高的安全能力，标准的图形框架，以及视频编解码的多媒体能力。
• 标准系统（standard system）
  面向应用处理器的设备，支持的设备最小内存为128MiB，如带屏IoT设备、智能手机。
  可以提供增强的交互能力，3D GPU和硬件合成能力，更多控件和动效更丰富的图形能力，以及完整的应用框架。
• 大型系统（large system）
  面向应用处理器的设备，支持的设备最小内存为1GiB，如智慧屏、智能手表等。
  可以提供支持兼容三方OS系统的应用框架。
  

HarmonyOS根据不同的系统规格，分别定义了最小系统必选组件集和对应的可选组件集。产品部署HarmonyOS时，根据系统规格类型选择对应的最小系统必选组件集，同时根据不同产品的差异化功能需要选择可选组件。基于组件间依赖管理，如果某个可选组件被选择，相应该组件依赖的其他组件也会自动被打包到HarmonyOS系统。

图5 选择组件

在开发者资源中心DevEco Marketplace可以进行组件管理，灵活拼装出不同的产品解决方案。DevEco Marketplace的详细介绍，请参见往期推文。

DevEco Marketplace链接如下：https://repo.

组件是拼装HarmonyOS的一个个零部件。每个组件都提供一定的系统能力，一些组件还涉及面向应用暴露API接口。不同组件组合部署到特定设备上，面向应用提供的API能力会存在差异。本文我们就组件的部署原理做了详细说明，后续我们还将对组件化架构下的组件运行态管理、SDK管理与应用分发原理做进一步的详细解析，敬请期待！