鸿蒙应用退出与崩溃排查：onDestroy陷阱、lastExitReas

鸿蒙专家

上一篇文章聊了生命周期和启动框架，这次来说说应用怎么结束。别小看这个问题：用户按返回键该退出还是挂后台？应用崩溃怎么查原因？有些场景需要应用自己重启怎么搞？处理不好用户真的会骂人。

我之前踩过一个坑：用户反馈“改了语言，重启应用又变回去”。查了半天发现应用退出时数据没持久化，下次启动又从默认配置读。后来才搞清楚onDestroy在某些场景下根本不走，代码白写了。

这篇就把应用退出、异常原因排查、应用重启三块串起来讲，都是实战一定会遇到的东西。

一、应用退出：不止一种方式

鸿蒙应用的退出机制分三大类，每一类处理方式不同。

1. 用户主动退出

最常见的是返回键退出。默认按返回键只是把UIAbility挂到后台，不销毁。如果想直接退出，可以重写onBackPressed方法：

2. import { AbilityConstant, UIAbility, Want } from '@kit.AbilityKit';
3. import { hilog } from '@kit.PerformanceAnalysisKit';
4. import { BusinessError } from '@kit.BasicServicesKit';
6. export default class EntryAbility extends UIAbility {
7.   onBackPressed(): boolean {
8.     this.context.terminateSelf().then(() => {
9.       hilog.info(0x0000, 'Demo', 'terminateSelf成功');
10.     }).catch((err: BusinessError) => {
11.       hilog.error(0x0000, 'Demo', `terminateSelf失败: ${err.code}, ${err.message}`);
12.     });
13.     return true; // 返回true表示消费事件，不再默认挂后台
14.   }
15. }

复制代码

注意：onBackPressed返回true表示事件被消费，系统不做默认处理；返回false则交给系统挂后台。

多任务清理（上滑卡片或点清除全部）时，onDestroy是保证触发的，可以在这里做数据保存。但在Dock栏关闭应用（PC或平板）时，onDestroy不保证触发，千万别依赖它保存关键数据。

2. 应用主动退出

通过代码调用terminateSelf，场景包括检测到致命错误主动终止、完成核心任务后自动关闭等。系统会触发onDestroy，走正常生命周期销毁。

2. import { AbilityConstant, UIAbility, Want } from '@kit.AbilityKit';
3. import { BusinessError } from '@kit.BasicServicesKit';
5. export default class EntryAbility extends UIAbility {
6.   private doExit(): void {
7.     this.context.terminateSelf().then(() => {
8.       console.info('应用主动退出成功');
9.     }).catch((err: BusinessError) => {
10.       console.error(`退出失败: ${err.code}, ${err.message}`);
11.     });
12.   }
13. }

复制代码

3. 系统强制终止

这类情况最坑爹——不会触发onDestroy。包括JavaScript崩溃、C++空指针异常、系统内存紧张回收进程、温度过高保护、应用升级时清理旧进程等。你的关键数据保存逻辑如果写在onDestroy里，碰上系统强杀等于白写。

那怎么办？关键数据要实时持久化，别等到退出时才存。

二、获取异常退出原因

既然系统强杀不通知，那至少得知道上次为什么挂了吧。鸿蒙从API 9开始就在LaunchParam里提供了lastExitReason，从API 18开始还能拿到更详细的内存信息。

在UIAbility的onCreate里读取：

2. import { UIAbility, Want, AbilityConstant } from '@kit.AbilityKit';
4. export default class MyAbility extends UIAbility {
5.   onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void {
6.     const reason = launchParam.lastExitReason;
7.     const exitMsg = launchParam.lastExitMessage;
8.     console.info(`上次退出原因: ${reason}, 详情: ${exitMsg}`);
9.     if (reason === AbilityConstant.LastExitReason.JS_ERROR) {
10.       // 触发崩溃上报
11.     } else if (reason === AbilityConstant.LastExitReason.RESOURCE_CONTROL) {
12.       // 检查是否需要清理缓存
13.     }
14.   }
15. }

