1. 写在前面：怎么读这份笔记

【理解】HarmonyOS 官方架构文档体系庞大，自学时最容易迷失在两个问题：

1. 新旧版本混读：官方文档站同时存在旧版（FA 模型、Java/JS UI）与新版本（Stage 模型、ArkTS/ArkUI）。学 NEXT 只看新版，旧版文档仅作演进对照。
2. 概念分层不清：系统架构（内核/服务/框架/应用四层）与应用模型（Stage 模型）是两个不同层面的东西，前者描述操作系统本身，后者描述"开发者怎么组织应用"。

【理解】建议阅读顺序：系统定位 → 分层架构 → 应用模型 → 进程/线程模型 → UI 框架与运行时 → 分布式特性。这份笔记即按此顺序组织。

---

2. HarmonyOS 是什么：定位与三大特征

【原文】HarmonyOS 是一款面向万物互联时代的、全新的分布式操作系统。在传统的单设备系统能力基础上，提出了基于同一套系统能力、适配多种终端形态的分布式理念，能够支持手机、平板、智能穿戴、智慧屏、车机、PC、智能音箱、耳机、AR/VR 眼镜等多种终端设备。

【原文】HarmonyOS 有三大特征：

特征	面向对象	核心内容
硬件互助，资源共享	消费者	搭载该操作系统的设备在系统层面融为一体、形成超级终端，设备硬件能力可弹性扩展
一次开发，多端部署	应用开发者	应用开发与终端形态差异无关，聚焦上层业务逻辑，一套代码多端运行
统一 OS，弹性部署	设备开发者	组件化设计方案，按设备资源能力与业务特征灵活裁剪

【理解】三个特征对应三个视角：消费者看到的是"多设备像一台设备"；应用开发者看到的是"写一次跑多端"；设备厂商看到的是"按需裁剪一套 OS 适配所有硬件"。分布式是贯穿始终的第一性原理。

---

3. 系统分层架构（四层）

3.1 总览

【原文】HarmonyOS 整体遵从分层设计，从下向上依次为：内核层、系统服务层、框架层和应用层。系统功能按照"系统 > 子系统 > 功能/模块"逐级展开，在多设备部署场景下，支持根据实际需求裁剪某些非必要的子系统或功能/模块。

┌─────────────────────────────────────────────────────┐
│  应用层：系统应用 + 第三方应用（NEXT：UIAbility /   │
│          ExtensionAbility 组成）                     │
├─────────────────────────────────────────────────────┤
│  框架层：ArkUI 声明式 UI 框架 + Ability 框架         │
│          + ArkTS/JS/C/C++ 多语言框架 API             │
├─────────────────────────────────────────────────────┤
│  系统服务层：系统基本能力 / 基础软件服务 /           │
│          增强软件服务 / 硬件服务（四大子系统集）     │
├─────────────────────────────────────────────────────┤
│  内核层：多内核（Linux/LiteOS…）+ 内核抽象层 KAL     │
│          + 硬件驱动框架 HDF                          │
└─────────────────────────────────────────────────────┘

【理解】四层架构不是 NEXT 的新发明，而是从 HarmonyOS 1.0 延续至今的稳定骨架。NEXT 的变化不在"层数"，而在每层具体组成：内核层依然是多内核 + KAL + HDF；系统服务层四大子系统集结构不变；框架层和应用层变化最大——Java 能力淡出、ArkTS/ArkUI 成为主推、应用组成单元从 FA/PA 演进为 UIAbility/ExtensionAbility。

3.2 内核层

【原文】内核层由内核子系统和驱动子系统两部分组成：

• 内核子系统：HarmonyOS 采用多内核设计，支持针对不同资源受限设备选用适合的 OS 内核。内核抽象层（KAL，Kernel Abstract Layer）通过屏蔽多内核差异，对上层提供基础的内核能力，包括进程/线程管理、内存管理、文件系统、网络管理和外设管理等。
• 驱动子系统：硬件驱动框架（HDF）是 HarmonyOS 硬件生态开放的基础，提供统一外设访问能力和驱动开发、管理框架。

【理解】“多内核"是理解内核层的关键：轻量设备（穿戴、IoT 传感器）可用 LiteOS 类轻内核，富设备（手机、平板）用 Linux 内核。开发者/上层服务不需要感知底层是哪个内核——KAL 把差异屏蔽了。HDF 的作用类似"驱动的标准插座”，设备厂商按框架写驱动，上层统一访问。

