鸿蒙系统深度解读（一）

avatar
@海尔优家智能科技（北京）有限公司

《鸿蒙系统深度解读》系列文章中，我们将针对鸿蒙系统分享基础知识、应用实例、前端JS/eTS部分、鸿蒙系统带给我们的思考、我们如何做这几部分内容。

1 鸿蒙和Android系统对比

1.1 系统特点

iHaier20230118-171015.png 「 单点系统痛点 」

  • 传统设备单点独立运行，还停留在功能机
  • 硬件设备彼此独立无法共享能力
  • 应用服务无法设备间自由切换

「 鸿蒙系统意义」

  • 分布式架构首次应用在终端
  • 软件服务不再受限于单硬件设备，服务能力通过不同设备得到扩展
  • 场景，终端发生变化不会导致服务中断
  • 对用户而言带来更加沉浸式极致体验
  • 对华为而言争夺物联网市场，占得发展先机
  • 突破国外技术封锁

1.2 底层内核

「 相同点 」

安卓和鸿蒙系统都是基于安卓开源项目 AOSP（Android Open Source Project）进行开发的，在鸿蒙系统上可以安装运行安卓apk。

「 不同点 」

安卓系统是基于 Linux 宏内核设计，鸿蒙系统基于微内核，包括 Linux 内核（手机操作系统内核）和 LiteOS 内核（智能硬件内核）

2 Openharmony 和 HarmonyOS区别

「 开源情况 」

OpenHarmony 是鸿蒙的基础能力，是开源的，OpenHarmony2.0去除了 AOSP 所以只支持 hap 文件安装运行，不支持 apk 安装运行。

HarmonyOS 是华为手机鸿蒙系统，基于 OpenHarmony 开发，不是开源的，支持 AOSP，可以兼容安卓apk安装运行。

OpenHarmony开源地址：gitee.com/openharmony ，不是 github.com/Awesome-Har… 。

Openharmony 和 HarmonyOS 的关系： iHaier20230118-171048.png 「 UI 框架 」

HarmonyOS 有两种 UI 框架，即方舟开发框架 ArkUI 和兼容 Android UI 框架（可以理解为 HarmonyOS = 兼容 Android + ArkUI）。方舟开发框架 ArkUI 采用 JS(eTS) 开发，兼容 Android UI 框架使用 Java 开发。

而 OpenHarmony 只有方舟开发框架 ArkUI 部分通过 JS 和 eTS 开发，不能使用 Java 进行开发。项目目录结构有区别，没有 Java 相关。

系统间关系：

iHaier20230118-171123.png

3 鸿蒙系统的应用场景

iHaier20230118-171200.png

3.1 应用场景1

  • 回家后手机上播放的音乐可以唤起电视/智能音响/ipad/智能音响等设备
  • 不间断不暂停继续从当前位置播放该音乐
  • 用手机来控制其他设备播放/暂停/快进等遥控功能 「 特点 」
  • 场景服务可在设备间无间断流转、协同处理
  • 数据在设备间流转不丢失
  • 远程控制

「 技术点 」

  • 基于分布式软总线跨端唤起FA
  • 将当前播放音乐信息数据传送到其他端体现出软总线可以传输基本类型
  • 分布式任务调度，通过 id 方式实现跨设备跨进程方法级调用实现手机来控制其他设备播放暂停/快进下一首等遥控功能

3.2 应用场景2

智家智能空调小U坏了不能呼叫搜索音乐，可以使用手机输入法作为智能空调（音响/电视/冰箱/冰箱）的文字输入设备，完成搜索（底层调用小U的搜索功能）。

「 特点 」

硬件互助，能力共享。

「 技术点 」

  • 分布式软总线作为技术通信能力，可以完成手机输入内容传输到其他设备
  • 也可以通过分布式数据库方式来实现，KV 类型数据传输，通过注册事件在别的设备监听手机输入文本变化
  • 官网例子使用分布式任务调度 RPC，序列化对象来做文本传输

3.3 应用场景3

冰箱/空调上需要采集照片，可以使用手机/PAD/相机上的照片或者作为照片采集设备。

「 特点 」

硬件互助，资源共享。

「 技术点 」

  • 相片等大对象传输，使用分布式任务调度 RPC 来跨进程跨端
  • 跨设备调用相机摄像头能力，通过任务调度 id 技术实现方法级别调用

3.4 应用场景4

晚上智能手表感知到用户已经入睡，自动调节空调进入睡眠静音模式，同时关闭客厅电视。

「 特点 」

自动感知，主动作为，真正实现智能智慧。

「 技术点 」

  • 智能手表通过传感器能力感知用户状态
  • 通过分布式软总线输入命令给空调进入睡眠模式，客厅电视关闭

3.5 应用场景5

智能手表/手机作为冰箱数据采集源，采集用户每天运动量、生活工作状态指标参数。到家后根据采用的数据制定科学的食谱到冰箱食谱推荐页。

「 特点 」

  • 补充了传统家电只能在家里的不足
  • 给用户提供更加科学准确合理的食谱

