!11400 Modify Ability Dev Doc

Merge pull request !11400 from 强波/modify_ability_doc

!11400 Modify Ability Dev Doc
Merge pull request !11400 from 强波/modify_ability_doc
6d7d2355 · openharmony_ci · Gitee · 1638aa52 · a631e9fa · 6d7d2355
3 changed file
--- a/zh-cn/application-dev/ability/ability-brief.md
+++ b/zh-cn/application-dev/ability/ability-brief.md
 # Ability框架概述

-Ability是应用所具备能力的抽象，也是应用程序的重要组成部分。Ability是系统调度应用的最小单元，是能够完成一个独立功能的组件。一个应用可以包含一个或多个Ability。
+Ability是OpenHarmony系统对应用的基本抽象。
+
+每个Ability是完成独立业务的应用组件，是系统调度应用的最小单元。一个应用可以包含一个或多个Ability。

 Ability框架模型具有两种形态：

- 第一种形态为FA模型。API 8及其更早版本的应用程序只能使用FA模型进行开发。FA模型将Ability分为FA（Feature Ability）和PA（Particle Ability）两种类型，其中FA支持Page Ability，PA支持Service Ability、Data Ability、以及FormAbility。
- 第二种形态为Stage模型。从API 9开始，Ability框架引入了Stage模型作为第二种应用框架形态，Stage模型将Ability分为PageAbility和ExtensionAbility两大类，其中ExtensionAbility又被扩展为ServiceExtensionAbility、FormExtensionAbility、DataShareExtensionAbility等一系列ExtensionAbility，以便满足更多的使用场景。
+- 第一种形态称为FA模型。API 8及其更早版本的应用只能使用FA模型。FA模型将Ability分为Page Ability、Service Ability以及Data Ability几种类型。
+- 第二种形态称为Stage模型，这是自API 9新增的模型。Stage模型将Ability分为UIAbility和ExtensionAbility两大类，其中ExtensionAbility又被扩展为ServiceExtensionAbility、FormExtensionAbility、DataShareExtensionAbility等一系列ExtensionAbility，以便满足更多的使用场景。
+
+自API 9开始，Stage模型是主推的开发模型。

 Stage模型的设计，主要是为了开发者更加方便地开发出分布式环境下的复杂应用。下表给出了两种模型在设计上的差异：

 | 对比           | FA模型                                                       | Stage模型                                                |
 | -------------- | ------------------------------------------------------------ | -------------------------------------------------------- |
-| 开发方式       | 提供类Web的API，UI开发与Stage模型一致。                     | 提供面向对象的开发方式，UI开发与FA模型一致。             |
-| 引擎实例       | 每个进程内的每个Ability实例独享一个JS VM引擎实例。               | 每个进程内的多个Ability实例共享一个JS VM引擎实例。       |
+| 应用组件开发方式       | 类Web的开发方式。                     | 面向对象的开发方式。             |
+| 引擎实例       | 每个Ability实例独占一个虚拟机实例。               | 多个Ability实例可以共享同一个虚拟机实例。       |
 | 进程内对象共享 | 不支持。                                                     | 支持。                                                   |
-| 包描述文件     | 使用config.json描述HAP包和组件信息，组件必须使用固定的文件名。 | 使用module.json5描述HAP包和组件信息，可以指定入口文件名。 |
-| 组件           | 提供PageAbility(页面展示)，ServiceAbility(服务)，DataAbility(数据分享)以及FormAbility(卡片)。 | 提供Ability(页面展示)、Extension(基于场景的服务扩展)。   |
-
+| 包描述文件     | 使用`config.json`描述HAP包和组件信息，组件必须使用固定的文件名。 | 使用`module.json5`描述HAP包和组件信息，可以指定入口文件名。 |
+| 组件           | 提供PageAbility(页面展示)，ServiceAbility(服务)，DataAbility(数据分享)以及FormAbility(卡片)。 | 提供UIAbility(页面展示)、Extension(基于场景的服务扩展)。   |
+
 除了上述设计上的差异外，对于开发者而言，两种模型的主要区别在于：

 * Ability类型存在差异；
