💧 重要知识点

OpenHarmony操作系统

OpenHarmony操作系统基础概述

OpenHarmony是由开放原子开源基金会（OpenAtom Foundation）孵化及运营的开源项目，目标是面向全场景、全连接、全智能时代，基于开源的方式，搭建一个智能终端设备操作系统的框架和平台，促进万物互联产业的繁荣发展。

技术架构

OpenHarmony整体遵从分层设计，从下向上依次为：内核层、系统服务层、框架层和应用层。系统功能按照“系统 > 子系统 > 组件”逐级展开，在多设备部署场景下，支持根据实际需求裁剪某些非必要的组件。OpenHarmony技术架构如下所示：

内核层

• 内核子系统：采用多内核（Linux内核或者LiteOS）设计，支持针对不同资源受限设备选用适合的OS内核。内核抽象层（KAL，Kernel Abstract Layer）通过屏蔽多内核差异，对上层提供基础的内核能力，包括进程/线程管理、内存管理、文件系统、网络管理和外设管理等。

• 驱动子系统：驱动框架（HDF）是系统硬件生态开放的基础，提供统一外设访问能力和驱动开发、管理框架。

系统服务层

系统服务层是OpenHarmony的核心能力集合，通过框架层对应用程序提供服务。该层包含以下几个部分：

• 系统基本能力子系统集：为分布式应用在多设备上的运行、调度、迁移等操作提供了基础能力，由分布式软总线、分布式数据管理、分布式任务调度、公共基础库、多模输入、图形、安全、AI等子系统组成。

• 基础软件服务子系统集：提供公共的、通用的软件服务，由事件通知、电话、多媒体、DFX（Design For X） 等子系统组成。

• 增强软件服务子系统集：提供针对不同设备的、差异化的能力增强型软件服务，由智慧屏专有业务、穿戴专有业务、IoT专有业务等子系统组成。

• 硬件服务子系统集：提供硬件服务，由位置服务、用户IAM、穿戴专有硬件服务、IoT专有硬件服务等子系统组成。

根据不同设备形态的部署环境，基础软件服务子系统集、增强软件服务子系统集、硬件服务子系统集内部可以按子系统粒度裁剪，每个子系统内部又可以按功能粒度裁剪。

框架层

框架层为应用开发提供了C/C++/JS等多语言的用户程序框架和Ability框架，适用于JS语言的ArkUI框架，以及各种软硬件服务对外开放的多语言框架API。根据系统的组件化裁剪程度，设备支持的API也会有所不同。

应用层

应用层包括系统应用和第三方非系统应用。应用由一个或多个FA（Feature Ability）或PA（Particle Ability）组成。其中，FA有UI界面，提供与用户交互的能力；而PA无UI界面，提供后台运行任务的能力以及统一的数据访问抽象。基于FA/PA开发的应用，能够实现特定的业务功能，支持跨设备调度与分发，为用户提供一致、高效的应用体验。

系统类型（考点）

OpenHarmony支持如下几种系统类型：

• 轻量系统（mini system）
面向MCU类处理器例如Arm Cortex-M、RISC-V 32位的设备，硬件资源极其有限，支持的设备最小内存为128KiB，可以提供多种轻量级网络协议，轻量级的图形框架，以及丰富的IOT总线读写部件等。可支撑的产品如智能家居领域的连接类模组、传感器设备、穿戴类设备等。

• 小型系统（small system）
面向应用处理器例如Arm Cortex-A的设备，支持的设备最小内存为1MiB，可以提供更高的安全能力、标准的图形框架、视频编解码的多媒体能力。可支撑的产品如智能家居领域的IP Camera、电子猫眼、路由器以及智慧出行域的行车记录仪等。

• 标准系统（standard system）（考点）
面向应用处理器例如Arm Cortex-A的设备，支持的设备最小内存为128MiB，可以提供增强的交互能力、3D GPU以及硬件合成能力、更多控件以及动效更丰富的图形能力、完整的应用框架。可支撑的产品如高端的冰箱显示屏。

基本概念

• 子系统
OpenHarmony整体遵从分层设计，从下向上依次为：内核层、系统服务层、框架层和应用层。系统功能按照“系统 > 子系统 > 组件”逐级展开，在多设备部署场景下，支持根据实际需求裁剪某些非必要的组件。子系统是一个逻辑概念，它具体由对应的组件构成。

• 组件
对子系统的进一步拆分，可复用的软件单元，它包含源码、配置文件、资源文件和编译脚本；能独立构建，以二进制方式集成，具备独立验证能力的二进制单元。

OpenHarmony系统启动流程（待补充）（考点）

内核

操作系统是位于应用和硬件之间的系统软件，向上提供易用的程序接口和运行环境，向下管理硬件资源。内核位于操作系统的下层，为操作系统上层的程序框架提供硬件资源的并发管理。

重要组成单元

• 负责持久化数据，并让应用程序能够方便的访问持久化数据的“文件系统”。

• 负责管理进程地址空间的“内存管理”。

• 负责管理多个进程的“进程管理”或者“任务管理“。

• 负责本机操作系统和另外一个设备上操作系统通信的“网络”。

内核构成（考点）

OpenHarmony采用了多内核结构，支持Linux和LiteOS，开发者可按不同产品规格进行选择使用。Linux和LiteOS均具备上述组成单元，只是实现方式有所不同。多个内核通过KAL（Kernel Abstraction Layer）模块，向上提供统一的标准接口。

OpenHarmony针对不同量级的系统，使用了不同形态的内核。轻量系统、小型系统可以选用LiteOS；小型系统和标准系统可以选用Linux。其对应关系如下表：

