1. 为什么开发者都在纠结 Stage 模型和 FA 模型
前阵子在做一个鸿蒙应用的重构，Pod里一半人说“趁早切Stage”，另一半人说“FA跑得好好的，别折腾”。这种拉扯相信很多开发者都不陌生。新版应用市场审核、API版本兼容、多设备适配这些事摆到台面上时，Stage模型和FA模型的选择就不是一个“用哪个顺手”的问题了，它直接决定你后续的维护成本、多端部署能力，甚至能决定你的应用能不能跟上系统的迭代节奏。
先说清楚两个词：FA模型是鸿蒙早期的应用模型，全称Feature Ability，靠PageAbility、ServiceAbility、DataAbility这些组件拼出界面和逻辑；Stage模型是后续演进出来的新模型，以UIAbility为入口，配合AbilityStage和ExtensionAbility来组织应用。这篇文章不打算抄文档，我想用实际开发的角度，把这个模型对比讲透，顺便把我在迁移过程中踩过的坑、摸出来的规律一起说清楚。
适合谁来读？一种是你刚接触鸿蒙开发，正在看官方推荐，不知道从哪套模型入手；另一种是你手上有老项目是基于FA写的，团队正在纠结要不要重构。看完以后，你应该能判断自己的项目该走哪条路，也知道从FA往Stage迁移的大概步骤和风险点在哪里。
2. FA模型：早期鸿蒙应用的“轻快打法”
2.1 FA模型的核心结构：一个功能对应一个Ability
FA模型的设计思路非常直白：把一个应用拆成多个Ability，每个Ability承担一类功能。面向界面的叫PageAbility，你在手机上看到的页面基本都挂在PageAbility下；后台跑日志、同步数据的叫ServiceAbility；专门做数据读写、共享给其他模块用的叫DataAbility。
这种“一个功能一个Ability”的划分方式，在当时应对小而快的业务非常顺手。每个Ability都是相对独立的应用组件，启动一个Ability就可以直接拉起对应功能，不需要把整个App的上下文都初始化一遍。加上AbilitySlice的存在，一个PageAbility内部还能拆出多个界面分区，用代码控制不同Slice的切换，在单页面内部做跳转时非常灵活。
但问题也出现在灵活性上。FA模型把“功能”和“进程/任务栈”绑定得不够紧密，Ability之间靠Want做跳转，状态管理散落在各个Ability里，一旦业务变复杂，页面间数据同步和生命周期管控就开始吃力。尤其是多个Ability都要访问同一个用户态数据时，你就得手动维护各种全局变量或者写一个类似服务总线的东西，项目越往后越痛。
2.2 FA模型的生命周期和路由机制
FA模型的PageAbility生命周期类似Android Activity，有onStart、onStop、onActive、onInactive等回调。开发时你在Ability里重写这些回调来管理资源，页面本身则用AbilitySlice承载。页面跳转用的是router，完全面向Slice做路由，代码结构大概是这样的：
// FA模型中一个典型的页面跳转 import router from '@ohos.router' @Entry @Component struct Index { build() { Button('跳转详情') .onClick(() => { router.pushUrl({ url: 'pages/Detail' }) }) } }初看上去很简单，但FA模型的路由和生命周期问题有几个隐坑：
- 页面退出后数据是否需要恢复，得自己在onActive里控制。
- router跳转是全局的，一旦页面栈管理不好，很容易出现“返回时页面状态错乱”。
- ServiceAbility和PageAbility之间要通过连接（connectAbility）维护跨Ability交互，连接对象的管理也要非常小心，漏掉断开就会造成资源泄漏。
2.3 FA模型的开发体验总结
从开发手感来说，FA模型如果只做单一设备上的简单页面，确实能很快跑起来。我当时用FA做了一个内部工具型应用，一个页面、一个Ability、一个Service就搞定了，全程没有太多概念负担。但这种舒服仅限于“一个页面一个功能”的早期阶段，一旦你在一个Ability里塞了五六个页面，或者需要多个窗口、后台任务、数据共享，FA模型的抽象层级就显得不够用了。
另外一个关键点是，FA模型的设计目标是快速响应当时的生态，很多系统能力，比如卡片、后台任务、多窗口流转，在FA模型下实现起来都比较绕。官方后续把推荐重心切到Stage，本质上是因为应用形态已经过了“单点功能”阶段，更需要一套能支撑复杂业务、多模块协作、系统级扩展的完整模型。
3. Stage模型：更接近真实业务的“重型工程框架”
3.1 Stage模型的入口组件：UIAbility + AbilityStage + ExtensionAbility
Stage模型不是简单改了个名字，它是从架构上把“应用”和“页面”解耦了。最核心的变化是引入了UIAbility、AbilityStage和ExtensionAbility三个新角色。
UIAbility对应的是带界面的应用入口，可以理解为以前FA模型的PageAbility升级版。但UIAbility不再强调“一个功能一个入口”，而是强调“一个页面场景一个入口实例”。同一个UIAbility可以启动多个实例，每个实例拥有自己的窗口，非常适合做分屏、自由窗口和独立任务。
AbilityStage是模块级生命周期组件，每个模块（类似一个功能包）可以有独立的AbilityStage，负责在执行模块加载时做一些统一初始化操作。它天然适合做一些全局配置、埋点统计、云端参数拉取这类“只应该做一次”的事情。以前在FA里自己写的Application级工具类，到Stage模型里就有了正规的挂靠位置。
ExtensionAbility则是处理无界面能力的一站式扩展点，比如后台任务、卡片服务、文件共享、数据管理，都可以通过不同类型的Extension来实现。通过AbilityStage和ExtensionAbility，系统能清楚识别“哪个模块在运行、为什么运行”，也方便系统做资源回收和隐私管控。
3.2 窗口和界面的解耦：WindowStage带来的改变
Stage模型里最容易被忽略但非常重要的设计，是UIAbility只负责生命周期和业务逻辑，窗口层面单独抽出了WindowStage。每个UIAbility在创建后会通过onWindowStageCreate拿到一个WindowStage对象，页面的内容都挂在这个窗口上加载。
这个设计直接带来了几个实际好处。第一，同一个UIAbility可以创建多个窗口，每个窗口加载不同的页面内容，实现“一组件多功能”；第二，窗口的显示、隐藏、大小变化都归WindowStage管理，UIAbility不用操心这些细节；第三，在折叠屏或PC端做适配时，你只需要增加窗口策略，不用重新调整页面生命周期。
从代码上看，Stage模型的入口模块通常是这样的：
// Stage模型中一个标准UIAbility入口 import UIAbility from '@ohos.app.ability.UIAbility' import window from '@ohos.window' export default class EntryAbility extends UIAbility { onCreate(want, launchParam) { // 应用级初始化，也可以放到AbilityStage去做 } onWindowStageCreate(windowStage: window.WindowStage) { // 注册窗口事件，比如窗口显示、尺寸变化 windowStage.loadContent('pages/Index') } onForeground() { // 进入前台，可恢复资源 } onBackground() { // 进入后台，及时释放非必需资源 } }3.3 Stage模型的生命周期与任务管理机制
Stage模型的UIAbility生命周期包括onCreate、onWindowStageCreate、onForeground、onBackground、onWindowStageDestroy、onDestroy，跟FA模型相比多了一套窗口生命周期回调。这套生命周期的意义在于：系统可以更精细地感知你的应用当前处于哪个阶段，然后针对性地管理资源。
举个例子，在FA模型里，后台任务边界模糊，ServiceAbility被系统杀掉了你可能都不知道。Stage模型里，后台能力统一交给ExtensionAbility，每种Extension都有明确的运行时限和管理规则。系统可以更高效地决定“这个后台任务还能不能跑”“这个Ability是否应该被回收”，这对长续航、省内存的目标是实打实的利好。
任务管理方面，Stage模型引入了更清晰的任务栈和窗口层级关系。应用启动后，系统从AbilityStage到UIAbility一层层拉起，每个UIAbility都有独立的任务记录。对比FA模型，Stage模型下的页面栈关系更符合大家直觉里的“应用内页面栈”概念，处理“返回上一个页面”“回到桌面后再进入原页面”这类常见操作时，心智负担小很多。
4. 对比拆解：Stage模型与FA模型的六大关键差异
4.1 入口粒度和任务模型不同
FA模型的最小可调度单位是Ability，一个Ability可能就是一个小功能，系统看到的是一堆能力组件。Stage模型的最小单位是“应用+UIAbility任务”，一个应用可以有多个UIAbility，每个UIAbility都是系统可识别的完整任务单元。
这个差异实际影响很大。FA模型下，你很难通过系统框架去管理“一个完整流程”，因为流程可能横跨多个Ability，系统不知道哪个页面应该和哪个页面组成一个任务。Stage模型天然支持“一个页面场景对应一个UIAbility实例”，任务边界和窗口边界对齐，系统能准确知道当前哪个任务在前台、哪些窗口需要保留，多任务切换的体验会顺很多。
4.2 生命周期与后台运行约束的差别
FA模型的后台运行相对宽松，ServiceAbility能较长时间留在后台，资源管理更多依赖开发者自觉。但这带来的后果是，部分应用滥用后台常驻，导致设备卡顿、耗电。Stage模型把后台能力拆到ExtensionAbility，系统给各种Extension划定了明确的运行策略和时限。
对普通开发者来说，这种“紧箍咒”其实是好事。你在FA模型里要自己设计一套后台心跳和线程管理，到Stage模型里只需要按照系统规则使用ServiceExtension或TaskDispatcher，剩下的事交给系统。好坏对错先不争论，至少规范的约束让更多应用在同等条件下体验更稳定。
4.3 开发范式和工程结构的差异
FA模型开发时，模块划分往往跟着Ability走，一个Ability一个目录，代码风格非常自由。Stage模型则扛着更严格的工程纪律：应用、模块、组件三个层次分得清清楚楚，AbilityStage负责模块生命周期，UIAbility负责可交互入口，Extension能力单独成模块。
实际工程中，Stage模型配合鸿蒙的HAP分包机制，可以让一个应用按需加载模块。比如你做一个电商App，首页、商品详情、支付、客服，可以拆成不同HAP，让支付模块仅在需要时加载。这在FA模型里不是不行，但要绕过各种能力之间的强关联，改造起来比重新设计还难。
4.4 数据共享和模块解耦能力
FA模型的数据共享一般靠DataAbility和外部存储接口，模块之间直接依赖较深。Stage模型推荐的思路是通过数据管理服务（比如关系型数据库、分布式数据对象）和统一的接口层做解耦，模块之间不直接相互调用，而是通过定义的接口协议通信。
我举个真实例子。原来用FA写的一个项目，订单模块和用户模块都要读同一个用户信息，信手编码就成了“从用户模块拿个单例过来”。后来用户模块升级，全项目到处都要改。迁到Stage模型后，我们把用户信息下沉到一个独立的DataShareExtension，业务模块只要通过统一的接口请求，底层换数据库还是换缓存策略，上层完全无感。
4.5 多设备协同和流转能力差距明显
Stage模型在跨设备流转上的设计是原生级的。UIAbility可以被指定为“可流转”，当用户在手机和平板之间切换时，系统可以把整个窗口状态和组件状态一起迁移到目标设备，界面模块完全不用重写而延续内容。FA模型虽然也能做流转，但流转粒度更多是页面级别的，状态同步和任务边界经常要手动补齐。
如果你做的是办公类、工具类应用，目标用户会在多个设备间切换，那Stage模型的多实例和任务管理能力能帮你省掉大量适配工作。简单的“从手机上继续到平板上看”的场景，Stage模型的代码改动量远小于FA模型。
4.6 迁移成本和生态建议
官方推荐的优先级已经很清楚：新项目直接用Stage模型，老项目按节奏迁移。为什么？背后是生态长期演进的方向。你可以把FA模型理解为“第一版API快速铺量”，Stage模型是为未来多端、多窗口、复杂业务打磨的基座。不用寄希望于官方继续加强FA模型的能力，很多新特性在Stage模型上才有完整实现。
但这也意味着存量FA项目需要正视迁移成本：代码不是简单换几个包名就能完事，路由、生命周期、任务管理都要重写。如果不愿意一次性大改，可以采取渐进式替换，把核心模块先迁到Stage，非核心模块继续保留在老接口上。只迁移一部分的话，同一个应用就会出现新老模型并存的情况，这时候要特别注意模型之间的交互边界。
5. 从FA迁移到Stage的实操心得
5.1 迁移前先理清这四件事
我在接触不少老项目后总结出一个规律：迁移失败的项目，基本都是因为没在迁移前把能力边界理清楚就动手了。至少要把下面四件事盘明白：
- 页面清单：记录现有应用里所有PageAbility，以及每个Ability内部使用了哪些AbilitySlice，页面间跳转关系是什么。
- 后台能力：把所有ServiceAbility找出来，分析每个后台任务是短时任务还是长时任务，是否允许被系统回收。
- 数据流：画出当前应用的数据来源和共享路径，哪些数据是页面局部使用的，哪些数据是多个模块共享的。
- 系统能力依赖：记录你使用了哪些系统开放能力，尤其是与窗口、输入法、多任务流转相关的能力。
把这四件事整理成表格之后，你才清楚哪些模块可以“平移”，哪些模块需要重新设计。
5.2 推荐的分阶段迁移路径
一次性全量迁可能是最省事的方案，但风险也最大，尤其是应用功能复杂时，很容易出现大面积回归。我更推荐的路径是先搭骨架、再填肉：
第一阶段，先建好Stage模型工程，把原有应用的壳子按模块关系拆成多个HAP，创建对应的AbilityStage并实现统一初始化。这个阶段先不迁移具体页面，只要确保应用能通过新入口启动。
第二阶段，把最核心的页面迁移成UIAbility页面，用WindowStage加载页面内容。这一阶段要重点验证页面跳转、前后台切换和任务栈是否符合预期。如果在核心页面上跑通，说明迁移路线是对的。
第三阶段，再把后台服务改造为ExtensionAbility。改造时尤其要注意后台任务的时限和系统约束，不要简单把ServiceAbility的代码复制过来，而是顺着系统推荐的接口重新设计。
最后，清理FA模型残留代码，移除旧的路由和旧Ability，做整体回归，重点看后台任务被杀后的恢复逻辑、窗口尺寸变化时的UI表现、跨设备流转时的状态同步。
5.3 迁移过程中最常踩的坑
第一个坑是生命周期不一致。FA模型里onActive对应页面可见，Stage模型里onForeground表示UIAbility进入前台，但窗口是否可见还需要额外判断。有些人直接照搬旧逻辑，结果页面退到后台时还在跑动画，资源消耗陡然上升。
第二个坑是Want参数与页面路由数据不一致。FA模型里router.pushUrl的参数可以直接在页面中取到，但Stage模型里页面加载是通过WindowStage.loadContent完成的，页面要获取启动参数，往往得先把参数保存在UIAbility的成员变量里，再在页面初始化时读取。这部分流程很多人会漏掉。
第三个坑是后台能力没有按Extension规范改写。ServiceAbility可以直接在代码里while循环做长任务，到了Stage模型，后台任务如果不符合系统约束，会被立刻销毁，甚至可能触发应用异常。解决办法是认真评估每个后台任务类别，需要长时间运行的就选用长时任务Extension，能拆成短时任务的就用TaskDispatcher，该用WorkScheduler的不要硬撑。
第四个坑是并行实例带来的全局变量共享问题。Stage模型同一种UIAbility可以启动多个实例，每个实例有自己的窗口和上下文。如果你用一个静态全局变量存储“当前用户登录状态”，多实例场景下就会互相覆盖。正确做法是把共享状态放到AbilityStage管理的模块级数据中，避免全局单例滥用。
6. 我的选择原则与最后想说的话
6.1 什么时候可以继续留在FA模型
如果你的应用是一个内部工具、单设备演示、生命周期很短的项目，并且未来半年内不打算做多设备适配，那么FA模型还能用。它不是不能跑，而是你心里要明白，后续系统升级、新特性支持方面会越来越吃紧。说白了，FA模型像一辆改装过的老车，市区代步没问题，但别指望它能跑长途越野。
6.2 什么时候必须提前切Stage
判断标准很简单：只要你的应用有以下任何一条，就建议直接上Stage模型。
- 需要使用卡片、后台任务、文件共享等系统级扩展能力。
- 需要在平板、折叠屏、PC等多窗口场景运行。
- 需要做跨设备流转或分布式协同。
- 模块数量多，希望做按需加载和独立交付。
- 担心老模型逐步边缘化，希望在生态早期就卡位。
这些需求在FA模型下不是做不到，而是实现的代价远高于直接迁移。如果你站在项目规划角度，早半年重构和晚半年重构，痛苦程度完全不同。
6.3 我在实际项目中的体会
基于我的实操经验，我的选择很明确：新项目，无论规模大小，一律Stage模型。老项目，能迁就迁，但不要头脑发热直接停线，而是按“骨架先行、核心先跑、后台细化、最后清场”的顺序来做。
另外分享一个小技巧：迁移过程里一定要留一张“旧代码能力与新接口对照表”。很多人迁移到一半就开始混乱，搞不清这个功能应该放到哪个组件里。我在做某模拟项目时，就是靠一张Excel表格，把旧Ability、旧Service、旧数据入口，逐个映射到新的UIAbility、ExtensionAbility和共享数据接口，整个团队对照着写，效率提升非常明显。
无论是选型还是迁移，本质都是为了一件事：让应用能顺着系统演进的方向跑，而不是和系统拧着走。多花点时间理解Stage模型的设计思路，后面省下的时间会是几十倍。