「 技术点 」

  • 通过智能手表/手机传感器能力，采集用户运动量、作息时间等，结合当前季节、温湿度等作为数据信息
  • 通过分布式总线/分布式任务调度等技术将采集数据发送到冰箱端
  • 冰箱采集到数据后可通过服务端进行大数据分析，最终给出一个科学合理的食谱推荐给用户

3.6 应用场景6

其他例子如，海尔洗衣机洗完衣服主动通过手机/智能手表等通知用户洗衣完成。

4 鸿蒙系统硬件互助，资源共享如何实现?

硬件互助、资源共享是鸿蒙最大的特点，关键技术包括：

  • 分布式软总线

  • 分布式设备虚拟化

  • 分布式数据管理

  • 分布式任务调度

  • 分布式连接能力

5 研究鸿蒙系统涉及哪些技术原理？

从技术上讲，鸿蒙系统硬件互助资源共享，背后涉及分布式系统相关概念：分布式、事务、本地事务、分布式事务、CAP/Base理论、强一致性/弱一致性/最终一致性、RPC、分布式任务调度。

前端：Flex布局、跨端方案 vue/flutter、mvvm 对象观察、模板渲染过程（模板语法 —> 抽象语法树—> 渲染函数(h函数) —> 虚拟节点Vdom —> diff/patch —> 真实节点Dom）、 三棵树原则、JS 引擎、线程模型等理论。

6 分布式软总线

「 软总线技术的特点 」

软总线技术最大特点是不同协议的异构网络进行组网。传统场景下，需要蓝牙传输的两台设备必须都具有蓝牙，需要WiFi传输的设备必须都具有WiFi。而蓝牙/WiFi之间是无法进行数据通信的。软总线提出蓝牙/WiFi融合网络组网技术（架构如下图所示），解决了不同协议设备进行数据通信的问题，使得多个鸿蒙设备能够自动构建一个逻辑全连接网络，用户或者业务开发者无需关心组网方式与物理协议，只需聚焦于业务逻辑的实现，无需关注组网方式与底层协议。

软总线模块实现的能力有：

  • 服务发布
  • 数据传输
  • 安全通信

「 软总线技术的实现协议 」

分布式软总线是基于开源 COAP(Constrained Application Protocol)协议，C语言实现的，属于一种底层基于 UDP 的应用层协议。鸿蒙使用 COAP 协议因为考虑到运行 harmonyOS 的设备除了硬件性能较好的手机、电脑等设备外，还有资源受限的物联网设备，这些设备的 ram、rom 相对较小。COAP 协议支持轻量的可靠传输，采用 COAP 协议，可以扩大组网的范围。

代码路径：code-v3.2-Beta1\OpenHarmony\foundation\communication\dsoftbus\components\nstackx_mini\nstackx_ctrl\include\coap_discover\coap_def.h

「 软总线技术的作用 」

软总线屏蔽了各种设备底层协议的差异，如不同设备支持 WIFI、蓝牙、USB、BT、NFC 等协议无法互通，但通过软总线可以使支持不同协议的设备互通，使得应用层不用在关心设备的底层协议。

注：真机实测需要不同设备登录同一华为账号，设置-超级终端-允许附近设备发现我，同时在同一局域网或蓝牙。远程模拟器不需要登录同一华为账号，默认在一个局域网。

分布式软总线架构示意图如下：

iHaier20230118-171253.png

根据软总线示意图得出如下几点结论：

  1. 协议栈和软硬协同层屏蔽各种硬件设备协议差异。
  2. 总线中枢负责解析命令，完成设备间发现与连接，基于 COAP 协议的设备发现功能。
  3. 安全模块负责通信的加解密；设备认证模块通过交换主控设备与配件设备的身份标识来建立点对点信任关系，设备认证模块关键技术点：HiChain机制数据接收管理、PAKE协议、STS协议流程。
  4. 提供统一的基于 Session 的认证、传输功能，上层业务系统可以通过 sessionId 收发数据或获取其相关基本属性，实现业务消息、流、控制指令等操作交互。
  5. 软总线代码路径：code-v3.2-Beta1\OpenHarmony\foundation\communication\dsoftbus\core，

  • discovery模块：提供基于 COAP 协议的设备发现机制；

  • connection模块：提供基于 COAP 协议的设备连接机制；

  • authentication模块：提供设备认证机制和知识库管理功能；

  • transmission：模块基于系统内核提供的socket通信，向 authmanager 模块提供设备认证通道管理和设备认证数据的传输；向业务模块提供 session 管理和基于 session 的数据收发功能，并且通过 GCM 模块的加密功能提供收发报文的加解密保护；

  • adapter：操作系统适配层。

    参考链接1，参考链接2

  • 需要注意的是，软总线启动后，设备在发现阶段基于 COAP 协议使用 UDP 数据报进行通讯。当设备认证通过，确认连接后，将会使用 TCP 协议进行更加安全可靠的通讯。

「 基于分布式软总线设备间交互过程 」
iHaier20230118-171324.png 具体过程：

  1. 发现端（如手机端）在广播发起 discover 请求后，使用 COAP 协议在局域网内发送广播 ；
  2. 被发现端（智能设备端）设备使用 PublishService 接口发布服务，接收端收到广播后，发送 COAP 协议单播给发现端；
  3. 发现端设备收到报文会更新设备信息建立连接。