3.3 系统服务层

【原文】系统服务层是 HarmonyOS 的核心能力集合，通过框架层对应用程序提供服务，包含四个子系统集：

子系统集	职责	典型组成
系统基本能力	分布式应用在多设备上运行、调度、迁移的基础能力	分布式软总线、分布式数据管理、分布式任务调度、方舟多语言运行时、公共基础库、多模输入、图形、安全、AI
基础软件服务	公共的、通用的软件服务	事件通知、电话、多媒体、DFX（Design For X）、MSDP&DV
增强软件服务	针对不同设备的差异化能力增强	智慧屏专有业务、穿戴专有业务、IoT 专有业务
硬件服务	硬件相关服务	位置服务、生物特征识别、穿戴专有硬件服务、IoT 专有硬件服务

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

【理解】系统服务层是"能力仓库"：手机、手表、车机各取所需。裁剪能力（可大可小）正是"统一 OS，弹性部署"的实现手段。注意系统基本能力子系统集不可按需裁剪——分布式能力是全局基座。

3.4 框架层

【原文】框架层为 HarmonyOS 应用开发提供了 ArkTS/JS/C/C++/Java 等多语言的用户程序框架，两种 UI 框架（适用于 ArkTS/JS 语言的方舟开发框架即 ArkUI、适用于 Java 语言的 Java UI 框架），以及各种软硬件服务对外开放的多语言框架 API。根据系统的组件化裁剪程度，HarmonyOS 设备支持的 API 也会有所不同。

【理解】框架层是"开发者直接接触的那一层"：

1. UI 框架：NEXT 语境下主推 ArkUI（声明式），Java UI 框架随 Java 能力退出历史舞台（旧文档仍可见）。
2. Ability 框架：应用组件（UIAbility/ExtensionAbility）的运行框架，属于 Ability Kit（程序框架服务）。
3. 多语言 API：同一套能力对不同语言开放，但设备裁剪程度决定 API 集合——这解释了为什么不同设备上部分 API 不可用。

3.5 应用层

【原文】（旧版描述）应用层包括系统应用和第三方非系统应用，应用由一个或多个 FA（Feature Ability）或 PA（Particle Ability）组成。

【原文】（NEXT 描述，见应用模型章节）应用由一个或多个 UIAbility / ExtensionAbility 组件组成，能力边界由 Stage 模型重新定义。

【理解】两版描述对照即可看出演进方向：FA（有 UI）/PA（无 UI，后台能力）的二分法，演进为 UIAbility（用户交互）/ ExtensionAbility（特定场景扩展） 的二分法。下文第 4 章详述。

---

4. 应用模型：Stage 模型（NEXT 核心）

4.1 什么是应用模型

【原文】应用模型是系统为开发者提供的应用程序所需能力的抽象提炼，它提供了应用程序必备的组件和运行机制。有了应用模型，开发者可以基于一套统一的模型进行应用开发。

【原文】目前主推且会长期演进的应用模型是从 API 9 开始支持的 Stage 模型。该模型提供了 AbilityStage 组件管理器和 WindowStage 窗口管理器，分别作为应用组件与窗口的"舞台"，故得名"Stage 模型"。

【原文】Stage 模型支持多个应用组件共享同一个 ArkTS 引擎实例，以及应用组件间的状态共享与对象调用，可以降低内存开销、提升开发效率，适用于复杂应用的开发。

4.2 Stage 模型 vs FA 模型（对照表）

【原文】随着应用模型的演进发展，从 API 7 开始支持的 FA 模型已经不再主推，当前 FA 模型主要用于 Lite Wearable 设备。

对比维度	FA 模型（旧）	Stage 模型（NEXT 主推）
支持起始	API 7	API 9
应用组件	PageAbility（UI）/ ServiceAbility（后台）/ DataAbility（数据共享）	UIAbility（UI）/ ExtensionAbility（特定场景扩展，如卡片、输入法）
引擎占用	每个应用组件独享一个 ArkTS 引擎实例	多个应用组件共享同一个 ArkTS 引擎实例
对象/状态共享	进程内不支持	组件间可方便共享对象和状态
内存占用	复杂应用内存开销大	显著降低内存开销
开发方式	导出匿名对象、固定入口文件，不可派生	面向对象，组件是类，可派生扩展
进程模型	主进程 + 渲染进程	主进程 + ExtensionAbility 进程 + 渲染进程
后台治理	弱	规范化后台进程管理，禁止随意驻留后台，防恶意行为
设计目标	简单场景	复杂应用、分布式场景、多设备多窗口

