📖 引言

你有没有过这样的经历：手机电量掉得特别快，打开电池设置一看，某个应用排在耗电榜前列，然后你毫不犹豫地把它卸载了？

电量消耗是用户卸载App的重要原因之一。在「民族图鉴」这样的工具类应用中，用户可能不会长时间高频使用，但如果它在后台悄悄耗电，用户的印象分就会大打折扣。一个"省电"的应用，用户更愿意保留；一个"耗电"的应用，随时可能被卸载。

你可能会问：我的应用只是展示一些静态内容，怎么会耗电？CPU、屏幕、网络、GPS，这些硬件模块哪个最耗电？后台运行时应该注意什么？定位功能怎么用才省电？网络请求怎么优化才能减少耗电？

这些问题的答案，都藏在硬件模块的功耗特性里。很多开发者对功耗的认知停留在"少做事就省电"这个层面，但实际上，功耗优化是一门精细的学问——同样是发网络请求，合并请求和分散请求的耗电量可能差好几倍；同样是用定位，高精度和低精度的功耗差距可能达到一个数量级。

本文将从手机功耗的构成讲起，详细介绍各个硬件模块的功耗优化方法：CPU、网络、定位、后台任务、传感器、唤醒锁。结合「民族图鉴」项目的实际场景，带你建立系统化的功耗优化思维。

---

🎯 学习目标

完成本文后，你将能够：

• ✅ 理解功耗优化的重要性以及对用户留存的影响
• ✅ 掌握手机功耗的构成：CPU、屏幕、网络、GPS、传感器、唤醒
• ✅ 学会CPU功耗优化：减少计算、批量处理、降低频率
• ✅ 掌握网络功耗优化：合并请求、减少轮询、缓存数据、智能预加载
• ✅ 学会定位功耗优化：低精度模式、减少更新频率、及时关闭
• ✅ 了解后台功耗优化：减少后台活动、合理使用后台任务
• ✅ 掌握唤醒锁（WakeLock）的正确使用方法
• ✅ 了解传感器功耗：陀螺仪、加速度计等的使用原则
• ✅ 学会功耗检测与分析的基本方法
• ✅ 能够为「民族图鉴」制定功耗优化清单

---

💡 需求分析

为什么要关注功耗？

1. 影响用户留存

用户的手机电量是有限的。如果你的App耗电太快，用户会用脚投票——直接卸载。

用户心理：

• “这个App也没怎么用，怎么电掉这么快？”
• “肯定是后台在偷偷跑，卸载了算了”
• “还是用那个省电的吧”

尤其是工具类应用，用户的使用频率可能不高，但"不耗电"是一个基本要求。

2. 影响应用评价

耗电问题会直接体现在应用商店的评价里。“耗电快”、“手机发烫”，这些负面评价会影响新用户的下载决策。

3. 体现应用品质

一个连功耗都做不好的应用，很难让用户相信它的整体品质。相反，一个"特别省电"的应用，会让用户觉得开发者很用心。

「民族图鉴」作为一个民族文化科普类应用，用户群体可能覆盖各个年龄段。对于老年用户来说，手机电量可能更是他们关注的重点。

手机功耗的构成

手机的耗电主要来自以下几个硬件模块：

模块	功耗占比	说明
屏幕	30%~50%	最大的耗电户，尤其是高亮度下
CPU	20%~30%	应用运行时的主要消耗
网络（WiFi/蜂窝）	10%~20%	数据传输，尤其是蜂窝网络
GPS	5%~15%	高精度定位时非常耗电
传感器	2%~10%	加速度计、陀螺仪、心率等
其他	5%~10%	蓝牙、NFC、震动等

注意：这只是大致的比例，实际情况因使用场景而异。比如导航时GPS可能成为最大耗电户，待机时可能是网络待机最耗电。

对于「民族图鉴」这样的应用，主要涉及的耗电模块是：

• CPU：页面渲染、数据处理、列表滚动
• 网络：如果有网络请求的话
• 定位：地图页面的定位功能
• 屏幕：用户使用时的屏幕点亮（这个是用户主动使用，一般不算应用的锅）

功耗优化的目标，就是在保证功能和体验的前提下，尽可能降低这些模块的能耗。

「民族图鉴」功耗现状分析

让我们看看「民族图鉴」有哪些可能的功耗问题点：

1. 网络请求：

   • AI聊天功能（如果有真实网络请求）
   • 图片加载（56个民族封面图）
   • 音乐播放（如果有在线音乐）

2. 定位功能：

   • 地图页面的定位功能（MapPage.ets）

3. 后台活动：

   • 音乐播放后台运行
   • TTS语音朗读
   • 后台数据同步

4. CPU计算：

   • 列表滚动时的渲染
   • 搜索过滤（56个民族的数据）
   • 动画效果

56个民族的数据量不大，所以CPU计算的压力应该不大。主要需要关注的是网络、定位和后台活动。

---

🔧 核心实现

一、CPU功耗优化

CPU是应用运行的核心，也是功耗的重要来源。CPU运行得越频繁、频率越高，耗电就越多。

1. 减少不必要的计算