系统级别	轻量系统	小型系统	标准系统
LiteOS-M	√	×	×
LiteOS-A	×	√	×
Linux	×	√	√

LiteOS-M（考点）

LiteOS-A

• 新增了丰富的内核机制：
• 新增虚拟内存、系统调用、多核、轻量级IPC（Inter-Process Communication，进程间通信）、DAC（Discretionary Access Control，自主访问控制）等机制，丰富了内核能力；
• 为了更好的兼容软件和开发者体验，新增支持多进程，使得应用之间内存隔离、相互不影响，提升系统的健壮性。

• 引入统一驱动框架HDF（Hardware Driver Foundation）
引入统一驱动框架HDF，统一驱动标准，为设备厂商提供了更统一的接入方式，使驱动更加容易移植，力求做到一次开发，多系统部署。

• 支持1200+标准POSIX接口
更加全面的支持POSIX标准接口，使得应用软件易于开发和移植，给应用开发者提供了更友好的开发体验。

• 内核和硬件高解耦
轻量级内核与硬件高度解耦，新增单板，内核代码不用修改。

Linux

OpenHarmony的Linux内核基于开源Linux内核LTS 4.19.y / 5.10.y 分支演进，在此基线基础上，回合CVE补丁及OpenHarmony特性，作为OpenHarmony Common Kernel基线。针对不同的芯片，各厂商合入对应的板级驱动补丁，完成对OpenHarmony的基线适配。

 

编译构建

OpenHarmony编译子系统是以GN和Ninja构建为基座，对构建和配置粒度进行部件化抽象、对内建模块进行功能增强、对业务模块进行功能扩展的系统，该系统提供以下基本功能：

• 以部件为最小粒度拼装产品和独立编译。

• 支持轻量、小型、标准三种系统的解决方案级版本构建，以及用于支撑应用开发者使用IDE开发的SDK开发套件的构建。

• 支持芯片解决方案厂商的灵活定制和独立编译。

基本概念

• 平台：开发板和内核的组合，不同平台支持的子系统和部件不同。

• 产品：产品是包含一系列部件的集合，编译后产品的镜像包可以运行在不同的开发板上。

• 子系统：OpenHarmony整体遵从分层设计，从下向上依次为：内核层、系统服务层、框架层和应用层（详见OpenHarmony技术架构）。系统功能按照“系统 > 子系统 > 部件”逐级展开，在多设备部署场景下，支持根据实际需求裁剪某些非必要的子系统或部件。子系统是一个逻辑概念，它具体由对应的部件构成。

• 部件：对子系统的进一步拆分，可复用的软件单元，它包含源码、配置文件、资源文件和编译脚本；能独立构建，以二进制方式集成，具备独立验证能力的二进制单元。需要注意的是下文中的芯片解决方案本质是一种特殊的部件。

• 模块：模块就是编译子系统的一个编译目标，部件也可以是编译目标。

• 特性：特性是部件用于体现不同产品之间的差异。

• GN：Generate Ninja的缩写，用于产生Ninja文件。

• Ninja：Ninja是一个专注于速度的小型构建系统。

• hb：OpenHarmony的命令行工具，用来执行编译命令。

编译构建流程

OpenHarmony执行编译命令的命令行工具——hb方式（考点）

1. hb set: 设置要编译的产品。

2. hb env: 查看当前设置信息。

3. hb build: 编译产品、开发板、部件、模块或芯片解决方案。

4. hb clean: 清除out目录对应产品的编译产物，仅保留args.gn、build.log。

5. hb help: 主要用于获取帮助信息和相关标记的说明。

DevEco Studio

子系统

分布式软总线子系统

分布式软总线子系统旨在为OpenHarmony系统提供的通信相关的能力，包括：WLAN服务能力、蓝牙服务能力、软总线、进程间通信RPC（Remote Procedure Call）等通信能力。

系统架构

提供的服务

• WLAN服务：为用户提供WLAN基础功能、P2P（peer-to-peer）功能和WLAN消息通知的相应服务，让应用可以通过WLAN和其他设备互联互通。

• 蓝牙服务：为应用提供传统蓝牙以及低功耗蓝牙相关功能和服务。

• 软总线：为应用和系统提供近场设备间分布式通信的能力，提供不区分通信方式的设备发现，连接，组网和传输功能。（组网限制：必须确保设备在同一个局域网中）

• 进程间通信：提供不区分设备内或设备间的进程间通信能力。

主要功能

• 发现连接：提供基于Wifi、蓝牙等通信方式的设备发现连接能力。

• 设备组网：提供统一的设备组网和拓扑管理能力，为数据传输提供已组网设备信息。

• 数据传输：提供数据传输通道，支持消息、字节、流、文件的数据传输能力。

约束

• 组网设备需在同一局域网中 或者 距离相近的近场设备间。

• 组网之前，需先完成设备绑定，绑定流程参见安全子系统中说明。

• 传输完成数据收发之后，业务要主动关闭会话，释放资源。

 

应用模型

ArkTS

通知

用户通知服务（考点）！！！！！！

HarmonyOS通过ANS（Advanced Notification Service，通知系统服务）对通知类型的消息进行管理，支持多种通知类型，如基础类型通知、进度条类型通知。

Notification Kit（用户通知服务）

Notification Kit（用户通知服务）为开发者提供本地通知发布通道，开发者可借助Notification Kit将应用产生的通知直接在客户端本地推送给用户，本地通知根据通知类型及发布场景会产生对应的铃声、震动、横幅、锁屏、息屏、通知栏提醒和显示。

• 前台：使用Notification Kit向用户发布通知。

• 后台：接入Push Kit进行云侧离线通知的发布。

通知业务流程（考点）