【理解】FA → Stage 的本质是从"轻量够用"走向"面向复杂应用"：共享引擎降低内存、OOP 提升可维护性、组件/窗口解耦支持多窗口形态、后台治理保护用户体验。面试高频题"Stage 模型相比 FA 模型有什么优势"，背这张表就够了。

4.3 Stage 模型基本概念

【原文】Stage 模型提供 UIAbility 和 ExtensionAbility 两种类型的组件，都有具体的类承载，支持面向对象的开发方式。

概念	官方定义（提炼）	一句话理解
UIAbility	包含 UI 的应用组件，主要用于和用户交互；生命周期只包含创建/销毁/前台/后台等状态，显示相关状态通过 WindowStage 事件暴露	“带界面的能力”，应用与用户交互的入口
ExtensionAbility	面向特定场景的应用组件；开发者不直接派生，而是使用其派生类	“特定场景的扩展”，如卡片、输入法、闲时任务
AbilityStage	每个 Entry/Feature 类型 HAP 在运行期都有一个 AbilityStage 实例；HAP 代码首次加载进进程时，系统先创建它	进程级/包级"舞台管家"，类似 Android 的 Application
WindowStage	每个 UIAbility 实例绑定一个 WindowStage，起到应用进程内窗口管理器作用，包含一个主窗口，为 ArkUI 提供绘制区域	窗口与组件解耦的关键，“无屏设备可裁剪窗口”
Context	Context 及其派生类向开发者提供运行期可调用的各种资源和能力；各组件有各自不同的 Context 子类，均继承自基类 Context	运行期"能力通行证"，不同组件拿到不同权限的 Context
ArkUI 页面	基于 ArkUI 框架构建的用户界面组件，可将不同 UI 组件组合实现复杂页面效果	UIAbility 展示与交互的载体
Application	应用在设备上的运行实例；由一个或多个 HAP 作为功能模块构成，可共享一个或多个 HSP 中的代码与资源	运行期动态实例
Bundle	应用在安装部署阶段的静态文件，包含所有 HAP、HSP 及相关资源；安装启动后形成运行期 Application	安装包（静态）↔ Application（动态）

【原文】ExtensionAbility 目前有用于卡片场景的 FormExtensionAbility、用于输入法场景的 InputMethodExtensionAbility、用于延时任务场景的 WorkSchedulerExtensionAbility 等多种派生类。ExtensionAbility 派生类实例由用户触发创建，并由系统管理生命周期。

【原文】三方应用开发者不能开发自定义服务，而需要根据自身的业务场景通过 ExtensionAbility 的派生类来实现。

【理解】AbilityStage 与 Application 的关系：AbilityStage 是每个 HAP 一个（运行期），Application 是每个应用一个（运行期）；一个 HAP 内的所有 UIAbility/ExtensionAbility 共用同一个 AbilityStage 实例。全局初始化（如日志、SDK 初始化）写在 AbilityStage.onCreate() 里。

4.4 应用模型的构成要素

【原文】应用模型的构成要素主要包含应用组件、进程模型、线程模型、任务管理模型以及应用配置文件。

要素	官方定义（提炼）
应用组件	应用的基本组成单位和运行入口；在不同状态间切换（生命周期），提供生命周期回调函数
进程模型	定义应用进程的创建和销毁方式，以及进程间的通信方式
线程模型	定义应用进程内线程的创建和销毁方式、主线程和 UI 线程的创建方式、线程间的通信方式
任务管理模型	定义任务（Mission）的创建和销毁方式，以及任务与组件间的关系（仅对系统应用开放）
应用配置文件	包含应用配置信息、应用组件信息、权限信息、开发者自定义信息等；在编译、分发、运行阶段分别提供给编译工具、应用市场和操作系统

【理解】任务管理模型"仅对系统应用开放"是 NEXT 的特色管控：三方应用的"最近任务"行为由系统统一治理。配置文件在 Stage 模型下是 app.json5（应用级：应用名、版本号、图标）与 module.json5（模块级：组件清单、权限、deviceTypes 等）两个文件，发布审核时这两个文件是合规检查的重点。

---

5. 进程模型与线程模型

