你是不是也在想——“鸿蒙这么火我能不能学会”答案是当然可以这个专栏专为零基础小白设计不需要编程基础也不需要懂原理、背术语。我们会用最通俗易懂的语言、最贴近生活的案例手把手带你从安装开发工具开始一步步学会开发自己的鸿蒙应用。不管你是学生、上班族、打算转行还是单纯对技术感兴趣只要你愿意花一点时间就能在这里搞懂鸿蒙开发并做出属于自己的App关注本专栏《零基础学鸿蒙开发》一起变强每一节内容我都会持续更新配图代码解释全都有欢迎点个关注不走丢我是小白酷爱学习我们一起上路 全文目录前言一、先说结论切后台不等于销毁 UIAbility二、HarmonyOS 7 下先把版本和接口确认清楚三、为什么重新进入应用没有重新 onCreate四、搭一个只记录生命周期的最小实验五、按照固定顺序做一次生命周期实验六、锁屏和解锁为什么要单独看七、把生命周期日志整理成一张表八、三个回调分别适合放什么逻辑九、为什么有时重新进入又真的出现 onCreate十、这个实验还有两个容易混淆的点开发经验总结前言做 HarmonyOS 应用生命周期相关逻辑时一个很容易产生的误解是用户按 Home 键离开应用之后再从桌面进入应用看起来像是“重新打开”了一次那么onCreate()是否也应该重新执行在 Stage 模型下答案取决于UIAbility 实例有没有被重新创建而不是界面有没有重新出现在用户眼前。这次只做一个很小的实验给onCreate()、onForeground()、onBackground()加日志然后按照“启动 → Home 键 → 再进入 → 锁屏 → 解锁”的顺序观察生命周期。重点不是把所有生命周期接口罗列一遍而是把“创建实例”和“前后台切换”这两件经常混在一起的事情拆开。需要先说明下面代码依据 HarmonyOS 官方接口组织但本文无法代替目标设备完成真机执行因此不会把预期日志冒充为已经采集到的真机结果。尤其是锁屏、解锁环节最终日志应以目标 HarmonyOS 7 设备上的实际输出为准。一、先说结论切后台不等于销毁 UIAbilityStage 模型中的 UIAbility 是包含 UI 的应用组件。官方对 Stage 模型的说明中明确指出UIAbility 生命周期包含创建、销毁、前台、后台等状态而窗口显示相关状态由 WindowStage 暴露。因此理解这篇文章只需要先分清两组概念回调它表达的核心含义onCreate()UIAbility 实例被创建onForeground()UIAbility 进入前台onBackground()UIAbility 进入后台onDestroy()UIAbility 实例被销毁这里真正需要关注的是Foreground → Background → Foreground 可以发生在同一个 UIAbility 实例上。按 Home 键通常解决的是“当前 UIAbility 不再处于前台”这个问题并不等价于调用terminateSelf()也不能简单理解成“应用已经销毁”。这也是为什么观察到onBackground onForeground却没有第二次onCreate本身并不矛盾。官方 Stage 模型还说明后台应用会受到系统统一的进程管理当系统资源不足时后台应用可能被回收。因此“进入后台后实例暂时仍然存在”和“后台实例永远不会被销毁”同样不是一回事。二、HarmonyOS 7 下先把版本和接口确认清楚本文按 HarmonyOS 7 开发背景讨论。华为当前升级适配文档明确给出了 HarmonyOS 7.0 与API version 26.0.0的对应关系并建议升级到 26.0.0 开发套件后完成兼容性验证。这里使用的是 Stage 模型下的UIAbility相关能力属于 Ability Kit。当前官方示例使用统一 Kit 导入方式import{AbilityConstant,UIAbility,Want}fromkit.AbilityKit;生命周期日志则可以通过 Performance Analysis Kit 中的 HiLog 输出。官方资料说明Performance Analysis Kit 提供 HiLog 流水日志能力用于记录和获取应用运行日志当前官方代码示例采用import{hilog}fromkit.PerformanceAnalysisKit;本文只是记录 UIAbility 生命周期不涉及相机、定位、网络、后台长时任务等能力因此这个最小实验不需要额外声明运行时权限。这里也不需要为了观察生命周期额外调用moveAbilityToBackground()。实验要验证的是正常用户操作下的状态变化直接使用 Home 键即可。三、为什么重新进入应用没有重新 onCreate这个问题还需要结合 UIAbility 的启动模式来看。官方“UIAbility组件启动模式”文档定义了singleton、multiton和specified三种模式其中singleton是默认启动模式。对于已经存在的 singleton UIAbility再次启动时系统会复用已有实例而不是重新创建实例。这意味着第一次创建实例 ↓ onCreate ↓ 进入前台 ↓ onForeground ↓ Home ↓ onBackground ↓ 再次进入 ↓ 复用原来的 UIAbility ↓ onForeground这里没有产生新的 UIAbility 实例自然没有理由再次执行onCreate()。这也是生命周期问题里最需要建立的判断方式不要根据“用户是不是重新点了应用图标”判断 onCreate而应该根据“系统是不是重新创建了这个 UIAbility 实例”判断。另外需要区分一种相近但并不完全相同的情况。官方生命周期规则中在一个已经存在的 UIAbility 被再次拉起时某些启动场景还会涉及onNewWant()启动模式文档也明确指出singleton 实例已经存在时再次通过启动机制拉起该 UIAbility不会重新进入onCreate()和onWindowStageCreate()。本文实验只记录三个核心回调所以不把onNewWant()加进日志但实际排查“应用图标再次启动”“Want 参数刷新”之类的问题时需要把它纳入观察范围。四、搭一个只记录生命周期的最小实验实验不需要业务页面也不需要状态管理。保留默认 EntryAbility在三个生命周期回调里打印统一格式的日志即可。为了让日志容易过滤可以固定一个 TAGimport{AbilityConstant,UIAbility,Want}fromkit.AbilityKit;import{hilog}fromkit.PerformanceAnalysisKit;constDOMAIN0x0000;constTAGAbilityLifecycle;exportdefaultclassEntryAbilityextendsUIAbility{onCreate(want:Want,launchParam:AbilityConstant.LaunchParam):void{hilog.info(DOMAIN,TAG,%{public}s,onCreate);}onForeground():void{hilog.info(DOMAIN,TAG,%{public}s,onForeground);}onBackground():void{hilog.info(DOMAIN,TAG,%{public}s,onBackground);}}这段代码只解决一件事给 UIAbility 的创建、进入前台、进入后台三个状态打时间点。官方现有示例同样通过继承UIAbility在onCreate()、onForeground()和onBackground()中使用hilog.info()记录生命周期因此这里没有自行设计新的生命周期接口。如果是在默认工程中实际复现不要为了使用上面这段代码把原有的onWindowStageCreate()删除掉。默认页面仍然需要正常创建 WindowStage、调用loadContent()加载 ArkUI 页面这里只是省略与本次实验无关的窗口代码。换句话说实际工程可以保持原来的onWindowStageCreate(windowStage:window.WindowStage):void{windowStage.loadContent(pages/Index);}再把三个日志回调加入 EntryAbility。真正需要观察的不是页面内容而是 DevEco Studio 的日志窗口。五、按照固定顺序做一次生命周期实验操作顺序保持简单启动应用 ↓ 按 Home 键 ↓ 重新进入应用 ↓ 锁屏 ↓ 解锁并回到该应用启动阶段最容易判断。新的 UIAbility 实例创建时会进入onCreate()应用进入前台时会进入onForeground()。因此首次启动时本文关注的核心日志应包含onCreate onForeground这里并不是说完整启动流程只有这两个回调。包含 UI 的 UIAbility 还涉及 WindowStage 生命周期只是本实验有意把观察范围压缩到了三个回调。接着按 Home 键。应用从前台离开后关注onBackground此时最重要的观察点不是“有没有 onBackground”而是后面重新进入时有没有再次出现onCreate。如果 UIAbility 实例仍然存在再次回到前台关注onForeground而不是onCreate onForeground这正好可以验证本文的问题前后台切换和实例创建是两条不同的生命周期语义。六、锁屏和解锁为什么要单独看锁屏比 Home 键稍微特殊一些因为它不只是“用户打开了另一个普通应用”还涉及系统锁屏状态以及后台资源治理。华为官方关于后台资源和跨设备生命周期管理的资料都把“锁屏”和“退至后台”作为需要进行后台资源管理的场景。例如官方后台视频导出最佳实践明确说明普通应用在切到后台、锁屏或熄屏后会受到后台执行限制需要持续执行特定任务时应使用对应的后台任务机制。因此在生命周期实验中锁屏是很有价值的一步但这里不应该脱离设备环境硬写一份“所有设备必然完全一致”的日志。复现时建议这样判断如果锁屏导致当前 UIAbility 进入后台应看到onBackground随后解锁并且系统重新显示的仍然是这个 UIAbility、实例也没有在后台被销毁那么关注onForeground如果后台期间实例已经被系统回收那么之后重新进入应用就属于新的实例创建过程此时重新出现onCreate()才是合理现象。这也是为什么不能把“Home 后没有 onCreate”扩展成“以后永远不会再执行 onCreate”。七、把生命周期日志整理成一张表下面这张表更适合作为实验前的预期观察表。实际发布文章时可以在目标 HarmonyOS 7 真机完成操作后用设备真实日志替换“预期关注日志”一列。操作UIAbility 状态变化预期关注日志是否意味着创建新实例首次启动应用创建 → 前台onCreate→onForeground是按 Home 键前台 → 后台onBackground否再次进入且原实例仍存在后台 → 前台onForeground否锁屏并使 Ability 进入后台前台 → 后台关注onBackground否解锁后恢复原 Ability后台 → 前台关注onForeground否后台实例已被系统销毁后再次启动重新创建 → 前台会重新出现onCreate随后进入前台生命周期是这里最有价值的其实是第二、三行。用户视觉上的操作是离开应用 → 再打开应用而 UIAbility 视角可能只是Foreground → Background → Foreground没有发生Destroy → Create自然也就不会重新执行onCreate()。八、三个回调分别适合放什么逻辑理解日志顺序之后代码应该放在哪里也会清楚很多。onCreate()更适合处理和UIAbility 实例创建强绑定的初始化。如果把“每次用户重新看到应用都要执行”的刷新逻辑只放在这里那么 Home → 再进入时很可能不会重新执行。onForeground()对应 UIAbility 重新进入前台。官方资源使用示例也采用在onForeground()中申请或恢复前台所需资源、在onBackground()中停止后台不应继续使用的资源这种模式。例如官方传感器资源合理使用示例就在前台注册传感器监听在onBackground()中取消监听。onBackground()则适合处理进入后台后的资源释放或业务状态切换。但这不代表任何任务放进onBackground()后都可以无限在后台执行。Stage 模型对后台应用存在系统治理持续后台运行的业务需要使用系统提供的相应后台机制而不能把生命周期回调当成“后台保活入口”。一个比较典型的理解偏差就是onCreate():void{// 每次回到应用都刷新数据}代码本身可以写但注释表达的业务假设并不成立。如果需求真的是“UIAbility 每次重新进入前台时检查数据是否需要刷新”判断入口应该优先围绕onForeground()设计再由业务自己决定是否真正发起刷新而不是强行要求onCreate()重复执行。九、为什么有时重新进入又真的出现 onCreate如果实验中发现第二次进入应用确实打印了onCreate()也不能立刻认定生命周期异常。onCreate()的核心判断仍然是当前是不是创建了新的 UIAbility 实例。后台应用受到系统资源管理。当后台实例已经被销毁之后再次启动自然需要创建新的 UIAbility于是onCreate()会再次出现。启动模式也会改变实例创建行为。官方文档说明multiton模式每次启动都可以创建新的该类型 UIAbility 实例singleton则会在已有实例存在时复用实例。因此看到onCreate()次数不符合预期时排查顺序可以压缩成下面这条链路确认是不是 Stage 模型 ↓ 确认当前 UIAbility 的 launchType ↓ 确认此前实例是否真的仍然存在 ↓ 确认操作只是前后台切换还是重新启动了 UIAbility ↓ 再检查 onCreate / onForeground / onBackground 日志不要反过来根据日志数量猜系统行为。十、这个实验还有两个容易混淆的点第一个是UIAbility 生命周期和 ArkUI 页面生命周期不是一回事。onCreate()、onForeground()、onBackground()属于 UIAbility。ArkUI 自定义组件还有自己的创建、显示和销毁相关回调。本文只讨论 UIAbility不把页面aboutToAppear()等回调混进来否则“页面出现”和“Ability 进入前台”很容易再次混成同一个概念。第二个是后台不等于销毁。Home 键让应用离开前台并不能作为“所有内存状态已经清空”的依据。如果业务必须跨生命周期保存数据不能因为一次 Home → 返回实验中实例没有被销毁就依赖内存变量永久保存重要状态。系统对后台进程有自己的资源管理策略。开发经验总结这个最小实验真正要记住的不是某一串日志而是 UIAbility 生命周期的判断基准。onCreate()回答的是“这个 UIAbility 实例是不是刚刚创建”onForeground()回答的是“它是不是进入了前台”onBackground()回答的是“它是不是离开了前台进入后台”。所以应用按 Home 后再进入没有重新执行onCreate()并不奇怪。只要原 UIAbility 实例仍然存在前后台切换本来就不需要重新创建实例。反过来如果业务希望“用户每次重新回到应用都执行一次检查”也不要把逻辑全部压在onCreate()。应该先确认真正需要监听的是实例创建还是 UIAbility 回到前台。最后还有一个很适合自己继续验证的实验在当前三个日志之外再加入onDestroy()然后分别测试 Home、任务中心划掉应用、系统回收后的再次启动。把“后台”和“销毁”真正拆开以后很多生命周期问题会变得直观得多。❤️ 如果本文帮到了你…请点个赞让我知道你还在坚持阅读技术长文请收藏本文因为你以后一定还会用上如果你在学习过程中遇到bug请留言我帮你踩坑