通知业务流程由通知子系统、通知发送端、通知订阅端组成。一条通知从通知发送端产生，通过IPC通信发送到通知子系统，再由通知子系统分发给通知订阅端。

• 通知发送端：可以是三方应用或系统应用。开发者重点关注。

• 通知订阅端：只能为系统应用，比如通知中心。通知中心默认会订阅手机上所有应用对当前用户的通知。开发者无需关注。

• 通知发送端调用AnsNotification校验参数合法性。（考点）

能力范围（考点）

• 发布文本、进度条等类型通知。

• 携带或更新应用通知数字角标。

• 取消曾经发布的某条或全部通知。

• 查询已发布的通知列表。

• 查询应用自身通知开关状态。

• 应用通知用户的能力默认关闭，开发者可拉起授权框，请求用户授权发布通知。

发布通知（考点）

通知发布接口如下表所示，不同发布类型通知由NotificationRequest的字段携带不同的信息。

接口名	描述
publish(request: NotificationRequest, callback: AsyncCallback<void>): void	发布通知。
cancel(id: number, label: string, callback: AsyncCallback<void>): void	取消指定的通知。
cancelAll(callback: AsyncCallback<void>): void;	取消所有该应用发布的通知。

约束限制（考点）

• 单个应用已发布的通知在通知中心等系统入口的留存数量有限（当前规格最多24条）。（考点）

• 通知的长度不能超过200KB（跨进程序列化大小限制）。

• 系统所有应用发布新通知的频次累计不能超过每秒10条，更新通知的频次累计不能超过每秒20条。

相关Kit（考点）

• Notification Kit创建的通知会即时显示在通知中心等系统入口，如果开发者希望在应用退到后台或进程终止后仍然有一些提醒用户的定时类通知，例如购物类应用抢购提醒等，可通过BackGroundTask Kit创建，目前支持基于倒计时、日历、闹钟等类型的通知提醒功能。

• 开发者可通过Ability Kit设置用户点击通知后的行为意图。（考点）

• 开发者可通过Push Kit远程推送用户通知到本地。

请求通知授权

接口名	描述
isNotificationEnabled():Promise<boolean>	查询通知是否授权。
requestEnableNotification(context: UIAbilityContext): Promise<void>	请求发送通知的许可，第一次调用会弹窗让用户选择。（后续再次调用时，则不再弹窗）

管理通知角标

当角标设定个数取值0时，表示清除角标。取值大于99时，通知角标将显示99+。

• 增加角标数，支持如下两种方法：
• 发布通知时，在NotificationRequest的badgeNumber字段里携带，桌面收到通知后，在原角标数上累加、呈现。
• 调用接口setBadgeNumber()设置，桌面按设置的角标数呈现。

• 减少角标数，目前仅支持通过setBadgeNumber()设置。

接口名	描述
setBadgeNumber(badgeNumber: number, callback: AsyncCallback<void>): void	设置角标个数。

管理通知渠道（考点）

接口名	描述
addSlot(type: SlotType): Promise<void>	创建指定类型的通知渠道。
getSlot(slotType: SlotType): Promise<NotificationSlot>	获取一个指定类型的通知渠道。
removeSlot(slotType: SlotType): Promise<void>	删除此应用程序指定类型的通知渠道。

媒体

传感器

HarmonyOS传感器

HarmonyOS传感器包含如下四个模块：Sensor API、Sensor Framework、Sensor Service和HDF层。

• Sensor API：提供传感器的基础API，主要包含查询传感器列表，订阅/取消传感器的数据、执行控制命令等，简化应用开发。

• Sensor Framework：主要实现传感器的订阅管理，数据通道的创建、销毁、订阅与取消订阅，实现与SensorService的通信。

• Sensor Service：主要实现HD_IDL层数据接收、解析、分发，前后台的策略管控，对该设备Sensor的管理，Sensor权限管控等。

• HDF层：对不同Sensor的数据采集方式【如FIFO】和采集频率进行策略选择，以及适配不同设备。

普通传感器调用

权限配置：如果设备上使用了传感器权限列表中的传感器，需要请求相应的权限，开发者才能获取到传感器数据。

• 开发者需要在module.json5里面配置权限。

注册监听：

• 通过on（）接口，实现对传感器的持续监听

• 通过once（）接口，实现对传感器的一次监听

媒体

媒体系统提供用户视觉、听觉信息的处理能力，如音视频信息的采集、压缩存储、解压播放等。在操作系统实现中，通常基于不同的媒体信息处理内容，将媒体划分为不同的模块，包括：音频、视频（也称播放录制）、图片等。

架构

AVPlayer——音频播放

 

AVPlayer——视频播放

 

AVPlayer——音频格式

 

AVPlayer——视频格式

AVRecorder支持的输出格式

音频播放

播放的全流程包含：创建AVPlayer，设置播放资源，设置播放参数（音量/倍速/焦点模式），播放控制（播放/暂停/跳转/停止），重置，销毁资源。

在进行应用开发的过程中，开发者可以通过AVPlayer的state属性主动获取当前状态或使用on('stateChange')方法监听状态变化。

音视频播控服务（5.0新版里才有）

AVSession Kit（Audio & Video Session Kit，音视频播控服务）是系统提供的音视频管控服务，用于统一管理系统中所有音视频行为，帮助开发者快速构建音视频统一展示和控制能力。

• 提供音视频统一管控能力，音视频类应用接入AVSession后，可以发送应用的数据（比如正在播放的歌曲、歌曲的播放状态等），用户可以通过系统播控中心、语音助手等应用切换多个应用、多个设备播放。

• 提供音频后台约束能力，音频接入AVSession后，可以进行后台音频播放。此功能需要同时申请后台任务。

安全

ATM应用权限管理

