【鸿蒙】HarmonyOS认证学习资料整理_一次开发多端部署的三个层次有哪些

第1章、HarmonyOS概述

概念
HarmonyOS是全场景分布式智慧系统。
HarmonyOS是一款面向万物互联时代、全新的分布式操作系统。

超级终端

功能机：软件整体升级不可分割，预装应用与操作系统绑定，有限功能
智能机：应用与操作系统分离，软件实现按需所得，但仍受硬件限制
超级终端：硬件通过网络连接，实现在逻辑上的一体，新的软硬件生态

HarmonyOS系统定位

一款面向万物互联的操作系统——每个人的IoT设备逐年增加。
构建全场景体验：
全场景——移动办公、运动健康、社交通信、媒体娱乐等
新硬件——软件定义硬件、设备间实现系统级融合、灵活按需适应不同场景
新交互——以人（手机）为中心、设备间主动感知、智能协同
新服务——服务直达、可分可合、跨设备按需流转（可分可合可流转）

HarmonyOS三大特性
硬件互助，资源共享——超级终端
一次开发，多端部署
统一OS，弹性部署

Harmony架构

横向纵向两个维度划分：
1、从上到下分4层：内核层、系统服务层、框架层、应用层
2、横向分3层：系统 ->（子系统集 ->）子系统 ->模块/功能（功能可裁剪）

内核层：
1、内核层分为2块：内核子系统和驱动子系统
2、多内核设计，通过KAL来适配对接多个内核，满足多种设备level的需求
3、目前支持三种内核：lieos_m、liteos_a、linux（分别为轻量、小型、（标准）、大型。可以扩展更多的内核，只需实现相应的KAL层适配），HCIA认证主要关心的是liteos_m内核

正确理解：硬件生态开放、统一外设访问能力、硬件驱动框架（HDF）的驱动开发框架、驱动管理框架

系统服务层：
1、根据不同设备形态的部署环境，各个子系统内部可以按照子系统颗粒度裁剪，每个子系统内部又可以按照功能粒度裁剪
2、系统服务层将OS底层能力封装成service，向上层应用提供service API
3、系统服务层是HarmonyOS的framework的核心部分（中间件）

框架层：
1、框架层的三个组成部分：应用程序框架、Ability框架、UI框架
2、三个框架都属于系统基本能力子系统集

应用层：
1、FA（feature ability，有UI界面，提供与用户交互能力）和PA（particle ability，无UI界面，提供后台运行任务能力）是应用的组成积木，就是HarmonyOS的原子化服务
2、FA在进行用户交互时所需的后台数据访问也需要由对应的PA提供支撑

应用服务智能分发
1、开发HarmonyOS应用，其实就是写需要的多个FA和PA
2、同一个PA/FA可以部署到多个不同设备中
3、同一个功能/模块，在不同的设备中可能需要设计不同的FA
4、开发应用时，要考虑好可能的场景和支持的设备，写好所有必要的FA和PA，打包成app
5、运行时根据实际参与超级终端的设备及其属性，智能分发必要的FA和PA（以hap包来分发，一个设备跑一个hap）
6、这就是HarmonyOS应用开发的所谓“一次开发、多端执行”的背后原理

HarmonyOS系统安全

在搭载HarmonyOS的分布式终端上，可以确保“正确的人，通过正确的设备，正确地使用数据”。

• 通过“分布式多端系统身份认证”来保证“正确的人”——协同互助认证（手机帮手环认证人脸识别）、零信任模型、多因素融合认证（不同设备标识同一用户的认证）
• 通过“在分布式终端上构建可信运行环境”来保证“正确的设备”——设备证书认证（证书中心发放证书，证书私钥预置到产线的设备中，保存到设备TEE环境中）、安全启动（确保程序完整未篡改）、（硬件）可信执行环境（TEE）
• 通过“分布式数据在跨终端流动的过程中，对数据进行分类分级管理”来保证“正确地使用数据”——围绕数据的生成、存储、使用、传输以及销毁过程进行全生命周期的保护

TEE环境
1、TEE, Trusted Execution Environment，即 可信执行环境
2、REE, Rich Execution Environment，即 所有移动设备通用的环境，运行通用的 OS
3、TEE需要硬件支持，不是纯软件能实现的
4、可以简单理解为整个系统由TEE和REE两部分组成（双系统），TEE是绝对安全的，REE只能通过受限API来访问TEE

