共计 4536 个字符，预计需要花费 12 分钟才能阅读完成。
HarmonyOS 3.1 版本（API 9）推出了全新利用开发模型 -Stage 模型，该模型从新定义了利用开发的能力边界，从利用开发模型的角度，反对多窗口状态下对立的利用组件生命周期，并反对跨设施的迁徙和协同机制。本文为大家具体介绍 Stage 模型。
一、Stage 模型概念
利用开发模型是运行在不同 OS 上的形象构造。OS 通过这种形象构造，把利用开发的基础设施封装在 OS 外部。开发者通过应用利用开发模型，复用 OS 基础设施的能力，达到高效开发利用的目标。
1、什么是 Stage 模型
Stage 模型提供面向对象的开发方式，规范化了过程创立的形式，提供组件化开发机制，将组件形象为 UIAbility 和 ExtensionAbility 两大类。UIAbility 组件的生命周期蕴含创立、销毁、前台、后盾状态，将与界面强相干的获焦、失焦状态都放在窗口治理对象中，从而实现 UIAbility 与窗口之间的弱耦合；在服务侧, 窗口治理服务依赖于组件治理服务，前者告诉后者前后台变动，这样组件治理服务仅感知前后台变动，不感知焦点变动。ExtensionAbility 组件提供场景化的服务扩大机制，不提供自定义服务的能力。
相比于 FA 模型，Stage 模型提供了更灵便的开发方式，更低的内存占用和更规范化的系统管理机制。
将来 HarmonyOS 将在兼容 FA 模型的根底上，继续演进 Stage 模型。
FA 模型与 Stage 模型比照图
2、Stage 模型能力特点
Stage 模型能力示意图
Stage 模型的设计，是为了提供给开发者一个更好的开发方式，更好的实用于多设施、分布式场景。
Stage 模型的三大能力特点：
1）原生反对组件级的迁徙和协同
Stage 模型的组件天生具备分布式迁徙和协同的能力，它是 HarmonyOS 反对分布式能力在利用模型上的体现。
利用组件反对跨设施的数据恢复：
充沛应用 ArkUI 的申明式 UI 和多页面的能力，把数据 / 状态保留在 UIAbility 组件实例中，逻辑批改数据，数据驱动 UI 变动。多设施间迁徙 UIAbility，就是迁徙 UIAbility 的数据 / 状态。在指标设施上通过数据 / 状态来复原 UI，实现逻辑与 UI 的解耦，晋升了流转开发效率。
利用组件反对跨设施的近程调用：
UIAbility 组件反对跨设施拉起另外一个设施上同名利用的同名组件实例。零碎在拉起过程中，通过底层软总线的能力在两个组件实例之间建设跨设施的 RPC 连贯，开发者在获取 RPC 接口后，即可进行跨设施通信，实用于利用在设施间交互的场景。
2）反对多设施状态和多窗口状态
在桌面设施上，窗口能够最大化 / 最小化 / 任意扭转窗口大小，窗口间能够任意切换焦点，接管用户输出。在挪动设施上，根本以全屏窗口为主，窗口之间形成栈构造，只有顶层窗口能力接管用户输出。如何在不同窗口状态的设施上，提供对立的组件模型呢？Stage 模型拆散了 UIAbility 生命周期和窗口显示 / 焦点事件，使得窗口的焦点切换不影响 UIAbility 组件的状态。
UIAbility 的前后台状态和窗口的全屏 / 最小化的关系如下：
只有当窗口最小化的时候，UIAbility 组件进入后盾状态，否则 UIAbility 组件处于前台状态；
当一个窗口全屏的时候，触发其余窗口最小化（能够依据产品状态确定全屏窗口个数）。
在桌面设施和挪动设施的交互体验不同的状况下，零碎通过施行上述规定，能够保障 UIAbility 组件的生命周期定义在多设施上保持一致。同时，不管在桌面设施还是挪动设施，都遵循每个新的 UIAbility 组件实例都会创立一个工作，所以也保障了工作（Mission）机制在多设施上的一致性。
3）从新定义利用能力边界
通常状况下，利用如果可自行决定创立多少个过程、自定义服务时，零碎为保障用户体验，须要在后盾运行管控、过程关联启动等方面对利用的运行状态进行强治理，从而升高零碎总体的内存占用和功耗开销。
Stage 模型基于场景的服务扩大、严格的后盾管控机制和受限的过程模型，从新定义了利用能力边界，使过程环境从“无序”到“有序”，标准了过程治理模型。
二、Stage 模型介绍
基于 Stage 模型开发利用，上面将会从利用组件、过程模型、线程模型、任务模型、后盾运行机制、利用配置文件 6 个方面进行介绍。
1、组件模型
利用开发模型中须要指明利用开发的入口。在 HarmonyOS 上，利用组件是利用开发的入口，同时也是运行时入口。用户启动、应用和退出利用过程中，利用组件会在不同的状态间切换，这些状态称为利用组件的生命周期。利用组件提供生命周期的回调函数，开发者通过利用组件的生命周期回调感知利用的状态变动。
Stage 模型组件类型
Stage 模型提供了 UIAbility 和 ExtensionAbility 两种类型的组件。
1）UIAbility 组件是一种蕴含 UI 界面的利用组件，次要用于和用户交互。UIAbility 的生命周期只蕴含创立 / 销毁 / 前台 / 后盾等状态，通过 WindowStage 的事件裸露显示相干的状态。每个 UIAbility 组件都会有一个主窗口与之绑定，如果开发者心愿开发简单的页面和动效，咱们举荐开发者应用 ArkUI 的多页面能力。UIAbility 反对跨设施拉起同名组件，并与之协同交互的能力。
2）ExtensionAbility 组件是一种面向特定场景的利用组件，零碎在特定场景下启动该组件为用户提供服务。开发者并不间接从 ExtensionAbility 派生，而是从 ExtensionAbility 的派生类派生。目前 ExtensionAbility 有用于卡片场景的 FormExtensionAbility 和用于输入法场景的 InputMethodExtensionAbility 等多种派生类。在 Stage 模型上，一般利用开发者不能开发自定义服务，也不反对开发者间接启动 ExtensionAbility，包含开发者本人编写的 ExtensionAbility。
2、过程模型
过程模型示意图
Stage 模型有三类过程，是从零碎总体资源占用思考，心愿由零碎负责利用过程的创立和销毁。所以不反对利用自定义配置多过程，也不反对通过接口启动过程。
1）主过程
开发者编写的 UIAbility 入口及其依赖的代码都在该过程中运行。它是由 UIAbility 组件的启动触发创立的。
2）ExtensionAbility 过程
开发者编写的同一种类型的 ExtensionAbility 组件实例都会在同一个过程中运行。不同类型的 ExtensionAbility 组件实例则在不同的过程中运行。该类过程是由零碎服务在特定场景下创立，并依据用户对特定场景的应用，决定其何时销毁。同时该类过程独立于主过程创立，并且不反对与主过程之间进行 IPC 通信。
3）Render 过程
为了反对 WebView 的运行，每个利用只能创立一个 Render 过程用于运行 WebView 的渲染引擎。这个 Render 过程也是由零碎负责创立和销毁。
3、线程模型
HarmonyOS 的原生利用开发语言为 ArkTS。在利用过程启动时，零碎会在主线程上创立一个 ArkTS 的虚拟机实例，而后加载和执行利用的入口代码。利用组件的生命周期回调，输出事件的散发，ArkUI 的布局等操作都会在主线程上执行，所以咱们举荐开发者不要在主线程上执行单次耗时过长的操作，否则容易引发卡顿。
ArkTS 通过提供 Worker API 反对并发编程。Worker 有独立的虚拟机上下文，它与主线程是两个不同的虚拟机上下文。它们之间通过 postMessage API 进行通信。这种基于消息传递的并发模型与基于锁的并发模型不同，须要开发者特地留神。
4、任务模型
用户在操作利用的过程中，常常须要对曾经操作过的利用进行切换，这些操作记录（不同 OS 的操作对象定义可能不同）常常被称为工作。利用工作治理模型须要定义工作的操作对象，以及工作创立和销毁的形式和机会。
在 HarmonyOS 上，每次用户启动一个新的 UIAbility 组件实例，都会生成一个新的工作（Mission）。例如，用户启动一个视频利用后，切换到“工作核心”界面，将会看到视频利用这个工作，当用户点击这个工作时，零碎会把该工作切换到前台，如果这个视频利用中的视频编辑性能也是通过利用组件编写的，那么在用户启动视频编辑性能时，会创立视频编辑的利用组件实例，在“工作核心”界面中，将会展现视频利用、视频编辑两个工作。
工作（Mission）中记录了组件和快照的信息，并在零碎中长久化。即便工作对应的组件实例销毁，工作依然存在。如果用户从工作核心中抉择某个工作，工作对应的组件实例会被拉到前台并获焦，如果它对应的组件实例曾经销毁，零碎会创立一个新的组件实例与之对应。
开发者在用户交互设计上须要特地留神，防止产生过多的工作。如果开发者心愿应用多个页面交互，举荐应用 ArkUI 的页面栈能力。
HarmonyOS 的任务模型不提供工作栈的能力，每个利用能够有多个工作在工作核心出现，不同利用的工作不会以栈的模式重叠在一起，防止了不同利用间工作混淆不清的状况。
5、后盾运行机制
后盾运行示意图
当利用的所有前台 UIAbility 组件都进入后盾的时候，零碎认为该利用进入后盾。利用在后盾运行的机制对设施续航影响很大。HarmonyOS 后盾运行机制的设计初衷是心愿利用过程在零碎规定范畴内运行，并使用户可感知，防止利用过程在后盾运行，而用户不感知的状况。咱们提供了如下几种后台任务（Task）：
1）短时工作
零碎每天会给申请了短时工作的利用调配肯定的后盾运行配额。
2）长时工作
零碎定义了若干种后盾长时运行的工作类型，开发者须要在利用的配置文件中配置，并须要上架审核。这样该利用在设施上后盾运行的时候，就能够放弃长时间运行，同时零碎会通过用户可感知的 UI 提醒用户有后盾过程正在运行。例如导航，录音，音乐等场景。
3）无工作
默认状况下，利用不申请任何后盾运行形式，则会在利用过程进入后盾 10 秒钟后被解冻挂起，利用无奈收到内部非用户操作事件。
4）闲时工作
对于一些 CPU 密集型，且对实时性要求不高的工作，比方科学计算等场景，零碎提供了闲时工作机制。例如设施充电等适当的机会向利用提供后盾运行的能力，开发者能够通过 Work-SchedulerExtensionAbility 应用该机制，零碎会依据以后的零碎状态和用户应用频次决策唤醒机会。
5）托管工作
对于一些能够托管给零碎执行的工作。比方下载等场景，零碎提供代理工作的 API，由零碎代理实现工作，利用过程会处于解冻状态。
6、利用配置文件
Stage 模型提供了全新的利用配置文件，它蕴含利用信息、利用组件信息、权限信息、开发者自定义信息等，这些信息在编译构建、散发和运行阶段别离提供给编译工具、利用市场和操作系统应用。
Stage 利用模型是 HarmonyOS 利用开发的基础架构，它从组件模型、面向对象开发方式、过程 / 线程模型等方面对 FA 模型进行了全面的优化，进步了利用开发效率。后续咱们将在利用模型的基础设施、大型利用开发、拓展利用状态、跨设施能力和性能体验等方面持续打磨，撑持 HarmonyOS 利用生态拓展，宽广开发者退出进来，一起摸索和翻新，共建万物互联的利用生态。
将来未来，有迹可循！