ATM (AccessTokenManager) 是HarmonyOS上基于AccessToken构建的统一的应用权限管理能力,基于统一管理的TokenID（Token identity，即每个应用的身份标识）提供应用权限校验功能。

应用权限保护的对象可以分为数据和功能：

• 数据包含了个人数据（如照片、通讯录、日历、位置等）、设备数据（如设备标识、相机、麦克风等）、应用数据。

• 功能则包括了设备功能（如打电话、发短信、联网等）、应用功能（如弹出悬浮框、创建快捷方式等）等。

权限使用的基本原则（和我们当前进行权限申请是一样的）

• 应用申请的权限，都必须有明确、合理的使用场景和功能说明，确保用户能够清晰明了地知道申请权限的目的、场景、用途；禁止诱导、误导用户授权；应用使用权限必须与申请所述一致。

• 应用权限申请遵循最小化原则，只申请业务功能所必要的权限，禁止申请不必要的权限。

• 应用在首次启动时，避免频繁弹窗申请多个权限；权限须在用户使用对应业务功能时动态申请。

• 用户拒绝授予某个权限时，与此权限无关的其他业务功能应能正常使用，不能影响应用的正常注册或登录。

• 业务功能所需要的权限被用户拒绝且禁止后不再提示，当用户主动触发使用此业务功能或为实现业务功能所必须时，应用程序可通过界面内文字引导，让用户主动到“系统设置”中授权。

• 当前不允许应用自行定义权限，应用申请的权限应该从已有的权限列表中选择。

权限的工作流程（申请）

权限校验的工作流程（使用）

应用APL等级（应用权限优先级，应用默认为normal）

元能力权限等级APL（Ability Privilege Level）指的是应用的权限申请优先级的定义，不同APL等级的应用能够申请的权限等级不同。

APL级别	说明
system_core等级	该等级的应用服务提供操作系统核心能力。
system_basic等级	该等级的应用服务提供系统基础服务。
normal等级	普通应用。

• normal权限
normal 权限允许应用访问超出默认规则外的普通系统资源。这些系统资源的开放（包括数据和功能）对用户隐私以及其他应用带来的风险很小。
该类型的权限仅向APL等级为normal及以上的应用开放。

• system_basic权限
system_basic权限允许应用访问操作系统基础服务相关的资源。这部分系统基础服务属于系统提供或者预置的基础功能，比如系统设置、身份认证等。这些系统资源的开放对用户隐私以及其他应用带来的风险较大。
该类型的权限仅向APL等级为system_basic及以上的应用开放。

• system_core权限
system_core权限涉及到开放操作系统核心资源的访问操作。这部分系统资源是系统最核心的底层服务，如果遭受破坏，操作系统将无法正常运行。
鉴于该类型权限对系统的影响程度非常大，目前暂不向任何三方应用开放。

权限类型（系统和用户，系统安装包自动，用户弹窗手动，权限显示在应用商店）

• system_grant
system_grant指的是系统授权类型，在该类型的权限许可下，应用被允许访问的数据不会涉及到用户或设备的敏感信息，应用被允许执行的操作不会对系统或者其他应用产生大的不利影响。
如果在应用中申请了system_grant权限，那么系统会在用户安装应用时，自动把相应权限授予给应用。应用需要在应用商店的详情页面，向用户展示所申请的system_grant权限列表。

• user_grant
user_grant指的是用户授权类型，在该类型的权限许可下，应用被允许访问的数据将会涉及到用户或设备的敏感信息，应用被允许执行的操作可能对系统或者其他应用产生严重的影响。
该类型权限不仅需要在安装包中申请权限，还需要在应用动态运行时，通过发送弹窗的方式请求用户授权。在用户手动允许授权后，应用才会真正获取相应权限，从而成功访问操作目标对象。
比如说，在权限定义列表中，麦克风和摄像头对应的权限都是属于用户授权权限，列表中给出了详细的权限使用理由。
应用需要在应用商店的详情页面，向用户展示所申请的user_grant权限列表。

配置文件权限声明

模型	Stage模型	FA模型
标识Aility	abilities	ability
配置文件	module.json5	config.json

应用权限列表（考点）

当前仅支持部分权限通过应用市场（AGC）使用ACL的方式跨级别申请权限。（以下列举常考的，其余请查表）

这里建议过一篇表，留个印象，权限接口函数基本为英文释义。

接口函数	函数含义	权限级别	授权方式	ACL使能
ohos.permission.DISTRIBUTED_DATASYNC	暂无	ㅤ	ㅤ	ㅤ
ohos.permission.START_ABILITIES_FROM_BACKGROUND	允许应用在后台启动或者访问其他组件。	system_basic	system_grant	TRUE
ohos.permission.ABILITY_BACKGROUND_COMMUNICATION	允许应用将Ability组件在后台启动并与该Ability建立通信连接。	system_basic	system_grant	TRUE
ohos.permission.START_INVISIBLE_ABILITY	ㅤ	ㅤ	ㅤ	ㅤ
ohos.permission.INTERNET	允许使用Internet网络。	normal	system_grant	TRUE

用户认证

用户认证（考点）

• User Authentication Kit（用户认证服务）提供了基于用户在设备本地注册的锁屏口令、人脸和指纹来认证用户身份的能力。

• 提供了系统级用户身份认证功能，并提供了多设备统一的、集多种认证方式（人脸、指纹、口令）于一体的系统级用户身份认证控件。

• 用户向应用/系统服务请求访问某些个人数据或执行某些敏感操作时，应用/系统服务将调用系统用户身份认证控件对用户身份进行认证，认证通过后，才响应用户对于数据或敏感操作的执行请求。

用户身份认证可用于各种鉴权场景，如应用内账号登录、支付认证等。