最直接的优化就是：能不算的就不算。

常见的不必要计算：

• 重复计算：相同的结果算了多次
• 过度计算：计算的精度超过了需要
• 无效计算：计算了但结果没用上

优化方法：

• 缓存计算结果（记忆化）
• 降低计算频率
• 延迟计算（真的需要时再算）

示例：搜索过滤优化

在「民族图鉴」的列表页（EthnicListPage.ets:83-107），用户每次输入都会触发过滤：

.onChange((value: string) => {
  this.searchText = value;
  this.filterData();  // 每次输入都过滤
})

56个民族的数据量不大，每次过滤的开销可以忽略。但如果数据量很大（比如上万个条目），就需要优化了：

// 防抖：用户停止输入300ms后才过滤
private searchTimer: number = -1;

private onSearchInput(value: string): void {
  this.searchText = value;
  
  // 清除之前的定时器
  if (this.searchTimer !== -1) {
    clearTimeout(this.searchTimer);
  }
  
  // 300ms后执行过滤
  this.searchTimer = setTimeout(() => {
    this.filterData();
  }, 300);
}

防抖（Debounce）不仅能提升响应速度，还能减少CPU计算次数，从而省电。

2. 批量处理

将多个小任务合并成一个大任务批量处理，可以减少CPU唤醒的次数。

原理：CPU有一个特点——启动和切换的开销比较大。如果频繁地唤醒CPU做一点小事，功耗会很高。把这些小事攒起来一次做完，效率更高，也更省电。

示例：批量写入存储

// ❌ 不好：每次操作都写入存储，频繁唤醒CPU
async saveItem(item: string): Promise<void> {
  const list = await this.getList();
  list.push(item);
  await this.put('list', JSON.stringify(list));
}

// ✅ 好：先存在内存里，批量写入
private pendingItems: string[] = [];
private saveTimer: number = -1;

saveItem(item: string): void {
  this.pendingItems.push(item);
  
  if (this.saveTimer === -1) {
    this.saveTimer = setTimeout(() => {
      this.flushSave();
    }, 2000);  // 每2秒批量写入一次
  }
}

private async flushSave(): Promise<void> {
  if (this.pendingItems.length === 0) return;
  
  const list = await this.getList();
  list.push(...this.pendingItems);
  await this.put('list', JSON.stringify(list));
  
  this.pendingItems = [];
  this.saveTimer = -1;
}

对于「民族图鉴」的StorageService，如果写入操作比较频繁，可以考虑这种批量处理的方式。

3. 降低计算频率

对于不需要实时更新的数据，可以降低更新频率。

示例：计时器优化

// ❌ 不好：每秒更新一次，即使界面上只显示到分钟
setInterval(() => {
  this.currentTime = new Date();
}, 1000);

// ✅ 好：每分钟更新一次就够了
setInterval(() => {
  this.currentTime = new Date();
}, 60000);

原则：更新频率只要满足体验需求就行，不要越高越好。

4. 后台时降低CPU使用

当应用进入后台时，应该减少或暂停非必要的计算。

aboutToDisappear(): void {
  // 页面消失时，暂停非必要的计算
  this.isBackground = true;
  this.pauseNonEssentialWork();
}

aboutToAppear(): void {
  // 页面出现时，恢复计算
  this.isBackground = false;
  this.resumeNonEssentialWork();
}

对于「民族图鉴」来说，主要注意：

• 进入后台时，暂停AI对话的轮询
• 页面不可见时，暂停动画效果
• 后台时减少数据刷新频率

二、网络功耗优化

网络是另一个耗电大户。尤其是蜂窝网络（4G/5G），数据传输时的功耗很高。

1. 网络为什么耗电？

网络传输的功耗主要来自两个方面：

1. 无线模块的功率消耗：发射和接收信号需要能量
2. 无线模块的唤醒开销：从待机到激活的切换过程很耗电

蜂窝网络有一个特点：即使只传很少的数据，无线模块也要被唤醒并维持一段时间的高功率状态。这就是为什么频繁的小请求特别耗电——每次请求都要唤醒一次无线模块。

这个效应叫做"尾能耗"（Tail Energy）：数据传完了，无线模块还要保持高功率状态一段时间才会降下来。

2. 合并网络请求

既然每次请求都有唤醒开销，那我们就把多个请求合并成一个，减少唤醒次数。

示例：合并数据请求

// ❌ 不好：多个分散的请求
async loadData(): Promise<void> {
  const userInfo = await this.api.getUserInfo();      // 请求1
  const ethnicList = await this.api.getEthnicList();  // 请求2
  const config = await this.api.getConfig();          // 请求3
}

// ✅ 好：合并成一个请求
async loadData(): Promise<void> {
  const data = await this.api.getInitData();  // 一个请求返回所有数据
  const { userInfo, ethnicList, config } = data;
}

当然，这需要后端接口支持。如果后端不支持，也可以考虑在前端做请求聚合。

对于「民族图鉴」来说，如果有多个初始化请求，可以考虑合并。

3. 减少轮询，改用推送

轮询是最耗电的网络使用方式之一。每隔一段时间就发一次请求，不管有没有新数据。