5.1 进程模型：三种基本进程类型

【原文】应用运行态可能存在的进程类型：

进程类型	官方描述
主进程	默认情况下，应用中（同一 Bundle 名称）的所有 UIAbility 均运行在同一个独立进程（主进程）中
ExtensionAbility 进程	应用中同一类型的所有 ExtensionAbility 运行在一个独立进程中；UIExtensionAbility 可为每个实例配置独立进程
Render 进程	应用中的 Web 组件运行时，系统为之分配一个 Render 进程用于渲染

【原文】进程名称的命名无固定规则，与进程类型不存在直接关联，不能用于业务逻辑判断。一个进程可以包含多个 AbilityStage，一个 AbilityStage 可以包含多个 Ability。进程的生命周期与 Ability 生命周期息息相关：当进程内的所有 Ability 都退出后，进程才会走销毁流程。

5.2 进程模型：特殊进程类型（2in1 和 Tablet 设备）

类型	机制	配置方式
模块独立进程	多 HAP 应用中，不同 HAP 的 UIAbility 运行在不同进程	module.json5 的 isolationMode 配置为 isolationOnly / isolationFirst
动态指定进程	同一 HAP 中 UIAbility 实例按运行时状态动态分配进程（如每进程最多 5 个实例）	isolationProcess: true + 主控进程回调 onNewProcessRequest 返回进程标识字符串
静态指定进程	同一应用的 UIAbility / EmbeddedUIExtensionAbility 固定分配到指定进程	module.json5 中 abilities / extensionAbilities 标签的 process 字段；配置相同字符串则共处同一进程
子进程	开发者主动开启多进程做后台业务	调用 childProcessManager 接口创建；生命周期跟随父进程，不支持再创建子进程

【理解】进程模型回答了两个面试高频问题：① “ExtensionAbility 跑在哪？”——同类型 ExtensionAbility 共用一个独立进程（与 UIAbility 主进程隔离，防止卡片崩溃拖垮主界面）；② “怎么开多进程？”——静态配置 process 字段、动态 onNewProcessRequest、或 childProcessManager 创建子进程。

5.3 线程模型：三类线程

【原文】系统创建应用进程启动后，会默认创建一个主线程并进入消息循环，应用组件均运行在主线程上。

线程类型	职责/特点
主线程	执行 UI 绘制；管理主线程的 ArkTS 引擎实例（多个 UIAbility 组件运行其上）；管理其他线程的 ArkTS 引擎实例（TaskPool 任务创建/取消、Worker 启动/终止）；分发交互事件；处理应用代码回调（事件处理与生命周期管理）；接收 TaskPool 与 Worker 线程发送的消息
TaskPool 线程	用于执行耗时操作，支持设置调度优先级、负载均衡等功能，推荐使用；线程数量与生命周期由 TaskPool 统一管理
Worker 线程	用于执行耗时操作，支持线程间通信；生命周期由开发者自行维护

【原文】同一线程中存在多个组件（UIAbility 组件和 UI 组件都存在于主线程中）；Stage 模型中目前主要使用 EventHub 进行线程内通信（订阅、取消订阅、触发事件）。

【理解】主线程职责清单是高频考点：UI 绘制 + 引擎管理 + 事件分发 + 生命周期回调。耗时逻辑绝不能写主线程——用 TaskPool（推荐，自管理）或 Worker（自管生命周期）。TaskPool 与 Worker 的选择题：无状态批量任务用 TaskPool，需要长期驻留/主动通信用 Worker。

---

6. ArkUI 与 ArkTS 运行时

6.1 ArkUI：声明式 UI 开发框架

【原文】ArkUI 是一套构建分布式应用界面的声明式 UI 开发框架。它使用简洁的 UI 信息语法、丰富的 UI 组件、以及实时界面预览工具，提升 HarmonyOS 应用界面开发效率。只需使用一套 ArkTS API，就能在多个 HarmonyOS 设备上提供生动而流畅的用户界面体验。

【原文】UI 更新机制升级：ArkUI 通过编译器生成特定函数，将 UI 组件更新和数据变更进行细粒度绑定，UI 更新 Diff 算法从 COMPONENT 和 ELEMENT 树形结构对比升级为单节点 NODE 的函数式更新，大幅简化声明式开发范式的 UI 树形结构，优化 UI 组件布局渲染性能。