亮点/特征

• 归一化认证接口：屏蔽不同认证因子的差异，调用锁屏口令、人脸、指纹认证的接口归一。

• 支持感知认证可信等级差异：支持调用者指定期望的认证可信等级，避免将低安认证能力应用在高风险操作的用户鉴权场景，例如将防伪能力不够的2D人脸认证用于支付场景。

• 支持业务自定义认证方式：支持带导航键的认证界面，用户点击导航键可切换业务自定义认证界面。

• 支持短时间内复用设备解锁认证结果：支持认证方式无关的解锁认证结果复用，采用该认证方式，只要在解锁后调用者指定的时间范围内（最长5min），可不用重复认证用户直接返回认证通过结果。

• 提供系统级用户身份认证界面：支持调用者自定义认证界面的标题和导航键文字。

• 支持感知注册凭据的变化：业务开通时，从认证成功结果中获取用户凭据的状态，或者直接查询用户凭据的状态，将注册的凭据状态存储起来。当调用者需要感知用户凭据变化时，需要从当前认证成功结果获取凭据的状态，或者查询当前凭据的状态，通过对比差异感知凭据状态的变化。

运作机制

用户认证框架主要包括四个部分：

1. 统一用户认证API：提供归一化的系统用户身份认证能力调用接口。屏蔽认证差异，便于开发者调用系统能力认证用户身份。

2. 统一用户认证框架：包括框架层的SA和驱动，负责调度系统上的各种身份认证能力和用户认证控件，来完成业务通过统一用户认证API发起的用户认证请求。

3. 统一用户认证控件：实现了各种认证方式的用户身份认证交互界面，确保一致的用户身份认证体验，供统一身份认证框架调用。

4. 各种认证能力：包括口令认证、人脸认证和指纹认证，分别实现了基于锁屏口令、人脸和指纹认证用户身份的能力，供统一用户认证框架调度。

用户身份认证通过后，统一用户认证框架会在设备可信执行环境中签发用户身份认证通过证明，简称AuthToken。

认证可信等级

系统采用三种指标来衡量认证可信等级（AuthTrustLevel），具体认证可信等级如下表所示。

• FRR（False Rejection Rate）：将合法用户当做非法用户拒绝的概率。

• FAR（False Acceptance Rate）：将非法用户当做合法用户接受的概率，又称为误闯率。

• SAR（Spoof Acceptance Rate）：接受一个基于合法生物特征复制的、非活体的样本概率。

FAR越低，FRR越高，认证的安全性越高，但使用便捷性越差。

认证可信等级	认证能力指标	说明&举例	典型应用场景
ATL4	FRR=10%时，FAR≤0.0001%，SAR≤3%	能高精度地识别用户个体，有很强的活体检测能力，如采用了安全键盘的6位及以上PIN码认证和有特殊安全增强的指纹与3D人脸认证。	小额支付
ATL3	FRR=10%时，FAR≤0.002%，SAR≤7%	能精确识别用户个体，有较强的活体检测能力，如有特殊安全增强的2D人脸认证。	设备解锁
ATL2	FRR=10%时，FAR≤0.002%，7%<SAR≤20%	能精确识别用户个体，有一定的活体检测能力，如使用普通相机采集图像的2D人脸认证。	维持设备解锁状态
ATL1	FRR=10%时，FAR≤1%，7%<SAR≤20%	能识别用户个体，有一定的活体检测能力，如声纹认证。	ㅤ

网络与连接

IPC与RPC通信（同属于网络与连接部分）

IPC（Inter-Process Communication）与RPC（Remote Procedure Call）用于实现跨进程通信。

• 前者IPC使用Binder驱动，用于设备内的跨进程通信。

• 后者RPC使用软总线驱动，用于跨设备跨进程通信。

• 需要跨进程通信的原因是因为每个进程都有自己独立的资源和内存空间，其他进程不能随意访问不同进程的内存和资源，IPC/RPC便是为了突破这一点。

• IPC和RPC通常采用客户端-服务器（Client-Server）模型，在使用时，请求服务的（Client）一端进程可获取提供服务（Server）一端所在进程的代理（Proxy），并通过此代理读写数据来实现进程间的数据通信。

• 通常，Server会先注册系统能力（System Ability）到系统能力管理者（System Ability Manager，缩写SAMgr）中，SAMgr负责管理这些SA并向Client提供相关的接口。Client要和某个具体的SA通信，必须先从SAMgr中获取该SA的代理，然后使用代理和SA通信。下文直接使用Proxy表示服务请求方，Stub表示服务提供方。

 

示意图

约束与限制

• 单个设备上跨进程通信时，传输的数据量最大约为1MB，过大的数据量请使用匿名共享内存。

• 不支持在RPC中订阅匿名Stub对象（没有向SAMgr注册Stub对象）的死亡通知。

• 不支持把跨设备的Proxy对象传递回该Proxy对象所指向的Stub对象所在的设备，即指向远端设备Stub的Proxy对象不能在本设备内进行二次跨进程传递。

其他

IPC/RPC的主要工作是让运行在不同进程的Proxy和Stub互相通信，包括Proxy和Stub运行在不同设备的情况。

匿名Stub

正向的消亡通知是Proxy感知Stub的状态，若想达到反向的死消亡通知，即Stub感知Proxy的状态，可以巧妙的利用正向消亡通知。如两个进程A（原Stub所在进程）和B（原Proxy所在进程），进程B在获取到进程A的Proxy对象后，在B进程新建一个匿名Stub对象（匿名指未向SAMgr注册），可称之为回调Stub，再通过SendRequest接口将回调Stub传给进程A的原Stub。这样一来，进程A便获取到了进程B的回调Proxy。当进程B消亡或B所在设备离开组网时，回调Stub会消亡，回调Proxy会感知，进而通知给原Stub，便实现了反向消亡通知。

