【鸿蒙心迹】Ability 生命周期与页面跳转：从前后台四态到 Navigation 路由栈

前言

上一篇把调试三件套补齐了，工具在手，这篇回到主线，讲清楚"应用是怎么活着的"：UIAbility 从创建到销毁都经历了什么、页面之间怎么跳、参数怎么传。码上清单做到多页面之后，这些问题一天之内全撞上了。

一、UIAbility 生命周期：先分清"应用态"和"页面态"

UIAbility 是系统调度的基本单元，一套回调下来就是它的一生：

onCreate(want)            // 创建,冷启动参数在 want 里
onWindowStageCreate()     // 主窗口创建,loadContent 加载首页在这里
onForeground() / onBackground()  // 前后台切换,反复触发
onNewWant(want)           // 单例被再次拉起时走这里,不走 onCreate
onDestroy()               // 销毁

最值得实测的是前后台这一段。我在 onForeground/onBackground 里各打了一条 hilog，然后挨个场景试：点 Home 键、切到别的应用、从最近任务回来——后台判定比想的直接，但下拉通知栏、弹权限窗这类"半前台"状态各系统版本表现不一致，涉及前后台逻辑（比如暂停轮询）别想当然，拿日志说话。

另一个关键点是 launchType：

• singleton（默认）：一个 Ability 全局一个实例，再次拉起走 onNewWant，页面栈原样保留；
• multiton：每次拉起都新开实例；
• specified：按参数决定复用还是新建，适合"同一文档多开"这类场景。

码上清单用默认单例就够了，但单例有个隐藏行为：从通知点进来想"重新开始"，实际只是把旧实例带回前台——想重置就得自己清页面栈。

二、页面跳转：router 与 Navigation 怎么选

ArkTS 有两条跳转路线。老的 router（pushUrl/getParams）还能用，但官方的重心已经移到 Navigation：系统级转场、一多适配、嵌套导航都按它的模型设计，新项目没有理由再选 router。

Navigation 的用法是"一个栈 + 一组目的地"：

// 页面 A:往栈里压
this.pathStack.pushPath({ name: 'Detail', param: this.todos[i] });

// 详情页:NavDestination 里取参、返回
let item = this.pathStack.getParamByName('Detail')[0];
this.pathStack.pop();

对比 router 最舒服的一点：跳转关系集中在一个路由栈对象里，谁压谁弹一目了然；而不是散落在各页面的 url 字符串里。传参也少了一层序列化的心智——对象直接给。

三、跳转踩坑三条

1. 目的地没注册，跳转无反应。Navigation 的每个 NavDestination 都要在路由表里登记，漏一个的表现是"点了没反应"，不报错。排查办法：先在 pushPath 前后打日志确认调用到了，再核对路由表条目。
2. 单例二次拉起只走 onNewWant。通知栏点进来的参数在 onNewWant 的 want 里，只在 onCreate 里处理 want 的代码，热启动时等于没接。两个回调要么都处理，要么抽成同一个函数。
3. 后台可能被直接杀掉。系统资源紧张时，后台 Ability 不给你留情面，回来直接重走 onCreate。放内存单例里的"会话中间态"会无声消失——登录态、草稿这类数据，变化时就落 Preferences 或数据库，别赌系统帮你记着。

小结

生命周期和跳转理顺之后，应用在设备上"活"的骨架就完整了：什么时候生、什么时候藏、页面怎么流转。下一篇写桌面卡片（元服务卡片），把码上清单从图标变成桌面上"活"的入口——不点进应用就能看待办、勾任务。

*本文环境：DevEco Studio 5.x / HarmonyOS NEXT（API 14+）。生命周期与 Navigation 细节以官方《应用程序框架指南》《导航》为准。系列上一篇：《【鸿蒙心迹】DevEco Studio 调试三件套实战》。*