轮询的替代方案：

• 推送通知：有新数据时服务器推过来（推荐）
• 长连接：建立持久连接，数据实时到达
• 智能轮询：根据使用场景动态调整轮询间隔

示例：智能轮询

// 基础轮询间隔（5分钟）
private baseInterval: number = 5 * 60 * 1000;
// 当前轮询间隔
private currentInterval: number = this.baseInterval;

private startPolling(): void {
  this.pollingTimer = setTimeout(async () => {
    const hasNewData = await this.checkNewData();
    
    if (hasNewData) {
      // 有新数据，缩短间隔
      this.currentInterval = Math.max(this.currentInterval / 2, 30000);
    } else {
      // 无新数据，拉长间隔
      this.currentInterval = Math.min(this.currentInterval * 1.5, this.baseInterval * 2);
    }
    
    this.startPolling();
  }, this.currentInterval);
}

对于「民族图鉴」的AI聊天功能，如果需要轮询获取回复，可以考虑：

• 用户在页面上时，轮询间隔短一些
• 用户离开页面后，轮询间隔拉长或停止
• 有新消息时再加快频率

4. 用好缓存

缓存是减少网络请求的利器。能从缓存读的，就不要发请求。

缓存策略：

• 内存缓存：最快，但退出应用就没了
• 磁盘缓存：慢一些，但持久化
• 混合缓存：先读内存，没有再读磁盘，还没有才发请求

缓存的几个问题：

• 缓存什么：不常变的数据（民族信息、配置等）
• 缓存多久：根据数据的时效性决定
• 怎么更新：定时更新、手动刷新、懒更新

对于「民族图鉴」来说，56个民族的基本信息是相对固定的，完全可以缓存起来，不需要每次都从网络获取。

5. 智能预加载

预加载是"提前把数据加载好"，等用户需要的时候直接用。

预加载的好处：

• 用户体验好：打开就有内容
• 减少请求次数：一次预加载，多次使用

预加载的注意事项：

• 不要在用户用得正嗨的时候预加载，抢占资源
• 预加载的数据要真的有用，不要浪费流量和电量
• 要考虑网络状态：WiFi下多预加载，移动网络下少预加载

示例：WiFi下预加载图片

async preloadImages(images: string[]): Promise<void> {
  const networkType = await this.getNetworkType();
  
  // 只在WiFi下预加载
  if (networkType !== 'wifi') {
    return;
  }
  
  // 批量预加载
  for (const url of images) {
    await this.loadImage(url);
  }
}

对于「民族图鉴」的56张民族封面图，可以考虑：

• 进入列表页时，先加载前10张
• 滚动时，预加载即将显示的图片
• WiFi下可以预加载更多

三、定位功耗优化

GPS是出了名的耗电大户。高精度定位模式下，GPS芯片持续工作，耗电量非常可观。

「民族图鉴」有地图页面（MapPage.ets），会用到定位功能。这部分的功耗优化很重要。

1. 选择合适的定位精度

定位精度越高，耗电越多。根据实际需求选择合适的精度，不要盲目追求高精度。

精度级别：

• 高精度：GPS + 网络 + 基站，最准也最耗电
• 低精度：网络 + 基站，精度稍低但省电
• 被动定位：接收其他应用的定位结果，最省电但不实时

选择原则：

• 导航：必须高精度
• 显示用户位置：低精度通常就够了
• 大概位置：用被动定位或城市级定位

对于「民族图鉴」的地图页面，只是显示用户的大概位置，低精度模式应该就够用了。

2. 减少定位更新频率

定位更新越频繁，耗电越多。根据需求设置合适的更新间隔。

常见场景的更新频率：

• 导航：1秒一次（甚至更频繁）
• 运动记录：几秒一次
• 显示位置：定位到就可以停下来了
• 后台定位：几分钟甚至更久一次

对于「民族图鉴」来说，用户进入地图页面时定位一次就够了，不需要持续更新。除非用户点击"跟随我的位置"之类的功能。

3. 及时关闭定位

不用的时候一定要关掉定位！这是最基本也是最重要的一条。

很多应用的问题是：用户进入地图页面开启了定位，离开时忘了关，结果GPS一直在后台跑，电哗哗地掉。

// 进入页面时开启定位
aboutToAppear(): void {
  this.startLocation();
}

// 离开页面时关闭定位
aboutToDisappear(): void {
  this.stopLocation();  // 一定要关！
}

对于「民族图鉴」的地图页面：

• 用户进入地图时，定位一次显示当前位置
• 用户离开地图时，立即关闭定位
• 不要在后台持续定位

4. 合理使用最后已知位置

如果不需要实时位置，可以先使用最后已知的位置，同时在后台请求更新。

async getCurrentLocation(): Promise<Location> {
  // 先拿最后已知位置，快速响应
  const lastLocation = await this.getLastKnownLocation();
  if (lastLocation) {
    return lastLocation;
  }
  
  // 没有的话再请求新的定位
  return await this.requestNewLocation();
}

这样用户能快速看到位置（虽然可能不是最新的），同时也减少了定位次数。

