鸿蒙最全深入解读鸿蒙Stage模型，想搞定大厂面试官

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上鸿蒙开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

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、线程模型

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

获取](https://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)**

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！