!2500 更新stage模型综述文档

Merge pull request !2500 from JayLeeHW/update

zh-cn/application-dev/ability/Readme-CN.md

@@ -8,6 +8,7 @@
    - [DataAbility开发指导](fa-dataability.md)
    - [FA卡片开发指导](fa-formability.md)
  - Stage模型
+   - [Stage模型综述](stage-brief.md)
    - [Ability开发指导](stage-ability.md)
    - [ServiceExtensionAbility开发指导](stage-serviceextension.md)
    - [跨端迁移开发指导](stage-ability-continuation.md)

zh-cn/application-dev/ability/ability-brief.md

@@ -4,7 +4,17 @@
 
 ​        Ability框架模型结构具有两种形态。第一种形态为FA模型，API 8及其更早版本的应用程序只能使用FA模型进行开发， FA模型将Ability分为FA（Feature Ability）和PA（Particle Ability）两种类型，其中FA支持Page Ability，PA支持Service Ability和Data Ability；从API9开始，Ability框架引入了Stage模型作为第二种应用形态，Stage模型将Ability分为PageAbility和ExtensionAbility两大类，其中ExtensionAbility又被扩展为ServiceExtensionAbility、FormExtensionAbility、DataShareExtensionAbility等等一系列ExtensionAbility，以便满足更多的使用场景。
 
-​         Stage模型的设计，主要是为了方便开发者更加方便地开发出分布式环境下的复杂应用。对于开发者而言，两种模型的主要区别在于：
+​        Stage模型的设计，主要是为了方便开发者更加方便地开发出分布式环境下的复杂应用。下表给出了两种模型在设计上的差异：
+
+| 对比           | FA模型                                                       | Stage模型                                                |
+| -------------- | ------------------------------------------------------------ | -------------------------------------------------------- |
+| 开发方式       | 提供类Web的 api，UI开发与Stage模型一致。                     | 提供面向对象的开发方式，UI开发与FA模型一致。             |
+| 引擎实例       | 每个进程内的每个Ability独享一个JS VM引擎实例。               | 每个进程内的多个Ability实例共享一个JS VM引擎实例。       |
+| 进程内对象共享 | 不支持。                                                     | 支持。                                                   |
+| 包描述文件     | 使用config.json描述HAP包和组件信息，组件必须使用固定的文件名。 | 使用module.json描述HAP包和组件信息，可以指定入口文件名。 |
+| 组件           | 提供PageAbility(页面展示)，ServiceAbility(服务)，DataAbility(数据分享), FormAbility(卡片)。 | 提供Ability(页面展示)、Extension(基于场景的服务扩展)。   |
+
+​        对于开发者而言，两种模型的主要区别在于：
 
 * Ability类型存在差异，接口使用上也存在一定的区别；
 

zh-cn/application-dev/ability/stage-brief.md