四、后台功耗优化

后台耗电是用户最不能容忍的——“我都没用这个App，它怎么还在耗电？”

1. 后台能做什么，不能做什么？

鸿蒙系统对后台应用有严格的限制。应用进入后台后，大部分功能都会被限制：

• CPU使用受限
• 网络访问受限
• 定位受限
• 不能启动新页面

这是系统为了省电做的限制，我们应该遵守。如果确实需要在后台运行，要使用系统提供的后台任务机制。

2. 合理使用后台任务

鸿蒙提供了多种后台任务类型，每种类型有不同的限制：

任务类型	适用场景	时间限制
短时任务	短暂的后台操作	约3分钟
长时任务	需要长时间运行的后台任务	需申请，有限制
延迟任务	不需要立即执行的任务	系统调度

短时任务：
用于短暂的后台操作，比如保存数据、完成下载等。

长时任务：
用于确实需要长时间在后台运行的场景，比如音乐播放、导航、下载等。需要申请特定的类型，系统才会允许。

对于「民族图鉴」来说：

• 音乐播放：可以申请音视频长时任务
• TTS朗读：如果朗读时间不长，短时任务可能就够了
• 数据同步：用延迟任务比较合适

3. 进入后台时的优化

应用进入后台时，应该主动做一些优化：

// 应用进入后台
onBackground(): void {
  // 1. 停止非必要的定时器
  this.stopAllTimers();
  
  // 2. 关闭定位（如果在用）
  this.stopLocation();
  
  // 3. 减少网络请求频率
  this.reduceNetworkFrequency();
  
  // 4. 释放不必要的资源
  this.releaseResources();
}

// 应用回到前台
onForeground(): void {
  // 恢复各项功能
  this.restoreAll();
}

4. 避免后台唤醒

不要用各种手段"保活"，不要频繁唤醒系统。

常见的不良做法：

• 用循环定时器保持应用唤醒
• 频繁发送广播唤醒自己
• 用前台服务伪装成长时任务

这些做法不仅耗电，还可能被系统检测到并列入"耗电应用"名单，甚至被应用商店下架。

正确的做法是：信任系统的后台管理，在规则内做事。

五、唤醒锁（WakeLock）的正确使用

什么是唤醒锁？

唤醒锁是一种机制，可以让应用保持CPU运行、屏幕常亮，防止设备进入休眠状态。

常见的唤醒锁类型：

• 屏幕唤醒锁：保持屏幕常亮
• CPU唤醒锁：保持CPU运行（屏幕可以关）

唤醒锁用得好可以提升体验，用不好就是耗电杀手。

什么时候需要唤醒锁？

合理的使用场景：

• 视频播放：屏幕不能暗
• 音乐播放：CPU不能停
• 导航：屏幕和CPU都要保持
• 文件下载：CPU要保持

不合理的使用场景：

• 为了"保活"而持有唤醒锁
• 普通应用长时间持有唤醒锁
• 用完了不释放

正确使用唤醒锁的原则

1. 能用就用，不用就放：需要时申请，用完立即释放
2. 超时保护：设置超时时间，防止忘记释放
3. 最低限度：用最低级别的唤醒锁满足需求
4. 用户感知：持有唤醒锁时让用户知道（比如状态栏通知）

对于「民族图鉴」来说：

• TTS朗读时：可以持有CPU唤醒锁，防止朗读到一半设备休眠
• 音乐播放时：持有音视频长时任务，系统会自动管理
• 其他时候：不需要唤醒锁

六、传感器功耗

手机里有各种传感器：加速度计、陀螺仪、磁力计、光线传感器、距离传感器、心率传感器等等。

不同传感器的功耗差异很大：

传感器	功耗	常用场景
光线/距离传感器	很低	自动亮度、通话息屏
加速度计	低	计步、屏幕旋转
陀螺仪	中	游戏、VR、姿态检测
磁力计	中	指南针
GPS	高	定位、导航
心率传感器	中高	健康监测

传感器使用原则

1. 不用就关：这是最重要的原则
2. 降低采样率：根据需求选择合适的采样频率，不要越高越好
3. 批量读取：让传感器先攒一批数据再读，减少CPU唤醒次数
4. 使用低功耗传感器：如果低功耗的能满足需求，就不要用高功耗的

对于「民族图鉴」来说，目前应该没有用到太多传感器。如果未来要加摇一摇、AR之类的功能，就需要考虑传感器功耗了。

七、功耗检测与分析方法

优化功耗，首先要能测量功耗。不知道哪里耗电，优化就是瞎猜。

1. 系统自带的电量统计

手机设置里的电池页面，可以看到各个应用的耗电排行。这是最直接的参考，也是用户最容易看到的。

能看到什么：

• 每个应用的耗电占比
• 前台使用时间 vs 后台使用时间
• 各个硬件模块的耗电情况（屏幕、CPU、网络、GPS等）
• 自启动次数和唤醒次数

怎么看：

1. 打开「设置」→「电池」→「耗电排行」
2. 找到你的应用，看详细信息
3. 重点看：
   • 前台耗电和后台耗电的比例
   • 有没有异常的后台耗电
   • 唤醒次数是不是太多
   • 定位、网络是不是用得很频繁

