内核层
- 内核子系统：采用多内核（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 开发的应用，能够实现特定的业务功能，支持跨设备调度与分发，为用户提供一致、高效的应用体验。
基础知识：构建第一个 ArkTS 应用（Stage 模型） (openharmony.cn)
Module 类型
Module 按照使用场景可以分为两种类型：
Ability 类型的 Module： 用于实现应用的功能和特性。每一个 Ability 类型的 Module 编译后，会生成一个以.hap 为后缀的文件，我们称其为 HAP（Harmony Ability Package）包。HAP 包可以独立安装和运行，是应用安装的基本单位，一个应用中可以包含一个或多个 HAP 包，具体包含如下两种类型。
- entry 类型的 Module：应用的主模块，包含应用的入口界面、入口图标和主功能特性，编译后生成 entry 类型的 HAP。每一个应用分发到同一类型的设备上的应用程序包，只能包含唯一一个 entry 类型的 HAP。
- feature 类型的 Module：应用的动态特性模块，编译后生成 feature 类型的 HAP。一个应用中可以包含一个或多个 feature 类型的 HAP，也可以不包含。
Library 类型的 Module： 用于实现代码和资源的共享。同一个 Library 类型的 Module 可以被其他的 Module 多次引用，合理地使用该类型的 Module，能够降低开发和维护成本。Library 类型的 Module 分为 Static 和 Shared 两种类型，编译后会生成共享包。
- Static Library：静态共享库。编译后会生成一个以.har 为后缀的文件，即静态共享包 HAR（Harmony Archive）。
- Shared Library：动态共享库。编译后会生成一个以.hsp 为后缀的文件，即动态共享包 HSP（Harmony Shared Package）。
说明：
实际上，Shared Library 编译后除了会生成一个.hsp 文件，还会生成一个.har 文件。这个.har 文件中包含了 HSP 对外导出的接口，应用中的其他模块需要通过.har 文件来引用 HSP 的功能。为了表述方便，我们通常认为 Shared Library 编译后生成 HSP。
stage 模型编译态包结构
- ets 目录：ArkTS 源码编译生成.abc 文件。
- resources 目录：AppScope 目录下的资源文件会合入到 Module 下面资源目录中，如果两个目录下的存在重名文件，编译打包后只会保留 AppScope 目录下的资源文件。
- module 配置文件：AppScope 目录下的 app.json5 文件字段会合入到 Module 下面的 module.json5 文件之中，编译后生成 HAP 或 HSP 最终的 module.json 文件。
FA 模型应用程序包结构
FA 模型与 Stage 模型不同之处在于 HAP 内部文件存放位置不同，FA 模型将所有的资源文件、库文件和代码文件都放在 assets 文件夹中，在文件夹内部进一步区分。
- config.json 是应用配置文件，IDE 会自动生成一部分模块代码，开发者按需修改其中的配置。详细字段请参见 应用配置文件。
- assets 是 HAP 所有的资源文件、库文件和代码文件的集合，内部可以分为 entry 和 js 文件夹。entry 文件夹中存放的是 resources 目录和 resources.index 文件。
- resources 目录用于存放应用的资源文件（字符串、图片等），便于开发者使用和维护，详见 资源文件的使用。
- resources.index 是资源索引表，由 IDE 调用 SDK 工具生成。
- js 文件夹中存放的是编译后的代码文件。
- pack.info 是 Bundle 中用于描述每个 HAP 属性的文件，例如 app 中的 bundleName 和 versionCode 信息、module 中的 name、type 和 abilities 等信息，由 IDE 工具构建 Bundle 包时自动生成。
混淆：
一种通用、高效的轻量级代码分析技术，对外源代码进行逆向工程、解码分析和结混淆，并保证代码的语义一致性; 寻求一种高效、通用的神经网络检测模型，在硬件限制下保证混淆恶意代码的检出率。
口 代码分析层面:(1)代码解混淆时间 (2)代码逆向成功率 (3)语义一致性分析
口 恶意代码检测层面:(1)模型运行时间 (2)模型性能指标分解目标
口 基于 Linux-AOSP 的 Android 逆向: 测试 OpenHarmony 对安卓平台恶意软件的兼容性，总结目前的 Java 混淆技术，开发或改进现有的反编译、解包和解混淆算法。
口基于 Lite-OS 的 JavaScript 脚本解混淆: 总结目前的 JavaScript 混淆技术，开发或改进现有的解混淆算法。
情景举例: 开源 OpenHarmony 的方舟编译器提供了多种混淆技术，对字节码进行混淆，从而保证 HarmonyOs 应用包内代码难以逆向和分析。
考量点: (1)代码解混淆时间 (2)代码逆向成功率 (3)语义一致性分析口
