[文章]HDC2021技术分论坛:“积木拼装”,HarmonyOS弹性部署大揭秘!

阅读量0
0
2
作者:peitaiyi,华为终端OS产品交付专家

HarmonyOS是一款面向万物互联时代的、全新的分布式操作系统。在传统的单设备系统能力基础上,HarmonyOS提出了基于同一套系统能力、适配多种终端形态的分布式理念,能够支持手机、平板、智能穿戴、智慧屏、车机等多种终端设备,实现更好的万物互联。

那么,HarmonyOS是如何用一套OS源码部署到多种终端的呢?本文将为你揭秘。

一、面临的挑战

首先,我们先简单介绍一套OS部署到多种终端面临的两大挑战。

  • 传统OS能力比较单一:一套OS系统部署到多种终端,不仅要支持百KB到GB级的内存,还需支持主流CPU架构、板级的器件、各种SoC及外设模组。而传统OS大都是单设备操作系统,一套OS仅适配于一套设备,无法满足碎片化的硬件需求。

  • 传统OS裁剪拼装能力差:产品形态分布于千行百业,大到汽车、电视、手机,小到手表、门铃、烤箱,不同功能的产品对OS的能力诉求不同,这要求OS可以灵活地剪和拼装。而传统OS裁剪拼装能力差,无法满足千行百业的产品。

图1 硬件和产品形态的碎片

二、HarmonyOS应对策略

基于上述的挑战,HarmonyOS应对策略是“OS可大可小,部件一次开发可在多种终端上部署”

1. 部件介绍

部件是HarmonyOS系统能力的基本单元,具有可复用、可裁剪、可配置、可独立编译和测试的特点。以源码、配置和资源文件为划分依据,拥有独立的文件和目录,可在不同的设备上实例化为不同的库或二进制文件,图2所示。

从系统角度看,部件可视为任何能运行在HarmonyOS上的软件。从外部设备看,部件则可视为一个个按设备所需组装成OS的系统能力。

图2 HarmonyOS部件化示意图

2. 部件拼装

HarmonyOS源码由“必选部件集”和“可选部件集”组成,必选部件集具有HarmonyOS特征的必选系统能力,可选部件集则具有产品可裁剪的系统能力。被裁剪的部件只会引起对应系统能力的缺失,不会引起系统的异常。

必选部件和可选部件像“积木”一样,根据设备硬件模块(摄像头、扬声器、屏幕、网络)与内存大小灵活拼装成不同的OS软件包,并部署到不同设备。

“大设备装大系统,小设备装小系统。”无论智能设备的运存大小如何,总能找到匹配TA的那一块系统积木。

图3 积木拼装

HarmonyOS部件拼装流程如图4所示。HarmonyOS发布归一化的SDK,应用开发者使用SDK和IDE进行跨设备的应用开发,再按不同的设备类型分发应用。同时,三方的部件也可以与OS软件包一起部署到设备中。

图4  HarmonyOS部件拼装流程

至此,相信大家对部件拼装有了一定的认识。随着万物互联时代的不断发展,HarmonyOS将适配越来越多的硬件设备,这就使得部件开发将马不停蹄,以适应千行百业的硬件产品。开发者如何开发部件呢?下文将为你解答。

三、如何开发部件

我们都知道,HarmonyOS是基于开源项目OpenHarmony开发的面向多种全场景智能设备的商用版本,HarmonyOS的部件大都来自OpenHarmony,所以下文对部件开发的解答,将围绕OpenHarmony部件的开发展开。

在OpenHarmony生态中有三大类开发者:OS开发者、芯片解决方案厂商和产品解决方案厂商,如图5所示。

图5 OpenHarmony开发者

  • OS开发者提供OpenHarmony所需的部件,包括内核、驱动框架、图形、媒体等基础的系统能力。
  • 芯片解决方案厂商对OS的驱动和接口进行适配,形成基于开发板的完整芯片解决方案。
  • 产品解决方案厂商基于OS和成熟的芯片解决方案组装产品。

1. 部件标准化

部件开发前需完备部件详细设计,在此过程中部件标准化尤为重要。

部件标准化确定了部件的名称、功能、可配置的特性、详细的规格和依赖。一个典型的部件的定义,图6所示。它包含了部件的名称、功能描述、是否系统必选、ROM/RAM、可配置特性和依赖等等。部件的依赖应尽量简单合理,杜绝循环和冗余的依赖。禁止部件直接依赖特定硬件和产品。

图6 部件定义文件

只有OS的系统能力都按部件进行标准化后,对外的系统能力才能灵活按需拼装。

2. 部件、开发板和产品严格解耦

为了保持OS可裁剪可拼装的能力,部件开发过程中,部件与开发板和产品之间应严格解耦且可独立编译。至此,我们将开发视图分为OS部件、芯片解决方案和产品解决方案,如图7所示。“OS部件”目录主要存放OS的能力集,比如内核、媒体、图形、电话、分布式软总线、安全等等。“芯片解决方案”目录主要存放芯片厂商基于某个开发板或者SoC对OS的适配。“产品解决方案”目录主要存放产品相关的配置以及厂商对OS接口的实现。

图7 OpenHarmony开发视图目录树示意图

基于OpenHarmony开发视图目录树,实现了部件、开发板和产品各自独立的开发,保障了三者良好的解耦性。

3. 全流程管控

部件在设计、开发和测试过程中,需严格管控整个流程。如图8所示,设计文档在对应PMC审核通过后方可启动部件的开发,在SIG组开发功能成熟后,再经OpenHarmony对应子系统的committer审核合入。合入后,测试团队将按部件独立测试验收,验收的范围不仅包括部件的功能和稳定性,还包括部件是否可独立编译、独立测试、依赖是否合入等等。HPM(HarmonyOS Package Manager)审核人员审核通过后,便可以申请HPM上架。

图8 HarmonyOS部件管控流程

说明:
  • PMC(Projects Management Centre)是指项目管理委员会,负责OpenHarmony 社区的管理工作,拥有代码库写权限、OpenHarmony 新版本发布、Roadmap发布、新PMC/Committer等社区事务的投票权、以及新的 PMC 成员和 Committer 提名权。
  • SIG(Special Interest Group)是指特别兴趣小组,SIG在PMC项目管理委员会指导下,负责OpenHarmony社区特定子领域及创新项目的架构设计、开源开发及项目维护等工作。

以上就是本期全部内容!相信大家对部件有了一定的认识,欢迎广大开发者参与到部件开发中。


回帖

声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容图片侵权或者其他问题,请联系本站作侵删。 侵权投诉
链接复制成功,分享给好友