7 分布式数据管理

「 数据管理方式 」

鸿蒙系统数据管理有三种方式：

  • 关系型数据库 SQLite 及 ORM
  • 轻量级数据存储 Preferences
  • 分布式数据库支持 KV 数据模型，是一种 NoSQL 类型数据库

「 相关概念 」

  • 事务
  • 本地事务
  • 分布式事务（不在一个JVM）
  • mysql 主从同步读写分离分库分表
  • CAP理论
  • dubbo
  • rocketmq
  • seata方案

「 事务 」

分布式数据库事务支持本地事务（和传统的数据库事务概念一致）和同步事务。同步事务是指在设备之间同步数据时，以本地事务为单位进行同步，一次本地事务的修改要么都同步成功，要么都同步失败。

「 CAP理论 」

CAP理论指的是在一个分布式系统中，Consistency(一致性)、Availability(可用性)、Partition Tolerance(分区容错性)，不能同时成立。

根据分布式系统CAP理论需满足数据一致性。在分布式场景中一般会涉及多个设备，组网内设备之间看到的数据是否一致称为分布式数据库的一致性。分布式数据库一致性可以分为强一致性、弱一致性和最终一致性。鸿蒙实现最终一致性即满足AP。

「 数据同步方式 」

分布式数据服务提供了两种同步方式：手动同步和自动同步。

  • 手动同步： 由应用程序调用 sync 接口来触发，需要指定同步的设备列表和同步模式。同步模式分为 PULL_ONLY（将远端数据拉到本端）、PUSH_ONLY（将本端数据推送到远端）和 PUSH_PULL（将本端数据推送到远端同时也将远端数据拉取到本端）。
  • 自动同步： 由分布式数据库自动将本端数据推送到远端，同时也将远端数据拉取到本端来完成数据同步，同步时机包括设备上线、应用程序更新数据等，应用不需要主动调用 sync 接口。

「 分布式数据管理 」

分布式数据管理基于分布式软总线的能力，实现应用程序数据和用户数据的分布式管理。用户数据不再与单一物理设备绑定，业务逻辑与数据存储分离。通过分布式数据管理使得数据实时同步到不同设备，该过程不需要业务逻辑参与实现。

分布式数据同步过程如下：

iHaier20230118-171408.png

「 分布式数据最终一致性 」

由鸿蒙系统层实现数据最终一致性，应用层只需要使用其一致性接口即可，参考下面数据库相关项目案例。

8 分布式任务调度

分布式任务调度基于分布式软总线、分布式数据管理等技术特性，构建统一的分布式服务管理（发现、同步、注册、调用）机制，支持对跨设备的应用进行远程启动、远程调用、远程连接以及迁移等操作，能够根据不同设备的能力选择合适的设备运行分布式任务。

分布式任务调度示意图如下:

iHaier20230118-171459.png

通过分布式任务调度可以实现跨端分布式计算，解决不同终端算力问题，实现硬件互助。

跨端分布式算力示意图如下：

iHaier20230118-171526.png

如图分布式任务调度，有如下特点：

  • 允许多个 HarmonyOS 设备协同计算和资源分担以及实时的任务调度
  • 能随时方便的发现和启用周边闲置的设备
  • 将周边的设备组建成算力和差异化功能的资源池
  • 为用户的高体验应用提供随需算力和特定能力的分布式卸载和协同能力
  • 组合成能胜任各种新业务场景需求的超级终端

分布式调度协议：服务端开发常见的分布式调度 RPC 协议有阿里开源 dubbo、京东杰夫 JSF 协议。HarmonyOS 分布式系统采用的极简D2D传输协议栈，(可以理解为鸿蒙实现的私有通信 RPC 协议)，相较于传统协议栈做了许多简化处理，包括压缩协议封装、增加协议处理的硬件亲和性，通过智能预测配合节电机制做预热处理，避免冷启动等。获得5-10倍的压缩数据同步传输速度提升，实现亚毫秒级的无线通信时延。

极减协议 D2D 和传统 TCP 比较如下：

iHaier20230118-171526.png

采用 D2D 协议相较传统的 TCP 协议，优点如下 ：

缩短协议路径： 精简协议处理流程，软件处理时延减少50%

减少线程调度： 减少收发侧线程调度，线程调度时延减少55%

芯片按需预热： 感知设备与业务状态，芯片处理时延减少80%。

进一步学习参考:forum.gitlink.org.cn/forums/7218…

9 鸿蒙与Android基础组件对比

鸿蒙Android
AbilityActivity
AbilitySliceFragment
ComponentView
ComponentContainerViewGroup
AbilityPackageApplication
IntentIntent
config.jsonManifeast.xml
FA/PAActivity/Service
SQLite/SharePreference/ORMSQLite/SharePreference/ORM
公共事件广播机制
EventHandlerHandler
EventRunnerLooper机制
idlaidl
原子化服务/服务卡片小程序/快捷键
avatar
文章
阅读
粉丝