【原文】逻辑和 UI 分离：通过数据双向绑定机制传递页面变化逻辑，将跨端迁移和协同的流转步骤从 7 步简化为 2 步，跨端迁移和协同的开发代码量降低 40% 以上。

【原文】高级扩展：基于 XComponent 组件接入 C++ 自绘制引擎（如游戏引擎）；基于 Web 组件提供 HTML5/Web 渲染能力，满足游戏、相机、地图、浏览器等复杂应用场景。

【理解】ArkUI 的三大卖点：声明式（描述 UI 状态而非命令式操作）、细粒度 UI 更新（Diff 从树级降到节点级）、一套 API 多端渲染。开发范式上官方曾并行提供"声明式开发范式（ArkTS）“与"类 Web 开发范式（兼容 JS）”，NEXT 主推前者。

6.2 ArkTS 运行时（方舟运行时）

【原文】ArkTS 运行时是 HarmonyOS 上应用的默认语言运行时，支持 ArkTS、TS 和 JS 语言的字节码及相关标准库。提供解释器、AOT 和 JIT 高效执行方式，并通过 Node-API 实现完善的跨语言调用接口，支持多语言混合开发。

【原文】ArkTS Runtime 主要由四个子系统组成：

子系统	组成（提炼）
Core Subsystem	与语言无关的基础运行库：承载字节码的 File 组件、支持 Debugger 的 Tooling 组件、负责系统调用适配的 Base 库组件
Execution Subsystem	执行方舟字节码的解释器、快速路径内联缓存、文件模块化管理运行
Compiler Subsystem	Stub 编译器、基于 IR 的编译优化框架、AOT 静态编译器、JIT 动态编译器（实验中）
Runtime Subsystem	内存管理（对象分配器与垃圾回收器：CMS-GC / Partial-Compressing-GC）、DFX 与 profiling 分析工具、Actor 并发模型、ECMAScript 标准库 + container 容器库、Node-API 接口等

【理解】三个关键认知：

1. 运行时 ≠ 引擎：ArkTS 运行时是"编译器 + 解释器 + GC + 标准库 + 跨语言桥"的完整栈，不止一个 JS 引擎。
2. AOT 是性能底气：静态编译到方舟字节码，配合解释器与 JIT 按需优化，这是"流畅"体验的底层保障。
3. Node-API 打通 C++：需要高性能或复用现有 C/C++ 库时，通过 Node-API 混合开发（对应架构图中"多语言框架 API"）。

---

7. 关键技术特性：分布式

【原文】HarmonyOS 的分布式技术体系，硬件互助、资源共享依赖的关键技术包括分布式软总线、分布式设备虚拟化、分布式数据管理、分布式任务调度等：

技术	官方定位	典型场景
分布式软总线	手机、平板、穿戴、智慧屏、车机等分布式设备的通信基座；为设备间互联互通提供统一分布式通信能力，实现无感发现和零等待传输；开发者无需关注组网方式与底层协议	手机碰一碰连接烤箱按菜谱烹调；多屏联动课堂
分布式设备虚拟化	不同设备资源融合、设备管理、数据处理，多种设备共同形成超级虚拟终端；按任务类型匹配能力合适的执行硬件	家务时视频通话，智慧屏的屏/摄像头/音箱虚拟化为本地资源
分布式数据管理	基于软总线实现应用与用户数据的分布式管理；用户数据不再与单一物理设备绑定，业务逻辑与数据存储分离	手机文档投屏到智慧屏协同编辑，状态实时同步
分布式任务调度	构建统一分布式服务管理（发现、同步、注册、调用）机制，支持跨设备应用的远程启动、远程调用、远程连接、迁移；按设备能力、位置、业务状态、用户习惯选设备运行	导航从手机迁移到车机再回手机；外卖订单迁移到手表

【原文】一次开发，多端部署：HarmonyOS 提供用户程序框架、Ability 框架以及 UI 框架，支持多终端业务逻辑和界面逻辑复用；UI 框架提供丰富的多态控件，支持栅格化布局与多种响应式布局方案，满足不同屏幕的界面适配。

【原文】统一 OS，弹性部署：通过组件化和小型化设计，支持多终端按需弹性部署——组件可有可无（按硬件形态选组件）、组件可大可小（按资源情况配功能集）、平台可大可小（编译链自动生成组件依赖，选图形框架自动带图形引擎）。