-# Stage模型综述
\ No newline at end of file
+# Stage模型综述
+
+### 设计思想
+
+​        Stage模型的设计，主要是为了解决FA模型无法解决的开发场景问题，方便开发者更加方便地开发出分布式环境下的复杂应用。
+
+​        Stage模型的设计思想如下图所示。
+
+![stagedesign](figures/stagedesign.png)
+
+​        Stage模型的设计基于如下三个出发点：
+
+- **应用的能力与系统总体功能和功耗的平衡**
+
+  ​         在系统运行过程中，前台应用的资源占用会被优先保障，与此同时由于应用能力不同而产生的功耗，也需要符合系统整体功耗的要求。Stage模型通过Ability与UI分离、严格的后台管控、基于场景的服务机制及单进程模型来达成这种应用能力与整体系统功耗的平衡。
+
+- **原生支持组件级的迁移和协同**
+
+  ​        OpenHarmony是原生支持分布式的操作系统，应用框架需要从架构设计上使得组件更易于实现迁移和协同。Stage模型通过Ability与UI分离及UI展示与服务能力合一等模型特性，实现这一设计目标。
+
+- **支持多设备和多窗口形态的特点**
+
+  ​        为了支持多种设备形态和更易于实现多种不同的窗口形态，需要组件管理服务和窗口管理服务在架构层面上是解耦的，从而方便裁剪，更有利于定制不同的窗口形态。Stage模型通过重新定义了Ability生命周期定义和设计组件管理服务和窗口管理服务的单项依赖解决这一问题。
+
+
+### 基本概念
+
+​        下图展示了Stage模型中的基本概念。
+
+![stageconcept](figures/stageconcept.png)
+
+-  **HAP**：即HarmonyAbilityPackage，OpenHarmony应用编译、分发、加载的基本单位，也成为module，每个HAP都有一个应用内唯一的名称，成为moduleName；
+-  **Bundle**：通过appid标识的OpenHarmony应用，Bundle可以包含多个HAP，每个应用都有一个bundleName，但是bundleName并不能唯一标识一个应用，appid中包含bundleName以及其他的更多信息，能够唯一标识一个应用；
+-  **AbilityStage**：对应HAP的运行期类，在HAP首次加载到进程中时创建，运行期开发者可见；
+-  **Application**：对应Bundle的运行期类，运行期开发者不可见；
+-  **Context**：提供运行期开发者可以调用的各种能力，Ability组件和各种ExtensionAbility都有各自不同的context类，他们都继承自基类Context，基类提供包名、moduleName、路径等信息；
+-  **Ability**：提供生命周期回调，持有AbilityContext，支持组件迁移/协同;
+-  **ExtensionAbility**：基于场景的服务扩展能力统称，系统定义了多种基于场景的ExtensionAbility类，它们持有各自的ExtensionAbilityContext;
+-  **WindowStage**：本地窗口管理器；
+-  **Window**：窗口 管理器管理的基本单元，持有一个ArkUI引擎实例；
+- **Ark UI Page**：Ark声明式UI展示。
+
+
+### 生命周期
+
+​        Ability及AbilityStage的生命周期是应用的基本流程中最重要的概念。在[Ability框架概述](ability-brief.md)中，给出了FA模型与Stage模型的生命周期对比，这里重点对Ability生命周期切换以及和AbilityStage、WindowStage之间的调度关系进行介绍。
+
+![stageabilitylifecyclecallback](figures/stageabilitylifecyclecallback.png)
+
+​        为了实现多设备形态上的裁剪和多窗口的可扩展性，OpenHarmony对组件管理和窗口管理进行了解耦。Stage模型定义Ability组件的生命周期，只包含创建、销毁、前后台等状态，而将与界面相关内容强相关的获焦、失焦状态放在WindowStage之中，从而实现Ability与窗口之间的弱耦合；在服务侧，窗口管理服务依赖于组件管理服务，前者通知后者前后台变化，这样组件管理服务仅感知前后台变化，不感知焦点变化。
+
+### ExtensionAbility机制
+
+​        不同于用于页面展示的Ability，ExtensionAbility提供的是一种受限的服务运行环境。ExtensionAbility具有如下特点：
+
+- 独立于主进程的单独进程运行，与主进程无IPC，共享一个存储沙箱；
+
+- 独立的Context提供基于业务场景的api能力；
+
+- 由系统触发创建，应用不能直接创建；
+
+- ExtensionAbility和进程的生命周期受系统管理。
+
+​        下图以卡片服务使用场景为例进行展示，系统提供了FormExtensionAbility基类，开发者通过派生提供卡片的具体信息。FormExtensionAbility实例及其所在的ExtensionAbility进程的整个生命周期，都是由系统服务FormManagerService进行管理。
+
+![ExtensionAbility](figures/ExtensionAbility.png)
+
+### 进程模型
+
+​        OpenHarmony系统中的应用均满足单进程模型。所谓的单进程模型，是指不允许应用配置多进程，应用中所有的进程都是由系统创建和管理的。每个应用至多并存三个进程：
+
+- 主进程：运行所有的Ability组件、页面和业务逻辑；
+
+- Extension进程：运行应用中的ExtensionAbility派生类，该进程由系统中的特定场景的服务管理其生命周期；
+
+- Render进程：专门为webview创建的进程，用于加载webview的渲染库。
+
+  下图展示了应用的进程模型。
+
+  ![stageprocessmodel](figures/stageprocessmodel.png)