复制代码

注意：PERFORMANCE_CONTROL（值6）已废弃，官方建议用RESOURCE_CONTROL替代。

LastExitDetailInfo（API 18+）可以获取退出时的进程状态：

2. import { UIAbility, Want, AbilityConstant } from '@kit.AbilityKit';
4. export default class MyAbility extends UIAbility {
5.   onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void {
6.     if (launchParam.lastExitDetailInfo) {
7.       const info = launchParam.lastExitDetailInfo;
8.       console.info(`PID: ${info.pid}, 进程名: ${info.processName}`);
9.       console.info(`RSS: ${info.rss} KB, PSS: ${info.pss} KB`);
10.       // 如果RSS或PSS过高，大概率是被内存管控杀的
11.       if (info.rss > 500000) { // 500MB
12.         console.warn('内存占用过高，建议优化');
13.       }
14.     }
15.   }
16. }

复制代码

exitSubReason也有很多门道：100~102是户外模式相关，103是后台CPU高负载，107/108是内存超限。看到107基本可以确定是PSS内存超限杀的。

实战中我们可以做一个崩溃检测和上报：

2. import { UIAbility, Want, AbilityConstant } from '@kit.AbilityKit';
4. export default class EntryAbility extends UIAbility {
5.   onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void {
6.     this.checkLastExit(launchParam);
7.   }
8.   private checkLastExit(launchParam: AbilityConstant.LaunchParam): void {
9.     const reason = launchParam.lastExitReason;
10.     if (reason === AbilityConstant.LastExitReason.NORMAL || reason === AbilityConstant.LastExitReason.UNKNOWN) {
11.       return;
12.     }
13.     console.warn(`异常退出，原因: ${reason}, 消息: ${launchParam.lastExitMessage}`);
14.     if (launchParam.lastExitDetailInfo) {
15.       const info = launchParam.lastExitDetailInfo;
16.       if (info.rss > 400000 || info.pss > 300000) {
17.         console.warn(`内存异常: RSS=${info.rss}KB, PSS=${info.pss}KB`);
18.       }
19.     }
20.     this.reportExitReason(reason, launchParam.lastExitMessage);
21.   }
22.   private reportExitReason(reason: number, message: string): void {
23.     // 上报到统计分析平台
24.   }
25. }

复制代码

三、应用重启：什么时候需要自己重启

有些场景需要主动重启：下载新资源需重新加载、关键配置变化需从初始状态开始、应用状态出问题想刷新。鸿蒙从API 12开始提供两种主动重启方式。

不保留窗口的重启：用ApplicationContext.restartApp，API 12+。重启过程中当前窗口关闭，用户会看到桌面再拉起。适合不介意闪一下的场景。

2. import { common, Want } from '@kit.AbilityKit';
3. function restartApp(context: common.ApplicationContext): void {
4.   let want: Want = {
5.     bundleName: 'com.example.myapp',
6.     abilityName: 'EntryAbility'
7.   };
8.   try {
9.     context.restartApp(want);
10.   } catch (err) {
11.     console.error(`重启失败: ${err.code}, ${err.message}`);
12.   }
13. }

复制代码

保留窗口的重启：用UIAbilityContext.restartApp，API 22+。重启过程中窗口保留，体验更连贯。

2. import { common, Want } from '@kit.AbilityKit';
3. async function restartWithWindow(context: common.UIAbilityContext): Promise<void> {
4.   let want: Want = {
5.     bundleName: 'com.example.myapp',
6.     abilityName: 'EntryAbility'
7.   };
8.   try {
9.     await context.restartApp(want);
10.   } catch (err) {
11.     console.error(`重启失败: ${err.code}, ${err.message}`);
12.   }
13. }

复制代码

如果重启后想跳转到另一个页面，把abilityName改成其他Ability即可。

两种方式共同的限制：只能在主线程调用，应用必须处于焦点状态，3秒内不能重复调用。后台应用不能自己重启，我的做法是先切到前台再调，或者给用户弹提示。

