鸿蒙应用能耗优化实战：如何避免引用不当引发的后台运行

摘要

在鸿蒙（HarmonyOS / OpenHarmony）应用开发中，很多开发者在做性能优化时，第一反应是网络请求、动画帧率、算法复杂度，但实际项目跑久了会发现：
真正拉高耗电的，往往不是"大功能"，而是一些"不起眼的引用问题"。

比如：

页面已经退出了，逻辑却还在跑
UI 没变化，但组件却在频繁重绘
定位、定时器、监听器在后台默默工作

这些问题的共同点只有一个：引用没有跟着生命周期走 。

这篇文章就围绕"引用导致的能耗问题"，结合 ArkUI 的实际开发场景，系统讲清楚原因、优化思路，以及可以直接复用的 Demo 写法。

引言

随着鸿蒙生态的发展，应用的使用场景已经从"短时间打开"变成了：

常驻后台的工具类应用
多页面频繁切换的业务型应用
长时间运行的智能设备配套 App

在这些场景下，能耗问题会被无限放大 。

而鸿蒙本身在系统层已经做了不少省电策略，如果应用层还存在"引用滥用"，系统再怎么兜底，电量也还是会掉得很快。

所以，与其纠结"怎么省电"，不如先把引用结构写对。

长生命周期对象引用短生命周期组件的问题

问题现象

这是最常见、也最容易忽略的一类问题。

页面（Page / Component）已经被用户退出，但：

被全局单例引用
被定时器回调引用
被事件监听或闭包捕获

导致页面无法被释放。

高能耗错误示例

ts 复制代码

// GlobalManager.ts
export const GlobalManager = {
  callback: null as (() => void) | null
}

ts 复制代码

// 页面代码
onPageShow() {
  GlobalManager.callback = () => {
    console.log('页面逻辑仍在执行')
  }
}

页面退出后，GlobalManager.callback 仍然持有页面逻辑的引用。

结果就是：

页面看似消失了
实际对象还活着
CPU 会被周期性唤醒
电量在后台慢慢流失

正确的优化方式

ts 复制代码

onPageHide() {
  GlobalManager.callback = null
}

这里的关键不是"写不写这行代码"，

而是建立一种意识：引用必须和页面生命周期对齐。

状态引用频繁更新引发的 UI 能耗

问题本质

在 ArkUI 中：

@State
@Observed
@Link

一旦发生变化，就可能触发组件重建。

如果状态更新本身没有业务意义，那就是纯耗电。

常见错误写法

ts 复制代码

@State count: number = 0

aboutToAppear() {
  setInterval(() => {
    this.count++
  }, 100)
}

即使 UI 并不关心 count 的变化，

也会导致组件树反复刷新。

优化方式一：限制更新条件

ts 复制代码

setInterval(() => {
  if (this.count < 10) {
    this.count++
  }
}, 1000)

优化方式二：非 UI 状态不要放进 State

ts 复制代码

private internalCount: number = 0

只有真正参与 UI 渲染的状态 ，才有资格使用 @State。

系统资源引用必须严格释放

高能耗资源类型

在鸿蒙中，以下资源一旦被引用，就可能持续唤醒系统：

定位服务
传感器
网络监听
后台任务

错误示例（定位）

ts 复制代码

onPageShow() {
  location.start()
}

如果页面退出却没有停止定位，

系统会一直认为"这个应用还需要位置数据"。

正确示例

ts 复制代码

onPageShow() {
  location.start()
}

onPageHide() {
  location.stop()
}

这类问题在测试阶段不明显，但在用户真实使用中，非常耗电。

后台引用导致的"隐形运行"

问题描述

应用进入后台后，逻辑仍在跑：

定时器没停
Promise 链没断
事件监听没注销

错误示例

ts 复制代码

this.timer = setInterval(() => {
  this.fetchData()
}, 5000)

正确释放方式

ts 复制代码

onPageHide() {
  clearInterval(this.timer)
}

如果是事件总线：

ts 复制代码

onPageHide() {
  eventBus.off('update', this.handler)
}

后台"偷偷跑逻辑"，是实际项目中最常见的耗电来源之一。

一个完整、可运行的引用优化 Demo 模块

数据管理模块

ts 复制代码

// DataManager.ts
export class DataManager {
  private listeners: 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())
  }
}

export const dataManager = new DataManager()

页面中使用

ts 复制代码

onPageShow() {
  dataManager.addListener(this.updateUI)
}

onPageHide() {
  dataManager.removeListener(this.updateUI)
}

updateUI() {
  console.log('UI 更新')
}

这样做的好处

页面存在时才参与业务
页面销毁后自动解绑
不会产生"幽灵引用"
能耗随页面生命周期自然下降

实际应用场景分析

场景一：资讯类 App 列表页

页面退出但轮询请求仍在跑
优化方式：页面隐藏时停止轮询

ts 复制代码

onPageHide() {
  clearInterval(this.refreshTimer)
}

场景二：智能设备控制页

页面退出但设备状态监听未移除
优化方式：解绑设备回调

ts 复制代码

device.offStatusChange(this.handler)

场景三：运动或定位类应用

页面切走但定位仍在后台运行
优化方式：严格控制定位生命周期

QA 环节

Q1：为什么系统不能自动帮我释放这些引用？

系统只能回收"没有引用的对象"，只要你还在引用，系统就认为你还需要。

Q2：弱引用能解决问题吗？

ArkTS 没有传统意义上的 WeakReference，更重要的是设计层面的引用关系。

Q3：怎么快速排查耗电问题？

优先检查：定时器、监听器、全局对象、Service 是否持有 UI 引用。

总结

鸿蒙应用中的能耗优化，本质并不是少写代码、少用功能，而是：

让引用跟着生命周期走
让资源只在需要的时候存在
不为"写起来方便"留下长期引用

一句话概括就是：
页面活着，逻辑才活；页面死了，引用必须一起断。