【理解】四条分布式技术有一条清晰依赖链：软总线是底座 → 数据管理/设备虚拟化建在底座上 → 任务调度综合三者做跨设备编排。学习时可画一张"总线 → 数据 → 虚拟化 → 调度"的依赖图加深记忆。

---

8. 自学路线建议

【理解】按"先骨架、后血肉、再实践"三步走：

阶段	内容	对应本文章节	自学动作
第 1 步：系统骨架	四层架构、每层职责、裁剪机制	第 2、3 章	能默画四层架构图；能说出每个子系统集的典型组成
第 2 步：应用模型	Stage 模型、组件、进程/线程	第 4、5 章	对照官方图理解 AbilityStage/UIAbility/ExtensionAbility/WindowStage/Context 关系；背下进程、线程三类型
第 3 步：开发技术	ArkUI、ArkTS 运行时、分布式	第 6、7 章	在 DevEco Studio 建一个空工程，逐字段读 app.json5 / module.json5；跑通 UIAbility 生命周期日志
第 4 步：进阶闭环	官方文档顺藤摸瓜	第 10 章索引	从 UIAbility 生命周期、启动模式、任务调度等官方专题文档继续深入

【理解】实践建议三件套：

1. 建工程读配置：新建空工程后，逐字段查 app.json5、module.json5 的官方配置说明，这是理解"配置文件要素"最快的路径。
2. 打日志看生命周期：在 UIAbility 的 onCreate / onWindowStageCreate / onForeground / onBackground / onDestroy 打日志，前台后台切换观察调用顺序。
3. 开多进程实验：按 5.2 节配置 isolationMode / process 字段，用 hdc shell ps -p <pid> -T 观察进程与线程，把抽象模型落到可观测的真实系统上。

---

9. 理解要点速查（面试向）

1. 四层架构：内核层（多内核 + KAL + HDF）→ 系统服务层（四大子系统集，可裁剪）→ 框架层（ArkUI/Ability/多语言 API）→ 应用层（系统应用 + 三方应用）。
2. 系统功能组织："系统 > 子系统 > 功能/模块"逐级展开，按需裁剪。
3. Stage 模型命名由来：AbilityStage（组件舞台）+ WindowStage（窗口舞台）。
4. 共享引擎：Stage 模型多个应用组件共享同一 ArkTS 引擎实例 → 省内存、可共享状态；FA 模型每组件独享引擎。
5. 两大组件：UIAbility（带 UI、用户交互）；ExtensionAbility（特定场景扩展，必须用派生类，三方应用不能自定义服务）。
6. AbilityStage vs Application：AbilityStage 每 HAP 一个，Application 每应用一个；AbilityStage 是进程内首个被创建的实例。
7. 进程三类型：主进程（所有 UIAbility）、ExtensionAbility 进程（同类共享独立进程）、Render 进程（Web 组件渲染）。
8. 线程三类型：主线程（UI 绘制 + 引擎管理 + 事件分发 + 生命周期）、TaskPool（推荐，自管理）、Worker（自管生命周期）。
9. 后台治理：Stage 模型规范化后台进程管理，应用不能随意驻留后台，防恶意行为。
10. ArkTS 运行时四子系统：Core / Execution / Compiler / Runtime；AOT + JIT + 解释器；Node-API 桥接 C++。
11. ArkUI 更新机制：编译器生成特定函数，数据变更细粒度绑定到单节点 NODE 的函数式更新。
12. 分布式依赖链：分布式软总线（底座）→ 分布式数据管理 / 设备虚拟化 → 分布式任务调度（跨设备编排）。

---

10. 官方文档索引

主题	官方文档
系统定义与技术架构	系统定义 - HarmonyOS 概述
技术特性（分布式等）	技术特性 - HarmonyOS 概述
Stage 模型开发概述	Stage 模型开发概述
应用模型概述	应用模型概述 - 应用模型
进程模型（Stage）	进程模型
线程模型（Stage）	线程模型
ArkTS 运行时概述	ArkTS 运行时概述
ArkUI 框架	ArkUI - 华为开发者联盟
UIAbility 组件	UIAbility 组件概述
ExtensionAbility 组件	ExtensionAbility 组件概述
TaskPool 与 Worker 对比	TaskPool 和 Worker 的对比

说明：官方文档站持续演进，URL 带 -V13 等版本后缀的页面为对应 API 版本的文档快照；不带后缀的为当前最新版。学习时优先看最新版，对照快照理解演进。