摘要
在鸿蒙（HarmonyOS / OpenHarmony）应用开发中，很多开发者在做性能优化时，第一反应是网络请求、动画帧率、算法复杂度，但实际项目跑久了会发现：
真正拉高耗电的，往往不是“大功能”，而是一些“不起眼的引用问题”。
比如：
- 页面已经退出了，逻辑却还在跑
- UI 没变化，但组件却在频繁重绘
- 定位、定时器、监听器在后台默默工作
这些问题的共同点只有一个：引用没有跟着生命周期走。
这篇文章就围绕“引用导致的能耗问题”，结合 ArkUI 的实际开发场景，系统讲清楚原因、优化思路，以及可以直接复用的 Demo 写法。
引言
随着鸿蒙生态的发展，应用的使用场景已经从“短时间打开”变成了：
- 常驻后台的工具类应用
- 多页面频繁切换的业务型应用
- 长时间运行的智能设备配套 App
在这些场景下，能耗问题会被无限放大。
而鸿蒙本身在系统层已经做了不少省电策略，如果应用层还存在“引用滥用”，系统再怎么兜底，电量也还是会掉得很快。
所以，与其纠结“怎么省电”，不如先把引用结构写对。
长生命周期对象引用短生命周期组件的问题
问题现象
这是最常见、也最容易忽略的一类问题。
页面（Page / Component）已经被用户退出，但：
- 被全局单例引用
- 被定时器回调引用
- 被事件监听或闭包捕获
导致页面无法被释放。
高能耗错误示例
// GlobalManager.tsexportconstGlobalManager={callback:nullas(()=>void)|null}// 页面代码onPageShow(){GlobalManager.callback=()=>{console.log('页面逻辑仍在执行')}}页面退出后，GlobalManager.callback仍然持有页面逻辑的引用。
结果就是：
- 页面看似消失了
- 实际对象还活着
- CPU 会被周期性唤醒
- 电量在后台慢慢流失
正确的优化方式
onPageHide(){GlobalManager.callback=null}这里的关键不是“写不写这行代码”，
而是建立一种意识：引用必须和页面生命周期对齐。
状态引用频繁更新引发的 UI 能耗
问题本质
在 ArkUI 中：
@State@Observed@Link
一旦发生变化，就可能触发组件重建。
如果状态更新本身没有业务意义，那就是纯耗电。
常见错误写法
@Statecount:number=0aboutToAppear(){setInterval(()=>{this.count++},100)}即使 UI 并不关心count的变化，
也会导致组件树反复刷新。
优化方式一：限制更新条件
setInterval(()=>{if(this.count<10){this.count++}},1000)优化方式二：非 UI 状态不要放进 State
privateinternalCount:number=0只有真正参与 UI 渲染的状态，才有资格使用@State。
系统资源引用必须严格释放
高能耗资源类型
在鸿蒙中，以下资源一旦被引用，就可能持续唤醒系统：
- 定位服务
- 传感器
- 网络监听
- 后台任务
错误示例（定位）
onPageShow(){location.start()}如果页面退出却没有停止定位，
系统会一直认为“这个应用还需要位置数据”。
正确示例
onPageShow(){location.start()}onPageHide(){location.stop()}这类问题在测试阶段不明显，但在用户真实使用中，非常耗电。
后台引用导致的“隐形运行”
问题描述
应用进入后台后，逻辑仍在跑：
- 定时器没停
- Promise 链没断
- 事件监听没注销
错误示例
this.timer=setInterval(()=>{this.fetchData()},5000)正确释放方式
onPageHide(){clearInterval(this.timer)}如果是事件总线：
onPageHide(){eventBus.off('update',this.handler)}后台“偷偷跑逻辑”，是实际项目中最常见的耗电来源之一。
一个完整、可运行的引用优化 Demo 模块
数据管理模块
// DataManager.tsexportclassDataManager{privatelisteners:Array<()=>void>=[]addListener(cb:()=>void){this.listeners.push(cb)}removeListener(cb:()=>void){this.listeners=this.listeners.filter(item=>item!==cb)}notify(){this.listeners.forEach(cb=>cb())}}exportconstdataManager=newDataManager()页面中使用
onPageShow(){dataManager.addListener(this.updateUI)}onPageHide(){dataManager.removeListener(this.updateUI)}updateUI(){console.log('UI 更新')}这样做的好处
- 页面存在时才参与业务
- 页面销毁后自动解绑
- 不会产生“幽灵引用”
- 能耗随页面生命周期自然下降
实际应用场景分析
场景一：资讯类 App 列表页
- 页面退出但轮询请求仍在跑
- 优化方式：页面隐藏时停止轮询
onPageHide(){clearInterval(this.refreshTimer)}场景二：智能设备控制页
- 页面退出但设备状态监听未移除
- 优化方式：解绑设备回调
device.offStatusChange(this.handler)场景三：运动或定位类应用
- 页面切走但定位仍在后台运行
- 优化方式：严格控制定位生命周期
QA 环节
Q1：为什么系统不能自动帮我释放这些引用？
系统只能回收“没有引用的对象”，只要你还在引用，系统就认为你还需要。
Q2：弱引用能解决问题吗？
ArkTS 没有传统意义上的 WeakReference，更重要的是设计层面的引用关系。
Q3：怎么快速排查耗电问题？
优先检查：定时器、监听器、全局对象、Service 是否持有 UI 引用。
总结
鸿蒙应用中的能耗优化，本质并不是少写代码、少用功能，而是：
- 让引用跟着生命周期走
- 让资源只在需要的时候存在
- 不为“写起来方便”留下长期引用
一句话概括就是：
页面活着，逻辑才活；页面死了，引用必须一起断。