@@ -29,7 +33,15 @@ Stage模型的设计，主要是为了开发者更加方便地开发出分布式

 两种模型的基本介绍，详见[FA模型综述](fa-brief.md)及[Stage模型综述](stage-brief.md)。

-## 相关实例
-针对Ability开发，有以下相关实例可供参考：
+## 相关实例
+
+### FA 模型
+
+- [Page内和Page间导航跳转（ArkTS）（API8）](https://gitee.com/openharmony/codelabs/tree/master/Ability/PageAbility)
+
+### Stage 模型

- [Page内和Page间导航跳转（ArkTS）（API8）](https://gitee.com/openharmony/codelabs/tree/master/Ability/PageAbility)
\ No newline at end of file
+- [Stage模型介绍（ArkTS）（API9）](https://gitee.com/openharmony/applications_app_samples/tree/master/ability/StageModel)
+- [窗口扩展（ArkTS）（API9）](https://gitee.com/openharmony/applications_app_samples/tree/master/ability/WindowExtAbility)
+- [系统任务管理（ArkTS）（API9）](https://gitee.com/openharmony/applications_app_samples/tree/master/ability/MissionManager)
+- [仿桌面应用（ArkTS）（API9）](https://gitee.com/openharmony/applications_app_samples/tree/master/ability/Launcher)
--- a/zh-cn/application-dev/ability/fa-brief.md
+++ b/zh-cn/application-dev/ability/fa-brief.md
 # FA模型综述

 ## 整体架构
-OpenHarmony用户程序的开发本质上就是开发Ability。OpenHarmony系统是通过对Ability调度，结合系统提供的一致性调度契约对Ability进行生命周期管理，从而实现对用户程序的调度。

-Ability框架在API 8及更早版本使用FA模型。FA模型中Ability分为PageAbility、ServiceAbility、DataAbility、FormAbility几种类型。其中：
- PageAbility是具备ArkUI实现的Ability，是用户具体可见并可以交互的Ability实例。
- ServiceAbility也是Ability一种，但是没有UI，提供其他Ability调用自定义的服务，在后台运行。
- DataAbility也是没有UI的Ability，提供其他Ability进行数据的增删查服务，在后台运行。
- FormAbility是卡片Ability，是一种界面展示形式。
+OpenHarmony应用的开发，是以Ability为入口展开的。
+
+对于Ability的开发，通常是以生命周期的回调处理为中心。
+
+Ability框架在API 8及更早版本仅支持FA模型。FA模型中Ability分为PageAbility、ServiceAbility、DataAbility、FormAbility几种类型。其中：
+- PageAbility使用ArkUI实现用户界面，是用户可见并可以交互的Ability实例。
+- ServiceAbility也是Ability一种，但是没有用户界面。它提供了其他Ability调用的自定义服务，ServiceAbility在后台运行。
+- DataAbility也是没有界面的Ability，提供其他Ability进行数据的增删查服务，它同样在后台运行。
+- FormAbility是实现卡片的Ability，卡片是OpenHarmomny系统上的一种界面展示形式。
+
+> 注：自API 9开始，Stage模型是主推的开发模型。

 ## 生命周期

-在所有Ability中，PageAbility因为具有界面，也是应用的交互入口，因此生命周期更加复杂。
+在所有Ability中，PageAbility因为具有界面，也是应用的交互入口，因此其生命周期更加复杂。
 **PageAbility生命周期回调如下图所示：**

 ![fa-pageAbility-lifecycle](figures/fa-pageAbility-lifecycle.png)

-其他类型Ability的生命周期可参考PageAbility生命周期去除前后台切换以及`onShow`的部分进行理解。
-开发者可以在 `app.js/app.ets` 中重写生命周期函数，在对应的生命周期函数内处理应用相应逻辑。
-
-目前`app.js`环境中仅支持onCreate和onDestroy回调，`app.ets`环境支持全量生命周期回调。
+其他类型Ability的生命周期可参考PageAbility生命周期去除前后台切换以及`onShow`及`onHide`的部分来理解。
+开发者可以在 `app.js/app.ets` 中重写生命周期函数，在对应的生命周期回调内处理应用的相应逻辑。

+目前`app.js`仅支持`onCreate`和`onDestroy`回调，但`app.ets`支持全量生命周期回调。

 ## 进程线程模型
-应用独享独立进程，Ability独享独立线程，应用进程在Ability第一次启动时创建，并为启动的Ability创建线程，应用启动后再启动应用内其他Ability，会为每一个Ability创建相应的线程。每个Ability绑定一个独立的JSRuntime实例，因此Ability之间是隔离的。
+
+每个应用运行在不同的进程中，在FA模型中，每个Ability运行在独立的虚拟机中。
+
+应用进程在Ability启动时创建，此时会为Ability创建相应的线程。当一个应用有多个Ability时，每一个Ability在独立线程中运行。在FA模型中，每个Ability绑定一个独立的虚拟机实例，因此Ability之间是隔离的。

 ![fa-threading-model](figures/fa-threading-model.png)


--- a/zh-cn/application-dev/ability/stage-brief.md
+++ b/zh-cn/application-dev/ability/stage-brief.md
@@ -2,93 +2,98 @@

 ## 设计思想

-        Stage模型的设计，主要是为了解决FA模型无法解决的开发场景问题，方便开发者更加方便地开发出分布式环境下的复杂应用。
+Stage模型的设计，是为了提供给开发者一个更好的开发方式，更好的适用于多设备、分布式场景。

-        Stage模型的设计思想如下图所示。
+Stage模型的设计思想如下图所示。

 ![stagedesign](figures/stagedesign.png)

-        Stage模型的设计基于如下三个出发点：
+Stage模型的设计基于如下三个出发点：

- **应用的能力与系统总体功能和功耗的平衡**
+- **应用进程的有序管理**

-           在系统运行过程中，前台应用的资源占用会被优先保障，与此同时由于应用能力不同而产生的功耗，也需要符合系统整体功耗的要求。Stage模型通过Ability与UI分离、严格的后台管控、基于场景的服务机制及单进程模型来达成这种应用能力与整体系统功耗的平衡。
+随着设备的内存越来越大，系统中同时运行的进程数量也越来越多。当数百个进程同时运行时，如果没有有效的管理措施，则系统整体的功耗和性能将无法得到保证。Stage模型中，通过短时任务、长时任务、托管任务和延迟任务四种方法对后台进程做了有序约束。这样做使得前台进程的资源得以保障，最终能获得更好的用户体验。

- **原生支持组件级的迁移和协同**
+- **原生支持跨端迁移和多端协同**

-          OpenHarmony是原生支持分布式的操作系统，应用框架需要从架构设计上使得组件更易于实现迁移和协同。Stage模型通过Ability与UI分离及UI展示与服务能力合一等模型特性，实现这一设计目标。
+OpenHarmony是原生分布式的操作系统，应用框架需要从架构设计上使得组件更易于实现跨端迁移和多端协同。Stage模型通过Ability与UI分离及UI展示与服务能力合一等模型特性，实现这一设计目标。

- **支持多设备和多窗口形态的特点**
-
-          为了支持多种设备形态和更易于实现多种不同的窗口形态，需要组件管理服务和窗口管理服务在架构层面上是解耦的，从而方便裁剪，更有利于定制不同的窗口形态。Stage模型通过重新定义了Ability生命周期定义和设计组件管理服务和窗口管理服务的单向依赖解决这一问题。
+- **支持多种设备的不同窗口形态**

+Stage模型重新定义了Ability的生命周期。系统在架构上，将应用组件管理服务和窗口管理服务进行了彼此解耦，这样做可以方便的针对特定设备进行适配，以实现出不同的窗口形态。

 ## 基本概念

-        下图展示了Stage模型中的基本概念。
+下图展示了Stage模型中的基本概念。

 ![stageconcept](figures/stageconcept.png)

-  **HAP**：即HarmonyAbilityPackage，OpenHarmony应用编译、分发、加载的基本单位，也称为module，每个HAP都有一个应用内唯一的名称，称为moduleName；
+-  **HAP**：OpenHarmony应用编译、分发、加载的基本单位。与开发态的module一一对应。在应用内，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类，它们持有各自的ExtensionContext;
+-  **AbilityStage**：对应HAP的运行期对象，在HAP首次加载到进程中时创建，运行期开发者可见；
+-  **Application**：对应Bundle的运行期对象，运行期开发者不可见；
+-  **Context**：提供运行期开发者可以调用的各种能力，Ability组件和各种ExtensionAbility都有各自不同的Context类，他们都继承自基类Context，基类提供包名、moduleName、路径等信息；
+-  **Ability**：提供生命周期回调，持有AbilityContext，支持组件的跨端迁移和多端协同;
+-  **ExtensionAbility**：基于场景的扩展能力统称，系统定义了多种场景的ExtensionAbility类，它们持有各自的ExtensionContext;
 -  **WindowStage**：本地窗口管理器；
-  **Window**：窗口 管理器管理的基本单元，持有一个ArkUI引擎实例；
-  **ArkUI Page**：方舟开发框架页面。
+-  **Window**：应用窗口，持有一个ArkUI引擎实例；
+-  **ArkUI Page**：基于ArkUI开发的用户界面。


 ## 生命周期

-        Ability及AbilityStage的生命周期是应用的基本流程中最重要的概念。在[Ability框架概述](ability-brief.md)中，给出了FA模型与Stage模型的生命周期对比，这里重点对Ability生命周期切换以及和AbilityStage、WindowStage之间的调度关系进行介绍。
+AbilityStage及Ability是关于应用生命周期的关键对象。
+
+在[Ability框架概述](ability-brief.md)中，给出了FA模型与Stage模型的生命周期对比，因此这里仅对Ability生命周期切换以及和AbilityStage、WindowStage之间的调度关系进行介绍。

 ![stageabilitylifecyclecallback](figures/stageabilitylifecyclecallback.png)

-        为了实现多设备形态上的裁剪和多窗口的可扩展性，OpenHarmony对组件管理和窗口管理进行了解耦。Stage模型定义Ability组件的生命周期，只包含创建、销毁、前后台等状态，而将与界面相关内容强相关的获焦、失焦状态放在WindowStage之中，从而实现Ability与窗口之间的弱耦合；在服务侧，窗口管理服务依赖于组件管理服务，前者通知后者前后台变化，这样组件管理服务仅感知前后台变化，不感知焦点变化。
+为了实现多设备形态上的适配和多窗口的扩展，OpenHarmony对组件管理和窗口管理进行了解耦。
+
+Stage模型定义Ability组件的生命周期，只包含创建、销毁、前后台等状态，而将与界面强相关的获焦、失焦状态都放在WindowStage之中，从而实现Ability与窗口之间的弱耦合；在服务侧，窗口管理服务依赖于组件管理服务，前者通知后者前后台变化，这样组件管理服务仅感知前后台变化，不感知焦点变化。

-	需要注意的是，在Ability中存在两个与WindowStage相关的生命周期状态onWindowStageCreate和onWindowStageDestroy，这两个生命周期状态的变化仅存在于具有窗口显示能力的设备中。前者表示WindowStage已经创建完成，开发者可以通过执行loadContent的操作设置Ability需要加载的页面；后者在WindowStage销毁后调用，从而便于开发者对资源进行释放。
+需要注意的是，在Ability中存在两个与WindowStage相关的生命周期状态onWindowStageCreate和onWindowStageDestroy，这两个生命周期状态的变化仅存在于具有显示能力的设备中。前者表示WindowStage已经创建完成，开发者可以通过执行loadContent的操作设置Ability需要加载的页面；后者在WindowStage销毁后调用，以便开发者对资源进行释放。


 ## Ability组件实例与任务

-        Ability组件有三种启动类型：
-
-+ **Singleton**：应用进程中只存在一个该类型的Ability实例，如下图Ability1；
-
-+ **Standard**：每次startAbility调用，都会在应用进程中创建一个该类型的实例，如下图Ability2的两个实例；
+Ability组件有三种启动类型：

-+ **Specified**：允许开发者在系统创建Ability实例之前，为该实例创建一个key，后续每次创建该类型的Ability实例都会询问应用使用哪个key对应的Ability实例，来响应startAbility请求，如下图Ability3。
+* **Singleton**：应用进程中只存在一个该类型的Ability实例，如下图Ability1；
+* **Standard**：每次startAbility调用，都会在应用进程中创建一个该类型的实例，如下图Ability2的两个实例；
+* **Specified**：允许开发者在系统创建Ability实例之前，为该实例创建一个key，后续每次创建该类型的Ability实例都会询问应用使用哪个key对应的Ability实例，来响应startAbility请求，如下图Ability3。

-        每个Ability实例都对应了一个Launcher Recent中看到的Mission(任务)。
+每个Ability实例都对应了一个近期任务中的Mission(任务)。

-        每个Ability实例对应的Mission都留有该Ability实例的快照，Ability实例销毁后，Mission中的会保留Ability的类的信息和快照，直到用户删除，或者超过存储上限。
+每个Ability实例对应的Mission都留有该Ability实例的快照，Ability实例销毁后，Mission中会继续保留Ability的类的信息和快照，直到用户删除，或者超过存储上限。

 ![AbilityComponentInstanceMission](figures/AbilityComponentInstanceMission.png)

 ## ExtensionAbility机制

-        不同于用于页面展示的Ability，ExtensionAbility提供的是一种受限的服务运行环境。ExtensionAbility具有如下特点：
+不同于页面展示的Ability，ExtensionAbility提供的是一种受限的运行环境。
+
+ExtensionAbility组件具有如下特点：

- 独立于主进程的单独进程运行，与主进程无IPC，共享一个存储沙箱；
+- 运行在独立于主进程的单独进程中，与主进程无IPC，但共享一个存储沙箱；

- 独立的Context提供基于业务场景的api能力；
+- 独立的Context提供基于相应业务场景的API能力；

 - 由系统触发创建，应用不能直接创建；

 - ExtensionAbility和进程的生命周期受系统管理。

-        下图以卡片服务使用场景为例进行展示，系统提供了FormExtensionAbility基类，开发者通过派生提供卡片的具体信息。FormExtensionAbility实例及其所在的ExtensionAbility进程的整个生命周期，都是由系统服务FormManagerService进行管理。
+下图以卡片使用场景为例进行展示。系统提供了FormExtensionAbility基类，开发者通过派生提供卡片的具体信息。FormExtensionAbility实例及其所在的ExtensionAbility进程的整个生命周期，都是由系统服务FormManagerService进行管理。

 ![ExtensionAbility](figures/ExtensionAbility.png)

 ## 进程模型

-        OpenHarmony系统中的应用均满足单进程模型。所谓的单进程模型，是指不允许应用配置多进程，应用中所有的进程都是由系统创建和管理的。每个应用至多并存三类进程：
+OpenHarmony系统对于应用进程是有强管控策略的。对于开发者来说，没有自行配置多进程的能力。应用的所有进程都是由系统创建和管理的。
+
+每个应用的进程可以分为三类：

- 主进程：运行所有的Ability组件、页面和业务逻辑；
+- 主进程：运行UIAbility组件、页面和业务逻辑；

 - Extension进程：运行应用中的ExtensionAbility派生类，该进程由系统中的特定场景的服务管理其生命周期；