局限性：

• 只能看个大概，不够精细
• 不能实时看到具体哪个操作耗电
• 不同手机的统计口径可能不一样

2. DevEco Profiler 功耗分析

DevEco Profiler提供了专门的功耗分析功能，可以实时监测应用的功耗情况。这是我们最主要的分析工具。

能分析什么：

• 实时功耗曲线：功耗随时间的变化
• CPU使用和功耗的关系：CPU占用高的时候功耗是不是也高
• 网络使用和功耗的关系：网络请求频繁的时候功耗变化
• 唤醒锁的持有情况：持有了哪些唤醒锁，持了多久
• 定位使用情况：定位开启的时间和频率
• 传感器使用情况：哪些传感器在工作

怎么用Profiler做功耗分析：

1. 连接设备，打开DevEco Profiler
2. 选择「功耗」模块
3. 开始记录，同时操作应用
4. 操作完成后停止记录
5. 分析功耗曲线，找到高功耗的时间段
6. 对照操作记录，看是什么操作导致了高功耗

分析要点：

• 找功耗峰值：什么时候功耗特别高？
• 看后台功耗：退到后台后功耗有没有降下来？
• 算平均功耗：正常使用时的平均功耗是多少？
• 对比优化前后：优化了之后功耗有没有真的降下来？

3. 功耗测试的基本方法

对比测试法：
这是最常用的测试方法。

1. 测试基础功耗（什么都不做的功耗，作为基线）
2. 测试目标场景的功耗（比如滚动列表10分钟）
3. 两者相减，就是这个场景的额外功耗

长时间测试法：
让应用运行几个小时，看总耗电量。适合测试后台功耗、待机功耗。

步骤：

1. 手机充满电，或者记录初始电量
2. 关闭其他应用，只留测试应用
3. 让应用运行指定时间（比如1小时）
4. 看用了多少电
5. 推算每小时耗电、一天耗电

注意事项：

• 测试环境要一致（同样的设备、同样的网络、同样的亮度）
• 多测几次，取平均值
• 用同样的操作路径，减少人为差异
• 注意温度影响，手机太热会降频

4. 代码层面的功耗监控

除了用工具测，我们也可以在代码里加一些监控，帮助定位功耗问题。

监控点示例：

// 网络请求监控
class NetworkMonitor {
  private requestCount: number = 0;
  private startTime: number = 0;

  startMonitoring() {
    this.startTime = Date.now();
    this.requestCount = 0;
  }

  recordRequest(url: string) {
    this.requestCount++;
    console.log(`[NetworkMonitor] 请求 #${this.requestCount}: ${url}`);
  }

  getStats() {
    const duration = (Date.now() - this.startTime) / 1000;
    console.log(`[NetworkMonitor] ${duration}秒内发起了 ${this.requestCount} 次请求`);
    console.log(`[NetworkMonitor] 平均每 ${duration / this.requestCount} 秒一次请求`);
  }
}

// 定位监控
class LocationMonitor {
  private locationCount: number = 0;
  private totalDuration: number = 0;
  private lastStartTime: number = 0;
  private isRunning: boolean = false;

  startLocation() {
    if (this.isRunning) return;
    this.isRunning = true;
    this.lastStartTime = Date.now();
    this.locationCount++;
    console.log(`[LocationMonitor] 第 ${this.locationCount} 次开启定位`);
  }

  stopLocation() {
    if (!this.isRunning) return;
    this.isRunning = false;
    const duration = Date.now() - this.lastStartTime;
    this.totalDuration += duration;
    console.log(`[LocationMonitor] 定位关闭，持续了 ${duration}ms`);
    console.log(`[LocationMonitor] 累计定位时间: ${this.totalDuration}ms`);
  }
}

这些监控可以帮助我们在开发阶段就发现一些明显的功耗问题，比如：

• 短时间内发起了大量网络请求
• 定位开了忘了关
• 定时器太频繁

💡 功耗分析的思路：

1. 先看整体：耗电是不是在正常范围？
2. 再找大头：哪块耗电最多？（屏幕？CPU？网络？GPS？）
3. 再定位具体问题：是哪个功能、哪段代码导致的？
4. 优化后验证：优化了之后真的省电了吗？

思路和性能优化是一样的，都是从宏观到微观，一步步定位。

八、实战：「民族图鉴」功耗优化清单

让我们为「民族图鉴」制定一份详细的功耗优化清单。

高优先级

优化项	说明	位置
定位及时关闭	离开地图页时立即停止定位	MapPage.ets
减少轮询	AI聊天的轮询间隔优化，后台时降低频率	AIService.ets
图片缓存	封面图缓存，避免重复下载	图片加载模块
后台暂停定时器	进入后台时停止非必要的定时器	各个页面

中优先级

优化项	说明	位置
搜索防抖	搜索输入防抖，减少过滤次数	EthnicListPage.ets
批量存储	StorageService批量写入	StorageService.ets
预加载优化	WiFi下才预加载图片，移动网络按需加载	图片加载模块
定位精度选择	地图页使用低精度定位	MapPage.ets

