一、什么是HarmonyOS
- 2019年8月9日,华为在华为开发者大会上正式发布HarmonyOS 1.0,同时将该操作系统开源。
- 2020年9月10日,HarmonyOS 2.0 正式发布。
- 2022年11月4日,全新的HarmonyOS 3.1发布,引入全新的Stage模型(准备放弃FA模型)。
二、目标
本文章将带领我们掌握以下技能:
- 理解HarmonyOS基本概念;
- 体会HarmonyOS设计理念;
- 区分HarmonOS技术架构层次;
- 了解HarmonOS部件化架构设计;
- 掌握HarmonOS技术特性;
- 了解HarmonOS系统安全;
三、HarmonyOS简介
万物互联时代正在开启
经过十多年的发展,传统移动互联网的增长红利已渐见顶,IoT时代即将到来。
新场景带来的挑战
不同的设备类型意味着不同的传感器能力、硬件能力。屏幕尺寸、操作系统和开发语言,以及交互方式等。同时跨设备协作也让开发者面临这分布式开发带来的各种复杂性,适配和管理工作也将非常巨大。当前移动应用开发中遇到的主要挑战包括以下一种:
- 针对不同设备上的不同操作系统,重复开发,维护多套版本。
- 多种语言栈,对技术人员技能要求较高。
- 多种开发框架,不同的编程范式。
- 命令式编程,需要关注细节,变更频繁,维护成本高。
移动终端应用生态面临变革
传统应用具有以下优缺点:
优点:
- 功能齐全
- 整体体验好
缺点:
- 厚重
- 开发周期长、成本高
- 信息、应用孤岛(传统应用之间是彼此独立的、碎片化的)
- 以应用未中心,而非用户为中心
- 需要用户主动关注等显性操作
轻量化程序实体正在成为新的趋势,轻量化程序具备“即用即走、无需安装卸载、永远最新”的特征,推动了App基于搜索下载的“人找应用”的传统分发想“服务找人”的智慧分发演进。
鸿蒙生态迎接挑战
-
单一设备延伸打多设备
应用一次开发就能在多个设备上运行,软件实体能够从单一的设备转移到其他设备上,且多个设备之间能够协同运行,给消费者提供全新的分布式体验。
-
厚重应用模式到轻量化服务模式
提供轻量化的服务,最小化资源消耗,一步直达,快速完成消费者特定场景的任务。
-
智慧分发到AI加持下的智慧分发
为消费者提供智慧服务场景服务,实现“服务找人”。
-
纯软件到软硬芯协同的AI能力
提供软硬芯协同话的原生AI能力,全面满足应用高性能诉求。
HarmonyOS系统定义
- HarmonyOS是一款面向万物互联时代的、全新的分布式操作系统。
- 在传统的单设备系统能力基础上,HarmonyOS提出了基于同一套系统能力、设备多种终端形态的分布式理念,能够支持手机、平板、智能穿戴、智慧屏、车机等多种终端设备,提供全场景(移动办公、运动健康、社交通讯、媒体娱乐)业务能力。
HarmonyOS发展史
2019年 > HarmonyOS正式发布并开源核心代码。
2020年 > 鸿蒙智联面向硬件生态伙伴全面开放
2021年 > 手机及多种智能终端设备搭载HarmonyOS 2
2022年 > 全新的HarmonyOS 3.1发布并推出Stage模型,五大场景体验持续化鸿蒙生态更加成熟
2023年 > HarmonyOS 4 发布
2024年 > HarmonyOS NEXT 正式发布,抛弃对AOSP的支持,鸿蒙原生应用全面启动。(不出意外的话,因为现在还是2023年,偷笑.jpg)
ArkTS
ArkTs 是华为自研的开发语言。它在TypeScript的基础上,匹配ArkUI框架,拓展了声明式UI、状态管理等相应的能力,让开发者以更简洁、更自然的方式开发跨端应用。
@Entry
@Component
struct SecondPage {
@State myText: string = 'World'
build() {
Column() {
Text(`Hello ${this.myText}`)
.fontSize(50)
Divider()
Button('Click me')
.onClick(() => {
this.myText = 'ArkUI'
})
.height(50)
.width(100)
.margin({ top: 20 })
}
.height('100%')
.justifyContent(FlexAlign.Center)
}
}
ArkUI
ArkUI是一套构建分布式应用界面的声明式UI开发框架。它使用极简的UI信息语法、丰富的UI组件、以及实时界面预览工具,提升开发效率。使用一套ArkTS API,就能在多个HarmonyOS设备上提供生动流畅的用户界面体验。
逻辑和UI分离通过利用数据双向绑定机制传递页面变化逻辑,将流转7个步骤简化为2个步骤。可将跨端迁移和协同的开发代码量降低40%以上。
方舟编译器(ArkCompiler)
ArkCompiler是华为自研的统一编程平台,包含编译器、工具链、运行时等关键部件,支持多种编程语言、多种芯片平台联合编译、运行而设计的统一编程运行时平台。支持包括动态类型和静态类型语言在内的多种编程语言,如:JS、TS、ArkTS等。
-
方舟编译器是鸿蒙系统作为手机、PC、平板、电视、车机和智能穿戴设备等多种设备统一操作系统的编译运行时底座。主要分成两个部分:
-
编译工具链
编译工具链以ArkTS/TS/JS源码作为输入,将其编译成为ABC(ArkCompiler Byte Code,即方舟字节码)文件。
-
运行时
运行时直接运行字节码文件,实现对应语言规范的语义逻辑。
-
方舟编译器具有以下特点:
-
AOT编译模式
ArkCompiler利用ArkTS的静态类型信息,进行类型推导并生成对象描述和内联缓存,加速运行时对字节码的解释执行;AOT(Ahead-of-Time)Compiler利用静态类型信息直接将字节码编译生成优化机器码,让应用启动即可运行高性能代码,提升应用启动和运行性能。
-
LiteActor轻量化并发
ArkCompiler运行时在HarmonyOS上提供了Worker API支持并发编程。在运行时实例内存隔离的基础上,ArkCompiler通过共享运行实例中的不可变或者不易变的对象、内建代码块、方法字节码等技术手段,优化了并发运行实例的启动性能和内存开销。
-
源码安全
ArkCompiler会把ArkTS/TS/JS编译为方舟字节码,运行时直接运行方舟字节码。并且ArkCompiler使用多种混淆技术提供更高强度的混淆与保护,使得HarmonyOS应用包中装载的是多重混淆后的字节码,有效提高了应用代码安全的强度。
开源开放的生态环境
- HarmonyOS是华为通过OpenHarmony项目,结合商业发行版增加能力,构建华为自研产品的完整解决方案。
- OpenHarmony是由开放原子开源基金会(OpenAtom Foundation)孵化及运营的开源项目,目标是面向全场景、全链路、全智能时代,基于开源的方式,搭建一个智能终端设备操作系统的框架平台,促进万物互联产业的繁荣发展。
OpenHarmony生态组成
OpenHarmony的生态由华为与生态合作伙伴共同构建,旨在构建一个健康的,可以自我正想迭代的生态系统,以持续吸引开发者和合作伙伴的加入,从而进而带动更多的用户选择。
-
HMS
HMS类似于Google的GMS,是一个集华为全家桶的一个App,包含着许多功能接口的API的服务能力,是华为自由的不开源的。
-
华为商用的HarmonyOS
相当于基于Android的AOSP所构建的EMUI、MIUI等高度自定义UI的Android系统。HarmonyOS是基于OpenHarmony构建的商业版的操作系统。
-
HarmonyOS Connect
华为向合作厂商提供的一种解决方案。
HarmonyOS Connect 服务包为合作伙伴提供设备开发、原子化服务开发、设备全生命周期运营运维等一站式智能化解决方案,由基础服务、增强服务、HarmonyOS Connect 云等组成。基础服务为设备赋予超级终端体验,增强服务提供设备运维分析、运营变现能力以及专属场景服务,HarmonyOS Connect 云连接设备与用户,共同助力开发者快速实现产品智能化升级,打造互联互通的 HarmonyOS Connect 生态。
根据伙伴选择的不同的解决方案与产品体验特性,我们提供基于 OpenHarmony 系统的闭源服务包,您可以在“管理中心”中,完成产品定义后,即可获取对应的服务包。
-
OpenHarmony
相当于Android中的AOSP,是一个开源的项目,具有最基础的操作系统的能力。
HarmonyOS Connect介绍
- HarmonyOS Connect(中文:鸿蒙智联)是华为统一的硬件生态品牌。
- HarmonyOS Connect生态伙伴可以基于华为提供的芯片设计、操作系统、连接、云、AI和用户体验设计能力,为消费者提供高品质的智能硬件生态设备,使该设备能够与华为HarmonyOS设备(包括手机、全屋主机、智能座舱、智慧屏、手表等终端)以及其他的HarmonyOS Connect生态设备进行连接和协同,共同打造互联互通的HarmonyOS Connect生态。
HarmonyOS Connect协助三种商业形态发展
1个平台、3种商业模式:
-
鸿蒙智联产品
伙伴自由渠道为主
-
华为智选
华为全渠道销售为主
-
全屋子系统
全屋渠道销售为主
HarmonyOS Connect生态智能家居产品合作伙伴案例
美的智能化家电、九阳不用手洗豆浆机、苏泊尔小C主厨料理机、方太智能电蒸箱、探梦者滑板车、新日电动车、奥佳华按摩椅等等。
四、HarmonyOS设计理念
HarmonyOS设计理念概述
HarmonyOS从用户和开发者视角出发,开发出一款面向万物互联时代的操作系统。
-
HarmonyOS的设计理念有两条:
-
消费者体验最佳原则
在终端硬件形态多样化的趋势下,保证用户分布式多设备协同的体验一致性,实现多端生态一体化。
-
开发者最小代价原则
像开发单设备一样开发分布式应用,一次开发多端部署。
-
HarmonyOS试图解决的问题
HarmonyOS作为面向智能终端的新一代OS,智能终端在万物互联的时代面临的问题就是HarmonyOS需要解决的问题目标范围。
- 软件能力割裂
- 应用生态割裂
- 用户数据割裂
- 多设备交互割裂
HarmonyOS设计目标
- 业务设计目标
- HarmonyOS的定位是面向万物互联下的操作系统,支撑万物互联下的多种设备和业务诉求,并随同相关技术而不断演进。
- 架构设计目标
- 弹性
- 可演进性
- 生态友好性
- 可重构性
- 可用性
- 流畅性
- 安全性
- 架构设计原则
- 分层抽象构建原则
- 积木化搭建原则
- 用户体验优化原则
- 隐私保护与安全原则
- 生态开放原则
- 分布式架构原则
- 接口隔离及兼容性原则
- 高性能低功耗原则
- 开源引用原则
鸿蒙生态应用核心技术理念
在万物智联时代重要机遇期,鸿蒙系统结合移动生态发展的趋势,提出了三大技术理念。
超级终端
超级终端是按用户在不同场景下使用各种智能终端,通过HarmonyOS的自动协同组成的一个逻辑终端。超级终端包含了各种类型的只能终端,是HarmonyOS管理的终端类型,对用户而言,就像一个终端。
五、HarmonyOS技术架构
HarmonyOS整体遵从分层设计,从下向上依次为:内核层、系统服务层、框架层和应用层。系统功能按照“系统 > 子系统 > 功能/模块”逐级展开,在多设备部署场景下,支持根据实际需求裁剪某些非必要的子系统或功能/模块。HarmonyOS技术架构如下所示。
内核层
内核子系统:HarmonyOS采用多内核设计,支持针对不同资源受限设备选用适合的OS内核。内核抽象层(KAL,Kernel Abstract Layer)通过屏蔽多内核差异,对上层提供基础的内核能力,包括进程/线程管理、内存管理、文件系统、网络管理和外设管理等。
驱动子系统:硬件驱动框架(HDF)是HarmonyOS硬件生态开放的基础,提供统一外设访问能力和驱动开发、管理框架。
系统服务层
系统服务层是HarmonyOS的核心能力集合,通过框架层对应用程序提供服务。该层包含以下几个部分:
系统基本能力子系统集:为分布式应用在HarmonyOS多设备上的运行、调度、迁移等操作提供了基础能力,由分布式软总线、分布式数据管理、分布式任务调度、方舟多语言运行时、公共基础库、多模输入、图形、安全、AI等子系统组成。其中,方舟运行时提供了C/C++/JS多语言运行时和基础的系统类库,也为使用方舟编译器静态化的Java程序(即应用程序或框架层中使用Java语言开发的部分)提供运行时。
基础软件服务子系统集:为HarmonyOS提供公共的、通用的软件服务,由事件通知、电话、多媒体、DFX(Design For X) 、MSDP&DV等子系统组成。
增强软件服务子系统集:为HarmonyOS提供针对不同设备的、差异化的能力增强型软件服务,由智慧屏专有业务、穿戴专有业务、IoT专有业务等子系统组成。
硬件服务子系统集:为HarmonyOS提供硬件服务,由位置服务、生物特征识别、穿戴专有硬件服务、IoT专有硬件服务等子系统组成。
根据不同设备形态的部署环境,基础软件服务子系统集、增强软件服务子系统集、硬件服务子系统集内部可以按子系统粒度裁剪,每个子系统内部又可以按功能粒度裁剪。
框架层
框架层为HarmonyOS应用开发提供了Java/C/C++/JS等多语言的用户程序框架和Ability框架,两种UI框架(包括适用于Java语言的Java UI框架、适用于JS语言的JS UI框架),以及各种软硬件服务对外开放的多语言框架API。根据系统的组件化裁剪程度,HarmonyOS设备支持的API也会有所不同。
应用层
- 应用层包括系统应用和第三方非系统应用。
- Ability是应用所具备能力的抽象,也是应用程序的重要组成部分。Ability是系统调度应用的最小单元,是能够完成一个独立功能的组件。一个应用可以包含一个或多个Ability。
- Stage模型将Ability分为PageAbility和ExtensionAbility两大类,其中ExtensionAbility又被拓展为ServiceExtensionAbility、FormExtensionAbility、DataShareExtensionAbility等一系列的ExtensionAbility,以满足更多的使用场景。
系统类型
根据设备的内存差异,鸿蒙操作系统适配的系统类型分为三类:
- 轻量系统(mini system)
- 支持的设备最小内存为128KiB
- 面向MCU(单片机)类处理器,例如Arm Cortex-M、RISC-V 32位的设备,硬件资源极其有限。
- 可以提供多种轻量级网络协议,轻量级图形框架,以及丰付的IOT总线读写部件等。可支撑的产品如智能家居领域的连接类模组、传感器设备、穿戴类设备等。
- 小型系统(small system)
- 支持设备最小内存为1MiB
- 面向应用处理器,例如:Arm Cortex-A的设备
- 可以提供更高的安全能力,标准的图形框架、视频编解码的多媒体能力。可支撑的产品如智能家居领域的IP Camera、电子猫眼、路由器以及智慧出行领域的行车记录仪等。
- 标准系统(standard system)
- 支持的设备最小内存为128MiB
- 面向应用处理例如Arm Cortex-A的设备
- 可以提供增强的交互能力、3D GPU以及硬件合成能力、更多控件以及动效丰付的图形能力、完整的应用框架。可支持的产品如高端的冰箱显示屏。
开发语言介绍
- 纯应用软件开发,基于官方提供的系统SDK进行应用开发。
- 软硬件结合的嵌入式开发,注重硬件操作、驱动开发、操作系统裁剪定制等。
-
应用开发
HarmonyOS支持如下语言
- ArkTS
- HML + JavaScript + CSS (仅FA模型可用)
- Java(仅API7及一下版本可用)
- C/C++
OpenHarmony支持如下语言
- ArkTS
- HML + JavaScript + CSS (仅FA模型可用)
- C/C++
-
设备开发
OpenHarmony设备开发仅支持
C/C++
编程语言。
六、部件化开发架构设计
HarmonyOS在模块化、组件化的基础上,引入了部件化架构的软件工程方法,综合运用模块化、部件化、组件化等手段,有效支撑了统一的操作在不同规格、不同形态、不同类型的设备上的弹性部署。
架构分层与组件化
能力集合
- HarmonyOS针对不同的系统规格,分别定义了基础部件能力集合(BCG)和可选部件能力集合(OCG),方便设备卡发着按需配置,已支撑其特色功能的扩展或定制开发。同时,HarmonyOS也支撑设厂商扩展私有的系统能力(PCG),打造设备差异化竞争力。
- 针对相同系统规格设备,具有相同的BCG系统能力,允许设备厂商按需选择好OCG系统能力、扩展PCG系统能力。
部件管理
-
为了支持基于部件的HarmonyOS积木花拼装,部件的基本特征包括:
部件之间的相对独立
和所依赖的部件一起拼装部署
-
可对外提供一定的系统软硬件能力
- HPM(HarmonyOS Package Manager)是HarmonyOS部件包的管理和分发工具,面向设备开发时,用于获取、定制HarmonyOS部件源码,执行安装、编译、打包等操作,最终构建特定产品的OS软件包,面向多设备部署时,如果部件之间存在依赖,则要求和被依赖的部件一起部署。
七、三大技术特性
-
消费体验
硬件互助,资源共享
HarmonyOS可以实现不同终端设备之间的快速连接、能力互助、资源共享,匹配合适的设备、提供流畅的全场景体验。
-
应用开发者体验
一次开发,多端部署
HarmonyOS采用了多种分布式技术,使得应用程序的开发实现与不同终端设备的形态差异无关,降低了开发难度和成本。
-
设备开发者体验
统一OS,弹性部署
HarmonyOS采用了组件化的设计方案,可以根据设备的资源能力和业务特征进行灵活裁剪,满足不同形态的终端设备对于操作系统的要求。
统一OS弹性部署
HarmonyOS通过组件化和小型化等设计方法,支持多种终端设备按需弹性部署,能够适配不同类别的硬件资源和功能需求。支撑通过编译链关系去自动生成组件化的依赖关系,形成组件树依赖图,支撑产品系统的便捷开发,降低硬件设备的开发门槛。
支持个组件的选择(组件可有可无):根据硬件的形态和需求,可以选择所需的组件。
支持组件内功能集的配置(组件可大可小):像开发单设备根据硬件的资源情况和功能需求,可以选择配置组件中的功能集。例如,选择配置图形矿建组件中的部分控件。一样开发分布式应用,一次开发多端部署。
支持组件间依赖的关联(平台可大可小):根据编译链关系,可以自动生成组件化的以来关系。例如,选择图形框架组件,将会自动选择依赖的图形引擎组件等。
一次开发多端部署
- HarmonyOS提供了用户程序框架、Ability框架以及UI框架,支持应用开发过程中多端的业务逻辑和界面逻辑进行复用,能够实现应用的一次开发,多端部署,提升了跨设备易用的开发效率。
- 采用业界主流的设计方式,提供多种响应式布局方案,支持栅格化布局,满足不同屏幕的界面适配能力。
硬件互助,资源共享
多种设备之间能够实现硬件互助、资源共享,依赖的关键技术包括分布式软总线、分布式设备虚拟化、分布式数据管理、分布式任务调度等。
分布式软总线
分布式软总线是手机、平板、智能穿戴设备等分布式设备的通信基座,为设备之间的互联互动提供了统一的分布式通信能力,为设备间的无感发现和零等待传输创造了条件。开发者只需聚焦于业务逻辑的实现,无需关注组网方式与底层协议。
分布式软总线是如何自发现并连接的呢?
分布式软总线提出自动发现设备,实现用户零等待的自发现体验,附近同账号的设备自动发现无需等待,自动安全连接。分布式软总线提出了异构网络组网,自动构建一个逻辑全连接网络,以解决设备间不同协议交互的问题。
分布式设备虚拟化
- 分布式设备虚拟化平台可以实现不同设备的资源融合、设备管理、数据处理,多种设备共同形成一个超级虚拟终端。
- 针对不同类型的任务,为用户匹配并选择能力合适的执行硬件,让业务连续的在不同设备间流转,充分发挥不同设备的能力优势,如显示能力、摄像能力、音频能力、交互能力以及传感器能力等。
分布式数据管理
用户数据不再与单一物理设备绑定,业务逻辑与数据存储分离,跨设备的数据处理如同本地数据一样方便快捷,让开发者能够轻松实现全场景、多设备下的数据存储、共享和访问,为打造一致、流畅的用户体验创造了基础条件。
分布式任务调度
分布式任务调度基于分布式软总线、分布式数据管理、分布式Profile等技术特性,构建统一的分布式服务管理(发现、同步、注册、调用)机制,支持对跨设备的应用进行远程启动、远程调用、远程连接以及迁移等操作,更够根据不同设备的能力、位置、业务运行状态、资源使用情况,以及用户的习惯和意图,选择合适的设备运行分布式任务。
八、系统安全
设备互信认证服务
-
设备互信认证服务
保证设备之间相互正确可信,并能够在验证信任关系后搭建安全的连接通道,实现用户数据的安全传输。
-
用户身份认证
除传统身份认证方式外,还提供生物认证方式和分布式协同认证能力。
-
应用程序隔离和权限管理
系统化地规范应用程序的行为准则与权限许可并强制执行。
-
数据分级访问控制架构
数据都能获得与其个人数据敏感程度、系统数据重要程度和应用程序数据资产价值匹配的保护措施。
-
数据防泄漏保护
数据生命周期范围内,数据的存储、访问和传输过程中数据泄露风险比较大。
九、元服务(原子化服务)
元服务定义
元服务是HarmonyOS提供的一种全新的应用形态,具有独立入口,用户可通过点击、碰一碰、扫一扫等方式直接触发,无需显示安装,由程序框架后台静默安装后即可使用,可为用户提供便捷服务。
元服务特性
元服务基于鸿蒙系统API开发,支持运行在1+8+N设备上,供用户在合适的场景、合适的设备上便捷使用。元服务是支撑可分可合,自由流转的轻量化程序实体,帮助开发者的服务更快触达用户。具备以下特点:
服务中心
服务中心为用户提供统一的元服务查看、搜索、收藏和管理功能。
元服务的服务流转
-
用户手动流转
用户可以通过手动选择合适的设备进行流转。用户点击图标后,会调起系统提供的流转面板。面板中心会展示出用户应用程序的信息及可流转的设备,引导用户进行后续的流转操作。
-
系统推荐流转
系统会通过分布式软总线自发的验证设备安全性,然后组网,组网之后就会去判断当前用户所处的环境中没有用户体验更佳的可选设备,如果存在这样的设备那么系统就会推荐用户进行流转。
元服务开发总体要求
-
免安装HAP包不能超过10MB
以提供快速响应的体验。超过此大小的HAP包不符合免安装要求,也无法再服务中心露出。
-
Project Type字段选择“Atomic Service”
HarmonyOS 2.0以上版本,通过DevEco Studio工程向导创建元服务。
-
保持免安装属性
对于元服务升级场景:版本更新时要保持免安装属性。如果新版本不支持免安装,将不允许新版本上架。
-
HAP包必须包含FA
如果某便捷服务的入口需要在服务中心露出,则该服务对应的HAP包必须包含FA,且FA中必须制定一个唯一的mainAbility(定位用户操作入口),mainAbility必须为PageAbility。
服务卡片定义
- 服务卡片(以下简称卡片)是FA的一种界面展示形式,将FA的重要信息或操作前置到卡片,以达到服务直达,减少体验层级的目的。
- 卡片常用于嵌入到其他应用(当前只支持系统应用)中作为其界面的一部分显示,并支持拉起页面,发送消息等基础的交互能力。