舍友不在寝，一个人偷偷学HarmonyOS应用开发之Ability以及Stage模型和FA模型-CSDN博客

本文链接：https://blog.csdn.net/2301_79624024/article/details/140527951

前言

“各位看官，咱们今天来聊一聊这HarmonyOS，哎呀，这可是个了不得的操作系统啊，现如今在科技江湖上那也是赫赫有名。不过，咱们都是明白人，知道要想学好这门手艺，基础可是万万少不得的。就好比是练武之人，得先扎好马步，才能修炼上乘武功不是？

今儿个，我那舍友刚好不在，我就借这个机会，跟大家伙儿好好唠唠这HarmonyOS的开篇之作——Ability中的应用模型。说到这Ability，那可是大有来头。它是HarmonyOS应用开发的核心概念之一，简单来说，就是应用所具备的能力。

但是光有能力不够啊，我们怎样写出他们的能力呢，这就不得不提到两个特别重要的应用模型，一个是FA模型，另一个是Stage模型。

各位看官，那我们就闲言少叙，书归正传，这一章，您可仔细听好了

一、 Ability概述

Ability是应用具备能力的抽象，是应用的重要组成部分

1、单Ability和多Ability

一个应用可以具备多种能力，也就是包含多个Ability。HarmonyOS支持应用以Ability为单位进行部署

2、 HarmonyOS应用模型

OpenHarmony应用模型的构成要素包括：应用组件、应用进程模型、应用线程模型、应用任务管理模型、应用配置文件五个部分。

应用组件：应用组件是应用的基本组成单位，是应用的运行入口。用户启动、使用和退出应用过程中，应用组件会在不同的状态间切换，这些状态称为应用组件的生命周期。应用组件提供生命周期的回调函数，开发者通过应用组件的生命周期回调感知应用的状态变化。应用开发者在编写应用时，首先需要编写的就是应用组件，同时还需编写应用组件的生命周期回调函数，并在应用配置文件中配置相关信息。这样，操作系统在运行期间通过配置文件创建应用组件的实例，并调度它的生命周期回调函数，从而执行开发者的代码。
应用进程模型：应用进程模型定义应用进程的创建和销毁方式，以及进程间的通信方式。
应用线程模型：应用线程模型定义应用进程内线程的创建和销毁方式、主线程和UI线程的创建方式、线程间的通信方式。
应用任务管理模型：应用任务管理模型定义任务（Mission）的创建和销毁方式，以及任务与组件间的关系。所谓任务，即用户使用一个应用组件实例的记录。每次用户启动一个新的应用组件实例，都会生成一个新的任务。例如，用户启动一个视频应用，此时在“最近任务”界面，将会看到视频应用这个任务，当用户点击这个任务时，系统会把该任务切换到前台，如果这个视频应用中的视频编辑功能也是通过应用组件编写的，那么在用户启动视频编辑功能时，会创建视频编辑的应用组件实例，在“最近任务”界面中，将会展示视频应用、视频编辑两个任务。
应用配置文件：应用配置文件中包含应用配置信息、应用组件信息、权限信息、开发者自定义信息等，这些信息在编译构建、分发和运行阶段分别提供给编译工具、应用市场和操作系统使用。

二、 FA模型

FA模型是HarmonyOS早期版本（API 8 及更早版本开始支持的模型）

1、 FA模型中的Ability

FA 模型中的Ability分为PageAbility、ServiceAbility、DataAbility、FormAbility四种类其中:

PageAbility是具备UI 实现的Ability，是用户具体可见并可以交互的Ability实例。
ServiceAbility也是Ability的一种，但是没有UI，为其他Ability提供调用自定义的服务，后台运行。
DataAbility也是没有UI的Ability,为其他Ability提供进行数据增、删、查的服务,在后台运行。
FormAbility是卡片Ability，是一种界面展示形式。

2、 FA模型的生命周期

在所有Ability中，PageAbility 因为具有界面，也是应用的交互入口，因此生命周期更加复杂。

PageAbility 的生命周期回调如下图

其他类型Ability的生命周期可参考PageAbility生命周期去除前后台切换以及onShow的部分进行理解。

开发者可以在app.ets中重写生命周期函数，在对应的生命周期函数内处理应用相应逻辑。

