第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目录下生成了可烧录镜像

第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_RRSCHED_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的移植

在这里插入图片描述

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

第三方库移植

在这里插入图片描述
在这里插入图片描述

Logo

为开发者提供学习成长、分享交流、生态实践、资源工具等服务,帮助开发者快速成长。

更多推荐