Energy Profiler：电池耗电分析、识别后台高耗电行为、优化应用电量消耗
做 Android 开发这么多年，我遇到过不少用户反馈：「你这 App 装上去，手机半天就没电了」。说实话，每次听到这种话，心里都咯噔一下。电量优化这事儿，看着不起眼，但直接影响用户体验。今天我就带你彻底搞懂 Energy Profiler 这个工具，看看怎么揪出那些偷电的「内鬼」。
为什么你的 App 会「吃电」？
先想一个问题：手机电池的电，到底被谁吃掉了？
说白了，Android 设备上的耗电大头就这几类：
- 屏幕亮着 —— 这是最狠的，尤其是高刷屏
- CPU 在干活 —— 代码写得烂，CPU 就一直在跑
- 网络在收发 —— Wi-Fi、4G/5G 模块都是电老虎
- GPS 在定位 —— 这个尤其费电
- WakeLock 没释放 —— 手机想睡，你不让睡
我个人习惯，拿到一个新项目，第一件事就是打开 Energy Profiler 跑一遍。不是为了找 bug，而是看看这个 App 的「用电画像」正不正常。
核心观点：Energy Profiler 不会直接告诉你「你的 App 用了多少毫安时」，但它会告诉你「你的 App 在什么时间段、因为什么原因、消耗了多少系统资源」。这比看电量百分比有用多了。
Energy Profiler 长什么样？
打开方式很简单：Android Studio 底部工具栏 -> Profiler -> 选择 Energy。
你会看到一条时间轴，上面用不同颜色标记了各个系统组件的活动状态：
| 颜色 | 代表什么 | 说明 |
|---|---|---|
| 绿色 | Low | 基本没干啥，正常待机状态 |
| 黄色 | Medium | 有轻度活动，比如网络请求、UI 更新 |
| 红色 | High | 高耗电行为，比如持续 GPS、大量网络传输 |
嗯，这里要注意：红色不代表一定有 bug，但如果你发现 App 在后台待机时还频繁出现红色区域，那就有问题了。
如何识别后台高耗电行为？
我曾经接手过一个项目，用户反馈说「晚上睡觉前充满电，早上起来掉了 30%」。一查，原来是某个后台 Service 每 5 秒发起一次网络请求，而且用了 PARTIAL_WAKE_LOCK 不让手机休眠。
用 Energy Profiler 抓这种问题，我一般分三步走：
- 先跑一次正常场景 —— 打开 App，正常操作几分钟，看看基线耗电情况
- 按 Home 键退到后台 —— 观察 1-2 分钟，看后台有没有异常活动
- 对比分析 —— 如果后台时段出现大量黄色/红色区域，说明有问题
具体操作时，我会配合 Event 时间轴一起看。比如在 Energy Profiler 的时间轴上，你可以看到 CPU、Network、Location 等子项的详细活动曲线。
小技巧：在 Energy Profiler 中，你可以按住鼠标左键拖选一段区域，然后右键选择「Export as CSV」。这样就能把这段时间的耗电数据导出来，做更精细的分析。
优化应用电量消耗的实战套路
找到问题之后，怎么改？我总结了一套「三板斧」，你照着做基本能解决 80% 的电量问题。
第一板斧：砍掉不必要的 WakeLock
WakeLock 这东西，说白了就是「我命令手机不许睡」。很多开发者图省事，直接拿一个 WakeLock 把整个后台任务包起来。结果任务跑完了，WakeLock 忘了释放。
// 错误示范：拿到 WakeLock 不释放
PowerManager pm = (PowerManager) getSystemService(POWER_SERVICE);
PowerManager.WakeLock wl = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyApp:Tag");
wl.acquire();
// 执行耗时任务...
// 忘了 wl.release()正确的做法是：用 acquire(timeout) 设置超时，或者用 try-finally 保证释放。
// 正确做法：设置超时，自动释放
wl.acquire(10_000); // 最多持有 10 秒第二板斧：合并网络请求
网络模块是电老虎。每次建立连接、断开连接，都要消耗不少电量。我见过最夸张的代码，是一个循环里每 200 毫秒发一次 HTTP 请求。你想想看，这手机电池能撑多久？
优化思路很简单：
- 用
JobScheduler或WorkManager把零散请求合并成批量请求 - 设置合理的间隔时间，比如至少 1 分钟以上
- 利用
ConnectivityManager监听网络状态，只在 Wi-Fi 下做大数据传输
第三板斧：GPS 定位别一直开着
GPS 模块的耗电，是 Wi-Fi 定位的 10 倍以上。很多 App 一启动就调用 requestLocationUpdates()，然后就不管了。
我的建议是：
- 能不用 GPS 就不用，优先用
NetworkProvider - 必须用 GPS 时，设置最小时间间隔（比如 60 秒）和最小距离变化（比如 100 米）
- 页面不可见时，记得
removeUpdates()
避坑指南：我曾经在某个版本里用了 FusedLocationProviderClient 的 getCurrentLocation()，以为它只请求一次就不耗电了。结果发现它内部会先尝试 GPS 获取，如果超时再降级到网络定位。在信号差的地方，GPS 模块会一直工作直到超时。后来我改成先判断网络定位是否可用，再决定是否调用 GPS。
知识体系总览
下面这张图，是我自己总结的 Energy Profiler 使用和电量优化的完整流程。你可以把它当作一个检查清单：
写在最后
电量优化这件事，说白了就是「让手机该睡的时候睡，该干活的时候高效干活」。Energy Profiler 是你手里的探照灯，帮你照清楚那些藏在暗处的耗电行为。
我个人习惯，每次发布新版本之前，都会用 Energy Profiler 跑一遍全流程测试。不是为了应付检查，而是真的怕用户骂娘。你想想看，一个 App 功能再强，如果装上之后手机半天就没电，用户第一反应肯定是卸载，而不是夸你功能做得好。
嗯，今天就聊到这儿。记住那三板斧：管好 WakeLock、合并网络请求、省着用 GPS。把这三点做到位，你的 App 在电量这块基本就及格了。