3、FA模型的进程线程模型

每个应用运行在不同的进程中，在FA模型中，每个Ability运行在独立的虚拟机中。

应用进程在Ability启动时创建，此时会为Ability创建相应的线程。当一个应用有多个Ability时，每一个Ability在独立线程中运行。在FA模型中，每个Ability绑定一个独立的虚拟机实例，因此Ability之间是隔离的。

各位看官，咱们前面已经聊过了FA模型，那可是HarmonyOS早期的璀璨明星啊！不过，话说回来，时代在进步，技术在发展，FA模型虽然曾经风光无限，但终究还是成为了过去式。

现在，咱们要聚焦的，是更为先进、更为强大的Stage模型。这Stage模型，可不是什么简单的角色，它是HarmonyOS应用开发的新篇章，是未来发展的趋势所在。相比于FA模型，Stage模型在性能、扩展性和灵活性方面都有着显著的优势。

所以，各位看官，如果您还在抱着FA模型不放，那可就有点儿out了。现在社会主推的，可是这位新晋的Stage模型。它就像是江湖中的后起之秀，虽然年轻，但实力不容小觑。想要在HarmonyOS的世界里闯出一片天，那您可得好好琢磨琢磨这Stage模型了！

三、 Stage模型

1、 Stage模型设计思想

为复杂应用设计
支持多设备和多窗口形态
平衡应用能力和系统管控成本

2、 Stage模型的生命周期

Ability的生命周期包括Creat、Foreground、Background、Destory四个状态。WindowsStageCreate和WindowsStageDestory为窗口管理器（WindowsStage）在Ability中管理UI界面功能的两个生命周期回调，从而实现Ability与窗口之间的弱耦合。

3、 Stage模型的Ability启动模式

Ability的启动模式是指Ability实例在启动时的不同呈现状态。针对不同的业务场景，系统提供了三种启动模式：

sinleton 启动模式

        sinleton启动模式为单实例模式，是默认情况下的启动模式。

        每次调用startAbility()方法时，如果应用进程中该类型的UIAbility实例已经存在，则复用系统中的UIAbility实例。系统中只存在唯一一个该UIAbility实例，即在最近任务列表中只存在一个该类型的UIAbility实例。

        说明：

        应用的UIAbility实例已创建，该UIAbility配置为单实例模式，再次调用startAbility()方法启动该UIAbility实例，此时只会进入该UIAbility的onNewWant()回调，不会进入其onCreate()和onWindowStageCreate()生命周期回调。

        如果需要使用singleton启动模式，在module.json5配置文件中的"launchType"字段配置为"singleton"即可。
standard启动模式

standard启动模式为标准实例模式，每次调用startAbility()方法时，都会在应用进程中创建一个新的该类型UIAbility实例。即在最近任务列表中可以看到有多个该类型的UIAbility实例。这种情况下可以将UIAbility配置为standard（标准实例模式）。

standard启动模式的开发使用，在module.json5配置文件中的"launchType"字段配置为"standard"即可。
specified启动模式

        specified启动模式为指定实例模式，针对一些特殊场景使用（例如文档应用中每次新建文档希望都能新建一个文档实例，重复打开一个已保存的文档希望打开的都是同一个文档实例）。

        在UIAbility实例创建之前，允许开发者为该实例创建一个唯一的字符串Key，创建的UIAbility实例绑定Key之后，后续每次调用startAbility()方法时，都会询问应用使用哪个Key对应的UIAbility实例来响应startAbility()请求。运行时由UIAbility内部业务决定是否创建多实例，如果匹配有该UIAbility实例的Key，则直接拉起与之绑定的UIAbility实例，否则创建一个新的UIAbility实例。

        说明：

        应用的UIAbility实例已创建，该UIAbility配置为指定实例模式，再次调用startAbility()方法启动该UIAbility实例，且AbilityStage的onAcceptWant()回调匹配到一个已创建的UIAbility实例。此时，再次启动该UIAbility时，只会进入该UIAbility的onNewWant()回调，不会进入其onCreate()和onWindowStageCreate()生命周期回调。

specified启动模式的开发使用，将module.json5配置文件的"launchType"字段配置为"specified"。