低优先级

优化项	说明	位置
列表优化	减少列表滚动时的CPU开销	列表页面
动画优化	不可见时暂停动画	各个页面
长时任务	音乐播放使用长时任务	MusicService.ets

优化检查流程

每次发布新版本前，检查以下几点：

1. 后台运行1小时，看耗电是否异常
2. 定位功能是否及时关闭
3. 有没有不必要的后台网络请求
4. 唤醒锁是否正确释放
5. 动画和定时器是否在后台暂停

---

九、省电模式设计思路

除了被动优化，我们还可以主动给用户提供省电选项。让用户根据自己的需求和电量情况，选择合适的模式。

为什么要做省电模式？

用户痛点：

• 手机快没电了，想省点电用
• 某些应用太耗电，想限制一下
• 不同场景下对性能和功耗的需求不一样

省电模式的意义：

• 给用户选择权
• 体现应用的贴心和专业
• 应对低电量场景
• 差异化竞争的一个点

省电模式的三个档位

可以设计三个档位，让用户根据需求选择：

1. 均衡模式（默认）

• 正常的性能和功耗
• 该有的功能都有
• 动画正常播放
• 网络正常请求
• 适合大多数场景

2. 省电模式

• 降低一些性能要求，换取更长的续航
• 动画简化或关闭
• 网络请求频率降低
• 图片质量降低
• 后台刷新减少
• 适合电量不太充足的时候

3. 超级省电模式

• 极致省电，只保留核心功能
• 只看文字，不加载图片
• 关闭动画效果
• 关闭后台刷新
• 只在WiFi下联网
• 适合电量很低的时候应急

省电模式的具体实现思路

enum PowerMode {
  BALANCED = 'balanced',    // 均衡模式
  POWER_SAVING = 'saving',  // 省电模式
  SUPER_SAVING = 'super',   // 超级省电
}

class PowerManager {
  private currentMode: PowerMode = PowerMode.BALANCED;

  setMode(mode: PowerMode) {
    this.currentMode = mode;
    this.applyMode();
  }

  private applyMode() {
    switch (this.currentMode) {
      case PowerMode.BALANCED:
        this.applyBalancedMode();
        break;
      case PowerMode.POWER_SAVING:
        this.applyPowerSavingMode();
        break;
      case PowerMode.SUPER_SAVING:
        this.applySuperSavingMode();
        break;
    }
  }

  private applyBalancedMode() {
    // 均衡模式：正常配置
    AnimationConfig.setDurationScale(1.0);
    ImageLoader.setQuality('high');
    NetworkManager.setPollingInterval(30000); // 30秒
  }

  private applyPowerSavingMode() {
    // 省电模式：适度优化
    AnimationConfig.setDurationScale(0.5);
    ImageLoader.setQuality('medium');
    NetworkManager.setPollingInterval(60000); // 1分钟
    // 关闭一些非必要的动画
    // 降低预加载的频率
  }

  private applySuperSavingMode() {
    // 超级省电：极致优化
    AnimationConfig.setDurationScale(0); // 关闭动画
    ImageLoader.setQuality('low');
    ImageLoader.setAutoLoad(false); // 不自动加载图片，用户点击再加载
    NetworkManager.setPollingInterval(300000); // 5分钟
    NetworkManager.setWifiOnly(true); // 仅WiFi下联网
    // 关闭后台刷新
    // 关闭所有非核心功能
  }

  shouldEnableAnimation(): boolean {
    return this.currentMode !== PowerMode.SUPER_SAVING;
  }

  shouldAutoLoadImage(): boolean {
    return this.currentMode !== PowerMode.SUPER_SAVING;
  }

  getImageQuality(): string {
    switch (this.currentMode) {
      case PowerMode.BALANCED: return 'high';
      case PowerMode.POWER_SAVING: return 'medium';
      case PowerMode.SUPER_SAVING: return 'low';
    }
  }
}

自动切换的思路

除了手动切换，还可以考虑自动切换：

基于电量自动切换：

• 电量 > 50%：均衡模式
• 电量 20%-50%：提示用户开启省电模式
• 电量 < 20%：自动切换到省电模式（可关闭）

基于网络自动切换：

• WiFi环境：正常加载，预加载
• 移动网络：降低图片质量，减少预加载

基于时间自动切换：

• 夜间：降低后台活动频率

💡 关于省电模式的建议：
对于「民族图鉴」这样的应用，初期可以先不做省电模式。
先把基础的功耗优化做好，确保正常使用下耗电正常。
如果用户反馈耗电问题，或者想做差异化体验，再考虑加上省电模式。
功能是做不完的，要分清主次。

---

⚠️ 功耗优化的常见误区

功耗优化路上有很多坑，有些做法看似在省电，实际上反而更耗电。让我们盘点一下常见的误区。

误区1：为了省电，什么功能都砍掉

表现：

• 把推送关了，把后台刷新关了，把定位关了
• 结果应用变得很难用，用户反而卸载了

问题：