元服务重启：用abilityManager.restartSelfAtomicService，API 20+，支持元服务的免安装更新。

此外还有被动重启：appRecovery模块。开启后应用挂了系统自动恢复并重启Ability，甚至能恢复到崩溃前的页面状态。

2. import { appRecovery } from '@kit.AbilityKit';
3. export default class EntryAbility extends UIAbility {
4.   onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void {
5.     appRecovery.enableAppRecovery(
6.       appRecovery.RestartFlag.ALWAYS_RESTART,
7.       appRecovery.SaveOccasionFlag.SAVE_OCCASION_UI_STATE
8.     );
9.   }
10. }

复制代码

注意：如果崩溃是脏数据导致的，自动恢复后会再次崩溃，可能死循环，不适合所有场景。

四、实际踩过的坑

坑1：onDestroy做保存，系统强杀全丢了
我之前把主题色保存逻辑写在onDestroy里，结果系统内存紧张直接杀进程，用户改完颜色再打开还是旧的。正确做法是数据改了立刻存，不依赖onDestroy。

坑2：restartApp在子线程调用直接报错
异步任务里调restartApp，报错：非主线程无权限。后来改用EventHub发消息到主线程调。

坑3：LastExitDetailInfo为空
这个字段从API 18开始，而且是可选的，只有异常退出时才可能有。取值时一定要做空判断。

坑4：SIGNAL退出的迷惑行为
看到大量lastExitReason === SIGNAL（值10）不要慌，这表示系统发kill信号，但不一定是坏事（如系统整理内存、应用升级）。要结合exitSubReason或时间戳判断。

坑5：3秒内重复调用restartApp被忽略
解决方案是UI层做防抖，保存上次调用时间，小于4秒就忽略。

总结

应用退出这件事坑不少，几个要点：用户主动退出走onDestroy可放心做清理；系统强制终止不触发onDestroy，关键数据要实时持久化；lastExitReason+lastExitDetailInfo是排查崩溃的利器，但注意空判断；主动重启分两种：流畅体验用UIAbilityContext.restartApp（API 22+），不在意闪一下用ApplicationContext.restartApp（API 12+）；重启接口需在主线程调用，3秒内不能重复，应用必须在前台。

最后，建议定期查看异常退出数据。我们上线上报功能后才发现，大量退出是因为内存问题，直接推动了内存优化工作。

热心网友6

这篇文章非常实用，尤其是关于 `onDestroy` 不保证触发的提醒，确实是个容易踩的坑。我之前也遇到过类似问题，不过是把用户设置存到了本地数据库，但由于依赖 `onDestroy` 写入，结果系统强杀时数据就丢了，后来改成了每次修改配置就立刻持久化才解决。 另外你提到的 `lastExitReason` 和 `lastExitDetailInfo` 在 API 18 后的增强很关键，对于线上排查崩溃和内存问题帮助很大。我之前没注意到 `PERFORMANCE_CONTROL` 已废弃，感谢提醒。 关于应用重启，你提到后面会讲，期待具体实现——比如 `terminateSelf` 后再调 `startAbility` 时需要注意什么，或者是否有更优雅的重启方式？

热心网友6

楼主这篇干货很实在，尤其是 onDestroy 不保证触发那点，之前我也掉过类似的坑，后来把关键数据的存盘逻辑都改成了实时写，才彻底解决。关于 lastExitReason 和内存信息的获取，目前我在 API 18 的设备上还没测试过，想问下楼主：如果 JS_ERROR 触发后，应用下次启动时 lastExitReason 是必能获取到吗？还是说有概率丢失？另外，RESOURCE_CONTROL 这个值除了清理缓存，有没有更好的应对策略？

热心网友6

这篇总结太及时了，正好最近被系统强杀搞得焦头烂额，之前一直以为onDestroy是铁定会走的，结果线上丢了好几次用户配置才反应过来。特别是“关键数据要实时持久化”这句，点醒了我。还有lastExitReason那个API，之前不知道可以这样查崩溃原因，以后排查效率能高不少。感谢分享！