注意：

• 反向死亡通知仅限设备内跨进程通信使用，不可用于跨设备。

• 当匿名Stub对象没有被任何一个Proxy指向的时候，内核会自动回收。

文件管理

应用文件（考点）！！！！！！

应用文件：文件所有者为应用，包括应用安装文件、应用资源文件、应用缓存文件等。（考点）

• 设备上应用所使用及存储的数据，以文件、键值对、数据库等形式保存在一个应用专属的目录内。该专属目录我们称为“应用文件目录”，该目录下所有数据以不同的文件格式存放，这些文件即应用文件。（考点）

• “应用文件目录”与一部分系统文件（应用运行必须使用的系统文件）所在的目录组成了一个集合，该集合称为“应用沙箱目录”，代表应用可见的所有目录范围。因此“应用文件目录”是在“应用沙箱目录”内的。

• 系统文件及其目录对于应用是只读的；应用仅能保存文件到“应用文件目录”下，根据目录的使用规范和注意事项来选择将数据保存到不同的子目录中。

应用沙箱目录（考点）

应用沙箱是一种以安全防护为目的的隔离机制，避免数据受到恶意路径穿越访问。在这种沙箱的保护机制下，应用可见的目录范围即为“应用沙箱目录”。

• 对于每个应用，系统会在内部存储空间映射出一个专属的“应用沙箱目录”，它是“应用文件目录”与一部分系统文件（应用运行必需的少量系统文件）所在的目录组成的集合。

• 应用沙箱限制了应用可见的数据的最小范围。在“应用沙箱目录”中，应用仅能看到自己的应用文件以及少量的系统文件（应用运行必需的少量系统文件）。因此，本应用的文件也不为其他应用可见，从而保护了应用文件的安全。（考点）

• 应用可以在“应用文件目录”下保存和处理自己的应用文件；系统文件及其目录对于应用是只读的；而应用若需访问用户文件，则需要通过特定API同时经过用户的相应授权才能进行。

应用沙箱目录 = 应用文件+ 少量系统文件。

应用沙箱路径（考点）

在应用沙箱保护机制下，应用无法获知除自身应用文件目录之外的其他应用或用户的数据目录位置及存在。同时，所有应用的目录可见范围均经过权限隔离与文件路径挂载隔离，形成了独立的路径视图，屏蔽了实际物理路径：

• 如下图所示，在普通应用（也称三方应用）视角下，不仅可见的目录与文件数量限制到了最小范围，并且可见的目录与文件路径也与系统进程等其他进程看到的不同。我们将普通应用视角下看到的“应用沙箱目录”下某个文件或某个具体目录的路径，称为“应用沙箱路径”。

• 一般情况下，开发者的hdc shell环境等效于系统进程视角，因此“应用沙箱路径”与开发者使用hdc工具调试时看到的真实物理路径不同，其对应关系详见应用沙箱路径和调试进程视角下的真实物理路径。

• 从实际物理路径推导物理路径与沙箱路径并不是1：1的映射关系，沙箱路径总是少于系统进程视角可见的物理路径。有些调试进程视角下的物理路径在对应的应用沙箱目录是无法找到的，而沙箱路径总是能够找到其对应的物理路径。（考点）

应用文件上传下载（考点）

• 应用可以将应用文件上传到网络服务器，也可以从网络服务器下载网络资源文件到本地应用文件目录。（考点）

• 当前上传应用文件功能，仅支持上传应用缓存文件路径（cacheDir）下的文件。使用上传下载模块接口，需申请相关权限：ohos.permission.INTERNET。（考点）

• 当前网络资源文件仅支持下载至应用文件目录。使用上传下载模块接口，需申请相关权限：ohos.permission.INTERNET。（考点）

应用文件分享（考点）

应用文件分享是应用之间通过分享URI（Uniform Resource Identifier）或文件描述符FD（File Descriptor）的方式，进行文件共享的过程。由于FD分享的文件关闭FD后，无法再打开分享文件，因此不推荐使用，本文重点介绍URI分享方式。

• 基于URI分享方式，应用可分享单个文件，通过ohos.app.ability.wantConstant的wantConstant.Flags接口以只读或读写权限授权给其他应用。应用可通过ohos.file.fs的open()接口打开URI，并进行读写操作。当前OpenHarmony API 9仅支持临时授权，分享给其他应用的文件在被分享应用退出时权限被收回。

• 基于FD分享方式，应用可分享单个文件，通过ohos.file.fs的open接口以指定权限授权给其他应用。应用从Want中解析拿到FD后可通过ohos.file.fs的读写接口对文件进行读写。

文件URI的格式为：file://<bundleName>/<path>

• file：文件URI的标志。

• bundleName：该文件资源的属主。

• path：文件资源在应用沙箱中的路径。

应用文件访问与管理

• 应用需要对应用文件目录下的应用文件进行查看、创建、读写、删除、移动、复制、获取属性等访问操作。开发者通过基础文件操作接口（ohos.file.fs）实现应用文件访问能力。

 

用户文件

用户文件：文件所有者为登录到该终端设备的用户，包括用户私有的图片、视频、音频、文档等。

1. 用户文件存放在用户目录下，归属于该设备上登录的用户。

2. 用户文件存储位置主要分为内置存储、外置存储。

3. 应用对用户文件的创建、访问、删除等行为，需要提前获取用户授权，或由用户操作完成。

内置存储（考点）

内置存储，是指用户文件存储在终端设备的内部存储设备（空间）上。内置存储设备无法被移除。内置存储的用户文件主要有：