• 功耗优化是为了提升用户体验，不是牺牲体验
• 该有的功能没有，用户直接就走了
• 省电省到应用不好用，得不偿失

正确做法：

• 核心功能不能省
• 用户感知强的体验不能省
• 在用户感知不到的地方优化
• 提供选项，让用户自己选（省电模式/均衡模式）

误区2：后台杀得越干净越省电

表现：

• 应用一退到后台就把所有东西都停了
• 用户切回来什么都要重新加载

问题：

• 频繁启动和销毁，反而更耗电
• 冷启动比热启动耗电多了
• 用户体验很差，每次回来都要等

正确做法：

• 合理利用系统的后台管理
• 不要自己瞎杀进程
• 该保留的保留，该释放的释放
• 热启动比冷启动更快也更省电

误区3：用定时器做心跳保活

表现：

• 每分钟唤醒一次，就为了"保活"
• 其实根本没有事情要做

问题：

• 频繁唤醒CPU和无线模块
• 每次唤醒都有额外的功耗开销
• 这是最常见的"偷电"行为
• 用户发现了直接卸载

正确做法：

• 不要做无谓的保活
• 信任系统的后台管理
• 真的需要后台运行，用系统提供的后台任务API
• 不要用"歪门邪道"保活

误区4：为了省流量，不做任何缓存

表现：

• 每次都从网络重新加载
• 美其名曰"省内存"

问题：

• 网络请求的功耗比内存大多了
• 重复下载同样的数据，浪费流量也浪费电
• 用户体验还差，每次都要等

正确做法：

• 合理使用缓存
• 不常变的数据缓存起来
• 缓存有上限，不会无限增长
• 省流量和省电不矛盾

误区5：动画越简单越省电

表现：

• 把所有动画都关了
• 界面干巴巴的，体验很差

问题：

• 动画的功耗其实很低
• 比起CPU和网络，动画那点电可以忽略
• 为了省这点电，牺牲体验不值得

正确做法：

• 正常使用动画，不用太担心耗电
• 优化动画性能（用transform/opacity），让动画更流畅也更省电
• 只在低端机上考虑精简动画
• 不要因为省电把应用做得很难用

误区6：功耗优化只是后端/系统的事

表现：

• “功耗是系统管的，我应用层管不了”
• “服务器优化好就行，客户端不用管”

问题：

• 应用的行为直接影响功耗
• 发多少请求、用不用定位、后台跑不跑任务，都是应用决定的
• 客户端不优化，后端再怎么优化也没用

正确做法：

• 客户端是功耗优化的重要一环
• 从设计阶段就考虑功耗
• 每加一个功能都想想：会不会增加耗电？
• 前后端一起优化，效果才最好

误区7：只看前台功耗，不管后台功耗

表现：

• 前台用的时候挺省电
• 退到后台后哗哗掉电

问题：

• 用户更在意后台耗电
• “我都没用这个App，怎么电还掉这么快？”
• 后台耗电是用户卸载App的重要原因

正确做法：

• 后台功耗比前台更重要
• 进入后台时主动释放资源
• 后台只做必须做的事情
• 定期检查后台耗电情况

误区8：省电模式就是砍功能

表现：

• 一说做省电模式，就把一半功能砍了
• 用户开了省电模式，就给个"残废版"

问题：

• 省电模式不应该是"阉割版"
• 用户开省电模式是想省点电，不是想不用了
• 核心功能和体验还是要保证

正确做法：

• 省电模式是优化，不是阉割
• 减少非必要的网络请求
• 降低更新频率
• 关闭一些锦上添花的效果
• 核心功能和体验保持不变

💡 功耗优化的正确姿势：
不是"能省就省"，而是"该用就用，不该用就不用"。
在保证用户体验的前提下，尽可能减少不必要的功耗。
好的功耗优化，用户是感觉不到的——只觉得"这个App挺省电的"，但不知道为什么。

---

❓ 常见问题

Q1：我的应用只是展示静态内容，为什么也耗电？

即使是展示静态内容，也会有耗电：

• 屏幕亮着就要耗电（这部分通常算在用户头上）
• CPU需要维持应用运行
• 内存占用也会间接影响功耗（系统需要更多的内存管理）

但正常情况下，静态应用的耗电应该很低。如果耗电异常，可能的原因：

• 后台有定时器在跑
• 有网络请求在轮询
• 定位没关
• 有唤醒锁没释放

建议用功耗工具测一下，看看具体是哪部分在耗电。

Q2：后台耗电怎么排查？

后台耗电是最常见的功耗问题。排查步骤：

1. 确认是否真的是后台耗电：

   • 看电池设置里，后台耗电占比高不高
   • 对比前台和后台的使用时间和耗电比例

2. 检查后台活动：

   • 有没有后台任务在运行
   • 有没有定时器在跑
   • 有没有网络请求在轮询

3. 检查系统资源：

   • 定位是否关闭
   • 唤醒锁是否释放
   • 传感器是否关闭

4. 使用工具分析：

   • 用DevEco Profiler查看后台功耗
   • 看CPU唤醒次数
   • 看网络使用情况

Q3：定位耗电特别多怎么办？