PKI证书
1、通信中数据安全靠加密，加密分对称加密和非对称加密2大类
2、对称加密的密钥传输困难所以用得少，而非对称加密更实用
3、参考百度百科中"非对称加密"词条，来理解非对称加密原理，公钥和私钥概念
4、PKI，Public Key Infrastructure，公开密钥基础设施，指的是证书的制作和分发的一种机制。在这个机制的保障前提下，进行可信赖的网络通信。PKI的基础技术包括加密、数字签名、数据完整性机制、数字信封、双重数字签名等

HarmonyOS关键特性

硬件互助，资源共享——超级终端
一次开发，多端部署
统一OS，弹性部署

分布式技术
包括：分布式软总线、分布式数据管理、分布式文件管理、分布式任务调度、分布式设备虚拟化
分布式软总线：是基础，是底层通信机制（WIFI、BLE等）的软件包装和管理
分布式数据管理：业务与数据分离，跨设备产生、存储和使用数据和本地一样方便
分布式文件管理：跨设备文件访问和访问本地文件一样方便
分布式任务调度：跨设备对应用进行远程启动、远程调用、远程连接以及迁移
分布式数据管理、分布式文件管理、分布式任务调度，这三个是分布式在系统服务层的封装，都会调用到分布式软总线。
分布式设备虚拟化：是分布式在系统应用层从效果出发的描述

一次开发，多端部署

• 此处指的是HarmonyOS应用开发，不是南向设备固件开发
• 应用开发IDE提供相应模板和机制，便于app开发者开发场景式app
• HarmonyOS应用云市场提供相应签名、分发等机制，确保hap合理组织成app，再部署到独立设备中
• FA和PA保证了app的可分发可运行，分布式特性保证了跨设备和设备内一样的编程方法和使用体验
• 各独立设备运行HarmonyOS，保证了端侧hap的适配和执行

统一OS，弹性部署

• 此处说的是HarmonyOS设备开发，不是北向应用开发了
• HarmonyOS从源码结构、软件工具、业务流程等方面会提供支撑，让设备上弹性部署HarmonyOS
• 可裁剪性
  

第2章、设备开发入门

可能存在的考点
1、设备端开发语言，C/C++
2、开发环境：Windows+Linux（ubuntu），Windows做编辑、烧录；Linux做编译
3、环境搭建中安装的各个软件是干嘛的

4、设备开发流程几个步骤、顺序

5、设备开发的IDE是DevEco Device Tool，应用开发是DevEco Studio
6、DevEco Device Tool是基于VSCode的插件式设计

OpenHarmony目录结构

applications目录：

base目录：

foundation目录：

OpenHarmony分层接口

为什么需要标准接口
1、为了解耦，便于模块化
2、此处主要是讲OS kernel和应用之间的接口，标准接口是为了应用程序可移植性

CMSIS
1、Cortex Microcontroller Software Inteface Standard
2、ARM专为Cortex-M系列单片机设计的微控制器软件接口标准
3、CMSIS有多个分支，鸿蒙用的主要是CMSIS-RTOS，是RTOS API的CMSIS标准
4、CMSIS-RTOS是事实上的RTOS API行业标准，很多rtos都乐意去支持
目前HarmonyOS的liteOS-M、liteOS-A适用。

POSIX
1、Potable Operating System Interface 可移植操作系统接口
2、POSIX被linux、windows、android、HarmonyOS等众多主流OS所支持，历史悠久
3、POSIX是事实上的linux级别的OS的API标准
4、在POSIX兼容的kernel之间，移植app是比较简单的
目前harmonyOS的linux内核适用。

组件开发与hpm

组件开发思想的理解
1、为了模块化
2、bundle.json，组件包内容的程序化描述
3、README.md，组件说明文档
4、LICENSE，组件发布许可证
5、script，多个组件打包成发行版时使用的脚本

组件与发行版的异同对比

hpm概念
1、hpm，全称 HarmonyOS Package Manager
2、主要功能：获取源码、执行安装、编译、打包、升级操作

hpm操作命令

hpm init -t dist 				初始化安装目录
hpm install @ohos/wifi_iot		安装wifi_iot这个发行版	
hpm dist						编译打包并发行，结果是out目录下生成了可烧录镜像
1
2
3

第3章、内核基础

HarmonyOS的进程与线程

1、HarmonyOS采用抢占式内核设计。同时，同优先级的多个线程间采用时间片轮转调度。（这里讲的内核指的是liteos_a内核）
2、优先级范围0-31，共32个，数字越小优先级越高。内核进程范围是0-9（10个），用户进程范围是10-31（22个）
3、总结：liteos_a内核和linux内核非常像，显著差异就是liteos_a是抢占式，而linux是非抢占式

4、多核CPU，进程/线程，保护/防冲突用自旋锁。自旋锁是一种阻塞式设计。
5、负载均衡是为了提升效率，让多个任务在多个CPU核心之间尽量平均分配。

