OpenHarmony技术架构

以4为核心，辅助2+3+5部分

• OS内核

• HDF：统一驱动框架

• 标准系统最小运行内存：128M

DevEco Studio开发工具

1.DevEco Studio基本特性

• 多设备统一开发环境

• 支持多语言的代码开发和调试

• 支持FA/PA快速开发

• 支持分布式多端应用开发

• 支持应用开发UI实时预览

2.OpenHarmony应用开发流程

OpenHarmony应用开发

1.移动应用概念

2.移动应用的组成

（1）APP

（2）APP包组成

• entry：应用的主模块。一个APP中，对于同一设备类型必须有且只有一个entry类型的HAP，可独立安装运行。

• feature：应用的动态特性模块。一个APP可以包含一个或多个feature类型的HAP，也可以不包含。只有包含Ability的HAP才能够独立运行。

（3）Module结构

• Ability类型的Module对于编译后的HAP

• Library类型的Module对于编译后的HAR或者HSP

（4）Ability

• FA有UI界面，而PA无UI界面。

（5）pack.info

• divery-with-install:表示该HAP是否支持随应用安装。“true”表示支持随应用安装；“false”表示不支持随应用安装。

• name：HAP文件名。

• module-type：模块类型，entry或者feature。

• device-type：表示支持该HAP运行的设备类型。

（6）共享包

（7）资源分类与访问

• 应用资源：借助资源文件能力，开发者在应用中自定义资源，自行管理这些资源在不同的设备或配置中的表现。
• 应用资源文件（字符串、图片、音频等）：统一存放于resources目录下，便于开发者使用和维护。resourse目录包括base目录与限定词目录。

• 系统资源：开发者直接使用系统预置的资源定义（即分层参数，统一资源ID在设备类型、深浅色等不同配置下有不同的取值）。

（8）配置文件

• 应用的全局配置信息，包含应用的包名、开发厂商、版本号等基本信息。

• 特定设备类型的配置信息。

• Module的基本配置信息，例如Module名称、类型、描述、支持的设备类型等基本信息。

• 应用组件信息，包含UIAbility组件和ExtensionAbility组件的描述信息。

• 应用运行过程中所需的权限信息。

3.应用模型

（1）应用组件——应用模型的最重要的部分

（2）应用进程和线程

• 应用进程模型：应用进程模型定义应用进程的创建和销毁方式，以及进程间的通信方式。

• 应用线程模型：应用线程模型定义应用进程内线程的创建和销毁方式、主线程和UI线程的创建方式、线程间的通信方式。

• 应用任务管理模型：应用任务管理模型定义任务（Mission）的创建和销毁方式，以及任务与组件间的关系。

• C,由B推出C错误

（3）OpenHarmony的进程模型

• 应用中（同一包名）的所有UIAbility、ServiceExtensionAbility运行在同一个独立进程中。

• WebView拥有独立的渲染进程

• 公共事件机制：多用于一对多的通信场景，公共事件发布者可能存在多个订阅者同时接受事件。

• 后台服务机制：当前主要通过ServiceExtensionAbility的能力实现。

（4）Stage模型

• 为复杂应用而设计
• 多个应用组件共享同一个ArkTS引擎（运行ArkTS语言的虚拟机）实例，应用组件之间可以方便的共享对象和状态，同时减少复杂应用运行对内存的占用。
• 采用面向对象的开发方式，使得复杂应用代码可读性高、易维护性好、可扩展性强。

• 原生支持应用组件级的跨端迁移和多端协同：Stage模型实现了应用组件与UI解耦。UI和应用组件都可以独立实现分布式的交互能力，实现UI的流转和组件分布式的交互。
• 在跨端迁移场景下，系统在多设备的应用组件之间迁移数据/状态后，UI便可利用ArkUI的声明式特点，通过应用组件中保存的数据/状态恢复用户界面，便携实现跨端迁移。
• 在多端协同场景下，应用组件具备组件间通信的RPC调用能力，天然支持跨设备应用组件的交互。

• 支持多设备和多窗口形态
应用组件管理和窗口管理在架构层面解耦：
• 便于系统对应用组件进行裁剪（无屏设备可裁剪窗口）。
• 便于系统扩展窗口形态。
• 在多设备（如桌面设备和移动设备）上，应用组件可使用同一套生命周期。

• 平衡应用能力和系统管控成本
Stage模型重新定义应用能力的边界，平衡应用能力和系统管控成本。
• 提供特定场景（如卡片、输入法）的应用组件，以便满足更多的使用场景。
• 规范化后台进程管理：为保障用户体验，Stage模型对后台应用进程进行了有序治理，应用程序不能随意驻留在后台，同时应用后台行为受到严格管理，防止恶意应用行为。

4.事件通知（开发—>通知—>通知概述）

（1）通知简介

• 显示接收到的短消息、即时消息等。

• 显示应用的推送消息，如广告、版本更新等。

• 显示当前正在进行的事件，如下载等。

（2）通知业务流程

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

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

5.文件（开发—>文件管理—>文件管理概述）

（1）文件存储

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

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

• 系统文件：与应用和用户无关的其他文件，包括公共库、设备文件、系统资源文件等。这类文件不需要开发者进行文件管理，本文不展开介绍。

（2）应用文件

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

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

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

（2）应用沙箱目录

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

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

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

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

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

（4）分布式文件服务

6.传感器与媒体

（1）工作原理：运作机制

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

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

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

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

（2）普通传感器调用

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

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

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

（3）媒体访问和播放

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

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