• 用户特有的文件：这部分文件归属于登录该设备的用户，不同用户登录后，仅可看到该用户自己的文件。按照这些文件的特征/属性，以及用户/应用的使用习惯，可分为：
• 图片/视频类媒体文件
所具有的特征包括拍摄时间、地点、旋转角度、文件宽高等信息，以媒体文件的形式存储在系统中，通常是以所有文件、相册的形式对外呈现，不会展示其在系统中存储的具体位置。
• 音频类媒体文件
所具有的特征包括所属专辑、音频创作者、持续时间等信息，以媒体文件的形式存储在系统中，通常会以所有文件、专辑、作家等形式对外部呈现，不会展示其在系统中存储的具体位置。
• 其他文件（统称为文档类文件）
以普通文件的形式存储在系统中，该类文件既包括普通的文本文件、压缩文件等，又包括以普通文件形式存储的图片/视频、音频文件，该类文件通常是以目录树的形式对外展示。

• 多用户共享的文件：用户可以通过将文件放在共享文件区，实现多个用户之间文件的共享访问。
共享文件区的文件，也是以普通文件的形式存储在系统中，以目录树的形式对外展示。

外置存储

外置存储，是指用户文件存储在外置可插拔设备上（如SD卡、U盘等）。外置存储设备上的文件，和内置存储设备共享区文件一样，可以被所有登录到系统中的用户看到。

外置存储设备具备可插拔属性，因此系统提供了设备插拔事件的监听及挂载功能，用于管理外置存储设备，当前仅对系统应用开放。

外置存储设备上的文件，全部以普通文件的形式呈现，和内置存储设备上的文档类文件一样，采用目录树的形式对外展示。

用户文件访问框架

用户文件访问框架（File Access Framework）是一套提供给开发者访问和管理用户文件的基础框架。该框架依托于HarmonyOS的ExtensionAbility组件机制，提供了一套统一访问用户文件的方法和接口。

选择用户文件

终端用户有时需要分享、保存一些图片、视频等用户文件，开发者需要在应用中支持此类使用场景。此时，开发者可以使用HarmonyOS系统预置的文件选择器（FilePicker），实现用户文件选择及保存能力。

根据用户文件的常见类型，文件选择器（FilePicker）分别提供以下接口：

• PhotoViewPicker：适用于图片或视频类文件的选择与保存。

• DocumentViewPicker：适用于文档类文件的选择与保存。

• AudioViewPicker：适用于音频类文件的选择与保存。

保护用户文件

在从网络下载文件到本地、或将已有用户文件另存为新的文件路径等场景下，需要使用FilePicker提供的保存用户文件的能力。

对音频、图片、视频、文档类文件的保存操作类似，均通过调用对应picker的save()接口并传入对应的saveOptions来实现。

驱动

HDF驱动

HDF（Hardware Driver Foundation）驱动框架，为驱动开发者提供驱动框架能力，包括驱动加载、驱动服务管理、驱动消息机制和配置管理。并以组件化驱动模型作为核心设计思路，让驱动开发和部署更加规范，旨在构建统一的驱动架构平台，为驱动开发者提供更精准、更高效的驱动管理的开发环境，力求做到一次开发，多系统部署。（考点）

驱动加载：preload

HDF驱动框架提供把和配置的设备列表匹配成功的驱动程序加载起来的功能。

• 按需加载

• 按序加载（默认）：配置文件中的priority（取值范围为整数0到200）是用来表示host（驱动容器）和驱动的优先级的。不同的host内的驱动，host的priority值越小，驱动加载优先级越高；同一个host内驱动的priority值越小，加载优先级越高。

驱动服务管理：policy

HDF框架可以集中管理驱动服务，开发者可直接通过HDF框架对外提供的能力接口获取驱动相关的服务。

当驱动需要以接口的形式对外提供能力时，可以使用HDF框架的驱动服务管理能力。

驱动消息机制

HDF框架提供统一的驱动消息机制，支持用户态应用向内核态驱动发送消息，也支持内核态驱动向用户态应用发送消息。

当用户态应用和内核态驱动需要交互时，可以使用HDF框架的消息机制来实现。

消息机制的功能主要有以下两种：

• 用户态应用发送消息到驱动。

• 用户态应用接收驱动主动上报事件。

配置管理

HCS（HDF Configuration Source）是HDF驱动框架的配置描述源码，内容以Key-Value为主要形式。它实现了配置代码与驱动代码解耦，便于开发者进行配置管理。

HC-GEN（HDF Configuration Generator）是HCS配置转换工具，可以将HDF配置文件转换为软件可读取的文件格式：

• 在弱性能环境中，转换为配置树源码或配置树宏定义，驱动可直接调用C代码或宏式APIs获取配置。

• 在高性能环境中，转换为HCB（HDF Configuration Binary）二进制文件，驱动可使用HDF框架提供的配置解析接口获取配置。

驱动模型

PWM：连续变化的数值控制

PWM即脉冲宽度调制（Pulse Width Modulation）的缩写，是一种对模拟信号电平进行数字编码并将其转换为脉冲的技术。

PWM接口

PWM接口定义了操作PWM设备的通用方法集合，包括：

• PWM设备句柄获取和释放

• PWM周期、占空比、极性的设置

• PWM使能和关闭

• PWM配置信息的获取和设置

PWM独立服务模式结构图

PWM使用流程

其他

DFX

在OpenHarmony中，DFX(Design for X)是为了提升质量属性的软件设计，目前包含的内容主要有：DFR（Design for Reliability，可靠性）和DFT（Design for Testability，可测试性）特性。

应用事件打点HiAppEvent（考点）

