UIAbility 退出时该在哪里释放资源？onWindowStageDestroy 和 onDestroy 对比【鸿蒙心迹】

你是不是也在想——“鸿蒙这么火我能不能学会”答案是当然可以这个专栏专为零基础小白设计不需要编程基础也不需要懂原理、背术语。我们会用最通俗易懂的语言、最贴近生活的案例手把手带你从安装开发工具开始一步步学会开发自己的鸿蒙应用。不管你是学生、上班族、打算转行还是单纯对技术感兴趣只要你愿意花一点时间就能在这里搞懂鸿蒙开发并做出属于自己的App关注本专栏《零基础学鸿蒙开发》一起变强每一节内容我都会持续更新配图代码解释全都有欢迎点个关注不走丢我是小白酷爱学习我们一起上路 全文目录前言一、先给出资源释放的判断方法二、HarmonyOS 7 下先把版本和接口确认清楚三、搭一个只观察资源释放的最小 DemoEntryAbility.ets四、页面只负责触发正常退出Index.ets五、onWindowStageDestroy 到底应该释放什么六、onDestroy 更适合处理 UIAbility 级资源七、观察两个 Destroy 时不要只记调用顺序八、几个容易理解错的地方九、实际项目怎么排查资源没有释放开发经验总结前言在 Stage 模型里写UIAbility时有两个生命周期很容易被当成同一件事onWindowStageDestroy()和onDestroy()。它们都出现在退出阶段官方示例里也都能看到“释放资源”的语义但两者管理的生命周期层级并不一样。Stage 模型本身就把应用组件和窗口管理做了解耦UIAbility负责组件生命周期而显示相关状态由WindowStage承担。所以这篇只讨论一个问题资源到底应该在哪释放。我们用一个最小 Demo 放三类资源进去一个系统环境监听器、一个定时器、一个主窗口对象引用。然后主动结束当前UIAbility观察onWindowStageDestroy()和onDestroy()把资源的“所有者”与清理位置对应起来。一、先给出资源释放的判断方法不要先问“哪个回调更晚”而应该先问这个资源到底属于 WindowStage还是属于 UIAbilityHarmonyOS 的 Stage 模型明确把应用组件和窗口管理解耦UIAbility生命周期主要负责创建、销毁、前后台等状态显示相关状态则通过WindowStage暴露。结合官方当前示例可以把本文涉及的资源先分成下面三类资源创建位置建议释放位置原因window.Window引用及窗口关联资源onWindowStageCreate()onWindowStageDestroy()生命周期依赖当前 WindowStagesetInterval()定时任务onCreate()onDestroy()本例让它跟随 UIAbility 实例ApplicationContext环境监听onCreate()onDestroy()官方 EnvironmentCallback 示例就是这样注册和注销华为官方多个当前示例对onWindowStageDestroy()的注释都是“主窗口销毁释放 UI 相关资源”而 EnvironmentCallback 官方 API 示例则直接在UIAbility.onCreate()中调用ApplicationContext.on(environment, ...)在onDestroy()中调用off(environment, ...)。这已经给出了一个很实用的边界窗口生命周期结束时清窗口资源UIAbility 生命周期结束时清 Ability 级资源。二、HarmonyOS 7 下先把版本和接口确认清楚本文以HarmonyOS 7.0 / API 26.0.0作为开发背景。华为最新升级适配文档明确说明HarmonyOS 7.0 对应 API 版本为 26.0.0从 26.0.0 开始HarmonyOS 开发套件的 API 版本号也改用X.Y.Z语义化格式。不过本文使用的核心能力并不是 HarmonyOS 7 才新增的能力。UIAbilityContext所属模块首批接口从 API version 9 开始支持并且仅用于 Stage 模型terminateSelf()可以主动销毁当前 UIAbility。EnvironmentCallback 同样从 API version 9 开始支持也是 Stage 模型接口。定时器模块则从 API version 3 开始提供setInterval()创建的重复定时任务需要通过clearInterval()主动删除。本文涉及的 Kit 很少UIAbility、EnvironmentCallback、common.UIAbilityContextAbility Kitwindow.WindowStage、window.WindowArkUI日志直接使用console.info()避免为了 Demo 再引入额外业务代码。整个示例不需要申请额外权限也不需要为资源释放增加module.json5权限配置。这里还要区分一个容易混淆的配置官方说明terminateSelf()默认不会清理任务中心中的任务如果业务确实需要停止 UIAbility 后同时移除最近任务可以给 Ability 配置removeMissionAfterTerminate: true。这属于任务管理行为不是本文讨论的“释放监听器、定时器和窗口引用”因此 Demo 不配置它。【建议插图1HarmonyOS 7 / API 26.0.0 工程中 EntryAbility.ets 的生命周期代码位置】三、搭一个只观察资源释放的最小 DemoDemo 的逻辑非常简单。UIAbility创建时做两件事注册一个ApplicationContext系统环境变化监听创建一个每 2 秒打印一次日志的定时器。等WindowStage创建完成并加载页面后再取得主窗口window.Window对象并保存引用。退出时则反过来onWindowStageDestroy()只处理窗口相关引用onDestroy()注销监听并清理定时器。页面上只留一个按钮调用UIAbilityContext.terminateSelf()这样可以主动进入正常的 UIAbility 销毁流程。官方文档确认terminateSelf()用于销毁 UIAbility 自身且只能在主线程调用。EntryAbility.ets这段代码解决的核心问题不是“怎么写生命周期”而是让三类资源具有清晰的归属关系。import{EnvironmentCallback,UIAbility}fromkit.AbilityKit;import{window}fromkit.ArkUI;exportdefaultclassEntryAbilityextendsUIAbility{privateenvironmentCallbackId:number|undefinedundefined;privatetimerId:number|undefinedundefined;privatemainWindow:window.Window|undefinedundefined;onCreate():void{console.info([LifecycleDemo] onCreate);constenvironmentCallback:EnvironmentCallback{onConfigurationUpdated(config){console.info([LifecycleDemo] configuration changed:${JSON.stringify(config)});},onMemoryLevel(level){console.info([LifecycleDemo] memory level changed:${JSON.stringify(level)});}};constapplicationContextthis.context.getApplicationContext();this.environmentCallbackIdapplicationContext.on(environment,environmentCallback);console.info([LifecycleDemo] environment listener registered, id${this.environmentCallbackId});this.timerIdsetInterval((){console.info([LifecycleDemo] timer tick);},2000);console.info([LifecycleDemo] timer created, id${this.timerId});}onWindowStageCreate(windowStage:window.WindowStage):void{console.info([LifecycleDemo] onWindowStageCreate);windowStage.loadContent(pages/Index,(err){if(err.code){console.error([LifecycleDemo] loadContent failed, code${err.code}, message${err.message});return;}this.mainWindowwindowStage.getMainWindowSync();console.info([LifecycleDemo] main window reference acquired);});}onWindowStageDestroy():void{console.info([LifecycleDemo] onWindowStageDestroy);// WindowStage 生命周期已经进入销毁阶段// 清除本 Ability 保存的窗口相关对象引用。this.mainWindowundefined;console.info([LifecycleDemo] window related reference released);}onDestroy():void{console.info([LifecycleDemo] onDestroy);constapplicationContextthis.context.getApplicationContext();if(this.environmentCallbackId!undefined){applicationContext.off(environment,this.environmentCallbackId);console.info([LifecycleDemo] environment listener removed);this.environmentCallbackIdundefined;}if(this.timerId!undefined){clearInterval(this.timerId);console.info([LifecycleDemo] timer cleared);this.timerIdundefined;}}}这里真正需要关注的是三个成员变量environmentCallbackId timerId mainWindow它们不是为了方便写 Demo 才随便放在一起而是故意代表三种典型资源订阅关系、持续任务、窗口对象引用。其中定时器还有一个官方约束clearInterval()删除的定时器应当与创建它的定时器位于同一线程。官方文档同时说明应用切到后台以后UI 场景中的定时器可能被冻结因此“进入后台”也不能简单等价成“定时器已经结束”。四、页面只负责触发正常退出为了不把系统杀进程、任务管理等因素混进 Demo可以直接调用terminateSelf()。官方示例已经给出了从 ArkUI 页面通过getUIContext().getHostContext()获取UIAbilityContext的方式。Index.etsimport{common}fromkit.AbilityKit;import{BusinessError}fromkit.BasicServicesKit;EntryComponentstruct Index{build(){Column({space:20}){Text(UIAbility Resource Release Demo).fontSize(22).fontWeight(FontWeight.Bold)Button(Terminate UIAbility).onClick(async(){constcontextthis.getUIContext().getHostContext()ascommon.UIAbilityContext;try{awaitcontext.terminateSelf();}catch(err){consterrorerrasBusinessError;console.error(terminateSelf failed, code${error.code}, message${error.message});}})}.width(100%).height(100%).justifyContent(FlexAlign.Center)}}这份代码是按照当前官方接口定义组织的最小示例没有在这里声称已经经过具体设备编译或真机运行。实际发布文章前建议使用 HarmonyOS 7 / API 26.0.0 的目标设备再做一次日志验证。【建议插图2点击“Terminate UIAbility”前控制台持续输出 timer tick 的日志】【建议插图3点击按钮后控制台中 onWindowStageDestroy、窗口引用释放、onDestroy、监听注销和 timer cleared 的日志】五、onWindowStageDestroy 到底应该释放什么onWindowStageDestroy()最重要的关键词不是 Destroy而是WindowStage。官方当前大量窗口示例都采用这样的结构onWindowStageDestroy():void{// Main window is destroyed, release UI related resources}也就是把它定位在主窗口销毁阶段用于处理 UI、窗口相关资源。因此如果某个对象只有在当前 WindowStage 存在时才有意义例如窗口对象引用、与窗口绑定的 UI 上下文、针对当前窗口创建的辅助对象以及业务自行创建并需要主动管理的子窗口资源那么清理逻辑应该优先围绕onWindowStageDestroy()设计。本例中的privatemainWindow:window.Window|undefined;就是最简单的窗口生命周期对象。这里还有一个很重要的细节主窗口是系统通过 WindowStage 提供给 UIAbility 的不应该为了“释放资源”而自己调用destroyWindow()把主窗口销毁一遍。Demo 做的是解除业务代码保存的引用this.mainWindowundefined;如果实际项目自行创建了子窗口则属于另一种情况。华为当前《子窗口开发指导》明确指出不再需要子窗口时应使用对应的窗口销毁接口释放子窗口。六、onDestroy 更适合处理 UIAbility 级资源监听器和定时任务则不一样。我们的 EnvironmentCallback 是在onCreate()中注册的它跟随的是这个 UIAbility 实例而不是某个具体窗口。官方 EnvironmentCallback 文档甚至直接给出了完全相同的生命周期配对onCreate - ApplicationContext.on(environment, ...) onDestroy - ApplicationContext.off(environment, ...)所以这里放到onDestroy()清理非常自然。定时器也是同样的设计。因为本例是在UIAbility.onCreate()中建立定时任务希望它存在于整个 UIAbility 生命周期所以在onDestroy()中执行clearInterval(this.timerId);如果实际业务中的定时器只服务某个页面那么它就不应该照搬本文放到UIAbility.onDestroy()。页面级资源应跟随页面或组件自身的生命周期释放。资源在哪里创建不是唯一标准资源属于谁才是更可靠的判断依据。七、观察两个 Destroy 时不要只记调用顺序在正常结束 UIAbility 的场景中这个 Demo 最值得观察的是两个阶段WindowStage 销毁阶段 ↓ onWindowStageDestroy() ↓ 释放窗口相关资源 UIAbility 销毁阶段 ↓ onDestroy() ↓ 注销监听、停止 Ability 级持续任务开发时很容易把它简化成“反正最终都会退出那全部塞到 onDestroy 不就行了”问题就在这里。如果资源本来依赖窗口把释放动作一直拖到 UIAbility 的最终销毁阶段会让窗口资源与 Ability 生命周期发生不必要的耦合反过来如果把所有监听器、任务都塞到onWindowStageDestroy()又等于默认这些资源一定依赖窗口这同样不准确。Stage 模型专门把 UIAbility 和 WindowStage 拆开资源管理最好也保留这层边界。八、几个容易理解错的地方这里有三个地方特别值得检查。第一onBackground()不是通用资源销毁点。UIAbility 进入后台和 UIAbility 被销毁是两件事。尤其是本文的定时器官方 Timer 文档明确说明应用切到后台后定时器可能被冻结这并不表示定时器已经被删除。第二不要把onDestroy()理解成进程级finally。官方当前restartApp()文档明确指出通过该接口重启进程时不会触发进程中 Ability 的onDestroy生命周期回调。也就是说重要数据不能仅依靠“应用退出时再保存”这种设计保证可靠性。第三窗口引用清空和销毁窗口不是同一件事。系统管理的主窗口只需要停止继续持有、停止继续操作业务主动创建且需要独立管理的窗口则应按照窗口 API 的生命周期要求主动销毁。华为当前子窗口指导也明确要求不再需要子窗口时进行销毁。九、实际项目怎么排查资源没有释放遇到 UIAbility 退出后仍怀疑有资源残留时可以按“资源所有权”往回查而不是先在两个 Destroy 之间猜。先确认资源在哪里创建。如果在onWindowStageCreate()中取得而且离开这个 WindowStage 后就没有继续存在的意义优先检查onWindowStageDestroy()。如果资源从onCreate()开始存在并且设计上服务整个 UIAbility例如应用级监听、连接句柄或本例这样的持续任务再检查onDestroy()是否成对执行了off、clear、disconnect等对应操作。监听器尤其要确认注册返回的 ID 是否保存下来。EnvironmentCallback 官方示例就是保存callbackId销毁时再把同一个 ID 交给off()。然后检查是否错误地把onBackground()当成退出。后台只是状态变化并不意味着 UIAbility 生命周期已经结束。最后再检查退出路径。不要假设任何情况下都一定执行onDestroy()对于官方已经明确说明不会触发该回调的特殊路径更不能把关键持久化操作只押在这里。开发经验总结onWindowStageDestroy()和onDestroy()真正的区别不是“两个销毁回调选哪个”而是它们代表两个不同层级的生命周期结束。窗口、UIContext、窗口关联对象这类资源应该优先跟随 WindowStage 管理监听器、连接、定时任务等 UIAbility 级资源则跟随 UIAbility 生命周期管理。创建和释放尽量形成清晰的配对关系onWindowStageCreate ↕ onWindowStageDestroy onCreate ↕ onDestroy这样处理之后即使以后一个 UIAbility 中加入更多窗口、监听和异步任务也比较容易判断资源应该归到哪一层而不是把所有清理代码堆到最后一个onDestroy()。如果正在整理现有 HarmonyOS 工程可以直接搜一遍on()、setInterval()、窗口对象和各种connect调用然后逐个问一句这个资源的真正所有者到底是谁很多资源释放问题到这里就已经能定位出方向。❤️ 如果本文帮到了你…请点个赞让我知道你还在坚持阅读技术长文请收藏本文因为你以后一定还会用上如果你在学习过程中遇到bug请留言我帮你踩坑