定位是耗电大户。如果你的应用定位耗电多，可以从以下几个方面优化：

1. 降低精度：

   • 如果不需要高精度，就用低精度模式
   • 低精确定位功耗可能只有高精度的1/3到1/5

2. 减少频率：

   • 不需要持续定位的，就定位一次就好
   • 需要持续定位的，拉长更新间隔

3. 及时关闭：

   • 用户离开相关页面时，立即关闭定位
   • 进入后台时，关闭定位
   • 长时间不操作时，自动关闭定位

4. 最后已知位置：

   • 先展示最后已知位置，再慢慢更新
   • 减少用户等待，也减少定位次数

对于「民族图鉴」的地图页，建议：

• 用户刚进入时定位一次，显示当前位置
• 用户点击"重新定位"时再定位
• 离开页面立即关闭
• 不要持续定位跟踪

Q4：手机发热严重是怎么回事？

发热和功耗是相关的——功耗越高，发热越严重。但发热还有其他原因：

1. CPU高负载：长时间大量计算
2. GPU高负载：复杂的动画、游戏
3. 网络传输频繁：持续高速下载/上传
4. 充电时使用：充电本身就会发热
5. 环境温度高：夏天本来就容易发热

优化方法：

• 减少CPU计算量
• 降低动画复杂度
• 减少网络请求频率
• 避免在充电时做重操作

如果「民族图鉴」也会导致发热，重点检查：

• 列表滚动时是不是有大量计算
• 动画是不是太复杂
• 有没有持续的网络请求

Q5：用了推送就一定比轮询省电吗？

大多数情况下是的，但不是绝对的。

推送省电的原因：

• 不需要应用自己维持连接
• 系统统一维护推送通道
• 只有真的有消息时才唤醒应用

但要注意：

• 如果推送太频繁，也会耗电（频繁唤醒应用）
• 推送服务本身也有一定的功耗（但通常比轮询小很多）

所以推送也要合理使用，不要什么事情都发推送，打扰用户还耗电。

Q6：怎么判断功耗优化有没有效果？

要量化优化效果，需要做对比测试。

测试方法：

1. 固定环境：

   • 同一台设备
   • 同一个系统版本
   • 同样的网络环境
   • 同样的亮度设置

2. 测试基线版本：

   • 运行相同的场景
   • 记录耗电量、CPU、网络等数据

3. 测试优化版本：

   • 运行相同的场景
   • 记录相同的数据

4. 对比分析：

   • 看哪些指标改善了
   • 改善了多少
   • 有没有副作用

常用指标：

• 单位时间耗电量（mAh/h）
• CPU使用率（%）
• 网络流量（MB）
• 唤醒次数（次/小时）

Q7：功耗优化会不会影响功能和体验？

有可能。功耗优化本质上是在"功能/体验"和"功耗"之间找平衡。

常见的权衡：

• 定位精度 vs 功耗
• 刷新频率 vs 功耗
• 预加载 vs 功耗
• 动画效果 vs 功耗

原则：

• 核心功能不能妥协
• 用户感知强的体验不能妥协
• 用户感知不到的地方，尽量优化
• 提供选项，让用户自己选择（比如"省流量模式"、“省电模式”）

比如「民族图鉴」可以加一个"省电模式"：

• 关闭动画效果
• 降低图片质量
• 减少网络预加载
• 延长数据刷新间隔

让在意功耗的用户自己选择开启。

---

📝 小结

本文详细介绍了鸿蒙应用功耗优化的各个方面。让我们总结一下：

核心知识点

1. 功耗构成：屏幕（最大）、CPU、网络、GPS、传感器、唤醒
2. CPU优化：减少计算、批量处理、降低频率、后台降载
3. 网络优化：合并请求、减少轮询、用好缓存、智能预加载
4. 定位优化：选择合适精度、减少更新频率、及时关闭
5. 后台优化：遵守后台限制、合理使用后台任务、进入后台主动优化
6. 唤醒锁：需要时申请，用完立即释放，设置超时保护
7. 传感器：不用就关、降低采样率、批量读取
8. 检测方法：系统电量统计、DevEco Profiler、对比测试

「民族图鉴」优化清单

高优先级：

• 地图页定位及时关闭
• AI聊天轮询优化
• 图片缓存
• 后台暂停非必要定时器

中优先级：

• 搜索防抖
• 批量存储
• 预加载优化（WiFi下才预加载）
• 定位精度选择

功耗优化的核心思维

功耗优化的本质是：在满足用户需求的前提下，尽可能少地使用硬件资源。

记住几个原则：

1. 能不用就不用：不用的功能、模块、资源，都关掉
2. 能少用就少用：需要用的，也尽量降低使用频率和强度
3. 批量高效：把多次操作合并成一次，提高效率
4. 场景感知：根据不同场景（前台/后台、WiFi/移动网络）调整策略

功耗优化不是一次性的工作，而是需要持续关注。每次加新功能时，都要想想：这个功能会增加多少功耗？有没有更省电的实现方式？

下一篇，我们将介绍性能监控与分析工具——DevEco Profiler，教你如何用专业工具发现和定位性能问题。