HiAppEvent是在系统层面为应用开发者提供的一种事件打点机制，用于帮助应用记录在运行过程中发生的故障信息、统计信息、安全信息、用户行为信息，以支撑开发者分析应用的运行情况。（传统的日志系统里汇聚了整个设备上所有程序运行的过程流水日志，难以识别其中的关键信息。）

• 打点：记录由用户操作引起的变化，提供业务数据信息，以供开发、产品、运维分析。

性能打点跟踪hiTraceMeter

hiTraceMeter为开发者提供系统性能打点接口。开发者通过在自己的业务逻辑中的关键代码位置调用HiTraceMeter接口提供的API接口，能够有效跟踪进程轨迹、查看系统性能。

• hiTraceMeter Tag:跟踪数据使用类别分类，称作hiTraceMeter Tag或hiTraceMeter Category，一般每个软件子系统对应一个Tag，该Tag在打点API中以类别Tag参数传入。hiTraceMeter命令行工具采集跟踪数据时，只采集给定的Tag类别选项指定的跟踪数据。

分布式跟踪hiTraceChain

hiTraceChain是基于云计算分布式跟踪调用链思想，在端侧业务流程（涉及跨线程、跨进程、跨设备）中的一种轻量级实现。hiTraceChain在业务控制面流程中，生成和传递唯一跟踪标识，在业务流程中输出的各类信息中（包括应用事件、系统时间、日志等）记录该跟踪标识。在调试、问题定位过程中，开发者可以通过该唯一跟踪标识将本次业务流程端到端的各类信息快速关联起来。hiTraceChain为开发者提供业务流程调用链跟踪的维测接口，帮助开发者迅速获取指定业务流程调用链的运行日志，定位跨设备/跨进程/跨线程的故障问题。

• chainId:分布式跟踪标识，属于HiTraceId的一部分，用于标识当前跟踪的业务流程。

错误管理

当应用的代码存在规范问题或错误时，会在运行中产生异常和错误，如应用未捕获异常、应用生命周期超时等。在错误产生后，应用会异常退出。错误日志通常会保存在用户本地存储上，不方便开发者定位问题。所以，应用开发者可以使用错误管理的接口，在应用退出前，及时将相关错误及日志上报到开发者的服务平台来定位问题。

• 应用错误管理接口由errorManager模块提供，开发者可以通过import引入

系统默认对异常的处理方式为进程退出，如果应用使用过程中产生了用户数据，直接退出可能会导致用户工作中断，数据丢失。如果使用应用故障恢复相关接口，则可对临时数据进行保存，应用退出后会重启应用并恢复先前的状态和数据，能给用户带来更好的使用体验。

• 目前该接口仅支持单进程单Ability的Stage模型应用开发。

• 应用故障恢复接口由appRecovery模块提供，开发者可以通过import引入。

• 通常的故障类型有JS程序Crash、应用程序卡死、C++程序Crash。Crash故障时应用一般都会被关闭。Freeze故障为应用无响应卡屏场景。应用上层无需关注故障类型，底层恢复框架会根据故障类型来实现不同场景的故障管理。

共享

HarmonyOS提供了两种共享包，HAR（Harmony Archive）静态共享包，和HSP（Harmony Shared Package）动态共享包。

• HAR中的代码和资源跟随使用方编译，如果有多个使用方，它们的编译产物中会存在多份相同拷贝；

• HSP中的代码和资源可以独立编译，运行时在一个进程中代码也只会存在一份。

HAR和HSP在APP包中的形态示意图

HSP

HSP旨在解决HAR存在的几个问题：

• 多个HAP引用相同的HAR，导致的APP包大小膨胀问题。

• 多个HAP引用相同的HAR，HAR中的一些状态变量无法共享的问题。

HSP的一些约束：

• HSP及其使用方都必须是Stage模型。

• HSP及其使用方都必须使用esmodule编译模式。

• HSP不支持在配置文件中声明abilities、extensionAbilities标签。

HSP按照使用场景可以分为应用内HSP和应用间HSP，应用间HSP暂不支持。

HAR

HAR（Harmony Archive）是静态共享包，可以包含代码、C++库、资源和配置文件。通过HAR可以实现多个模块或多个工程共享ArkUI组件、资源等相关代码。HAR不同于HAP，不能独立安装运行在设备上，只能作为应用模块的依赖项被引用。

• HAR不支持在配置文件中声明abilities、extensionAbilities组件。

• HAR不支持在配置文件中声明pages页面。

• HAR不支持在build-profile.json5文件的buildOption中配置worker。

• FA模型与Stage模型的HAR不支持相互引用。

• Stage模型的HAR，不能引用AppScope内的内容。在编译构建时AppScope中的内容不会打包到HAR中，导致HAR资源引用失败。

 

🫧 单独知识点

❄️ 未找到对应知识点

11.[单选题]——未找到

12.[单选题]——未找到

17.[单选题]——未找到

23.[单选题]——未找到

25.[单选题]——无有效信息

1. 网络请求可以放到主线程中执行。

🎵 答案存疑

1. OpenHarmony 轻量级内核是基于 IoT 领域轻量级物联网操作系统 Huawei LiteOS 内核演进发展的新一代内核，其中不包含以下哪些选项？

🌀 后期完成

1. 设备需要完成以下接口的开发步骤，以使能 BLE 广播的发送。

1. 内核抽象层 (KAL, Kernel Abstract Layer) 通过屏蔽多内核差异，对上层提供基础的内核能力，包括___。

1. 使用 UiTest 模块编写 OpenHarmony 应用自动化测试用例代码: let driver = Driver.create(); let button123 = await driver.findComponent(ON.type('Button').id('123')); await button123.click(); 实现的是: 找到 id 为 123 的按钮，并点击。