线程管理


HarmonyOS的线程采用抢占式调度机制。如果处于ready状态的多个任务不是一个优先级，直接抢占决策。如果是同一个优先级怎么办？有2种策略可选：SCHED_RR 和 SCHED_FIFO

对处于ready状态的同样优先级的任务。SCHED_RR是分配给每一个任务一个特定的时间片（默认是10ms），然后轮转依次运行（各线程分配10ms循环执行）。而SCHED_FIFO则是让一个任务运行完再调度下一个任务，而顺序就是依照创建的先后（FIFO先进先出，先的执行完后才能执行下一个）。

HarmonyOS线程常用的两种锁：互斥锁（共享-独占锁） 和 读写锁。

总结：
liteOS-M 和 liteOS-A 都是抢占式的，进程和线程都是抢占式的，而Linux是非抢占式的； liteOS-A 和
Linux 进程线程都有，而 liteOS-M只有线程；
多核CPU，进程/线程间，用自旋锁；
单CPU，单进程中的线程间，用互斥锁或读写锁；

HarmonyOS的内存、网络和文件系统

其他内核基础知识

第4章、驱动基础

HDF驱动模型

HDF驱动开发

驱动平台介绍

SPI总线协议及SPI时序图详解

时钟极性CPOL对传输协议没有重大的影响。如果CPOL=0，串行同步时钟的空闲状态为低电平；如果CPOL=1，串行同步时钟的空闲状态为高电平。时钟相位CPHA能够配置用于选择两种不同的传输协议之一进行数据传输。如果 CPHA=0，在串行同步时钟的第一个跳变沿(上升或下降)数据被采样；如果CPHA=1，在串行同步时钟的第二个跳变沿(上升或下降)数据被采样。

CPOL和CPHA的两个设置可以从时钟信号的图来看，CPOL的值与时钟信号初始值一致，CPHA=0第一个跳边沿（时钟前沿）采集，CPHA=1第二个跳边沿（时钟后沿）采集。

RTC的晶振频率是32.768KHz


例子：
编码值（譬如8位） 电压值 物理量值（譬如温度值）
范围0-255 0-3.3V 0-33度
解题思路：搞清楚物理量、电压值、编码值三者之间的2个对应关系。剩下的其实就是按比例算
出题1：编码值是11011011，问是多少度？ 1316+11=219，x=33(219/256)=28度
出题2：已知是15度，问编码值是多少？ 15/33=x/256，x=116，再把116换算成二进制值（思路：十进制先转十六进制，再转二进制。116 = 0x74 = 0b01110100）

第5章、基础子系统开发

HarmonyOS的编译构建子系统

gn和ninja
传统GNU开发工具：写Makefile管理工程，用make工具来构建。
改进版：因为makefile手写很难，就有了cmake，改进成了写camke的list文件，用cmake工具将其转为Makefile，再用make进行构建。
鸿蒙的再改进版（来自于google）：用gn来替代cmake，用ninja来替代Makefile。开发者写gn配置文件就行了，语法简单。

编译构建过程
鸿蒙的hb
(1)hb是鸿蒙专为build开发的一个工具软件，hb其实就是harmonyos build的缩写
(2)hb的用法是hb cmd arg，有多个cmd
(3)hb set 命令从来设置编译的鸿蒙源码目录
(4)hb build -f 命令用来编译构建选中的开发板

HarmonyOS的分布式远程启动

HarmonyOS的公共基础与OTA升级

公共基础库：
通用的操作可以直接调用现成的库函数，包括文件操作、数据库操作等。避免“重复造轮子”。
由鸿蒙开发者实现公共基础库，设备应用开发者拿来即用。

HarmonyOS的启动恢复

HarmonyOS的软总线

第6章、扩展子系统开发

HarmonyOS的图形图像媒体子系统

HarmonyOS的AI框架和Sensor框架与用户程序框架

HarmonyOS的剩余几个框架

安全框架


测试框架

DFX框架


XTS框架

第7章、功能调测

HarmonyOS的shell命令

接下来重新编译内核，
make clean;
make;
再使用help即可查看所有已注册的命令。

动态注册基本一致，需要注意的是：1、动态注册的函数写在应用程序中；2、动态注册函数入参不需要静态注册时的第一个参数（全局变量名），因此也不需要在mk文件中添加编译选项；3、因为是liteos-m内核，应用和内核是编在一起的，因此不管是静态还是动态，都需要重新编译。

HarmonyOS自带的shell命令

第8章、HarmonyOS的移植

第三方库移植