应用发烫和耗电问题，本质上是硬件资源被过度消耗的外在表现。CPU持续高负载会让芯片温度快速上升，GPU过度绘制推高屏幕渲染开销，网络模块频繁唤醒无线芯片（Radio State），这三者叠加在一起，用户感受到的就是机身发烫、电量骤降、体验变差。要做好功耗优化，第一步不是盲目改代码，而是先弄清楚电到底被谁吃掉了，再针对性地下手。本文按照CPU、GPU、网络三个方向，分别讲清楚问题成因、排查工具和具体的优化手段。
一、先定位：用工具找到耗电热点
功耗优化最忌讳凭感觉改代码。Android提供了多套官方工具，建议按顺序组合使用。首先是Android Studio的Profiler，打开Energy面板可以直接看到CPU、Network、Radio三部分的能耗曲线，时间段上哪个模块异常一目了然。
其次是Battery Historian，它是Google开源的电池分析工具，通过导出的bugreport数据，可以看到WakeLock持有时长、Alarm唤醒次数、网络状态切换等细粒度信息。导出命令如下：
# 采集数据（复位电量统计后操作一段时间） adb shell dumpsys batterystats --reset # 导出bugreport文件 adb bugreport bugreport.zip # 用Battery Historian网页工具加载分析
最后是Systrace（或新版Perfetto），适合分析某一段操作内CPU具体在忙什么，比如某个页面滑动时是否主线程被频繁阻塞、是否有多余的线程在空转。三个工具各有侧重：Profiler看宏观曲线，Battery Historian看系统级事件，Systrace看微观调用。定位阶段建议三者结合，避免误判。
二、CPU优化：消灭空转和不必要的高负载
CPU是发热的第一大来源。常见的CPU浪费场景包括：轮询代替事件通知、主线程做重计算、频繁的GC、以及持有WakeLock导致CPU无法休眠。其中轮询问题最普遍，很多开发者为了实现状态刷新，习惯性写一个定时器每隔几秒查一次接口，这种写法在息屏状态下会持续唤醒CPU，功耗非常可观。
改进思路是事件驱动：有新数据时由服务端推送（如长连接通道），本地不需要主动轮询。如果确实需要定时任务，优先使用JobScheduler或WorkManager，它们会在系统层面合并多个应用的唤醒时机，并且支持充电状态、网络类型等约束条件，比裸用Handler.postDelayed省电得多：
// 使用WorkManager调度周期任务，系统会自动合并唤醒
PeriodicWorkRequest request = new PeriodicWorkRequest.Builder(
SyncWorker.class,
6, TimeUnit.HOURS) // 最小周期就是6小时，不要试图设得更短
.setConstraints(new Constraints.Builder()
.setRequiredNetworkType(NetworkType.UNMETERED) // 仅在WiFi下执行
.setRequiresBatteryNotLow(true) // 电量低时不执行
.build())
.build();
WorkManager.getInstance(context).enqueueUniquePeriodicWork(
"sync_task", ExistingPeriodicWorkPolicy.KEEP, request);
WakeLock也是重灾区。持有没有超时的PARTIAL_WAKE_LOCK，等于亲手禁止CPU休眠。规范做法是：必须设置超时时间，用完立刻释放，并且在finally块中保证释放路径一定会执行：
PowerManager pm = (PowerManager) getSystemService(POWER_SERVICE);
PowerManager.WakeLock wl = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "myapp:tag");
wl.acquire(10 * 60 * 1000L); // 设置10分钟超时，防止忘记释放
try {
// 执行真正需要保持唤醒的工作
} finally {
if (wl.isHeld()) {
wl.release();
}
}
另外，主线程上的重计算要通过Profiler的CPU火焰图排查，把JSON大文件解析、图片解码等操作移到后台线程，并对列表场景做好对象复用，减少GC压力。GC虽然不直接消耗大量CPU，但频繁GC会打断执行流水线，间接推高CPU占用。
三、GPU优化：过度绘制与动画治理
GPU层面的功耗浪费，最典型的是过度绘制（Overdraw）。所谓过度绘制，就是同一块像素被重复绘制多次。比如页面背景已经由Window设置了一次，根布局又画一次背景色，再叠一层卡片背景，同一像素就画了三次，其中两次完全是白费电。检测方法很简单：开发者选项里打开调试GPU过度绘制，屏幕上会以颜色区分，红色区域代表绘制了4次以上，是需要重点治理的地方。
治理手段包括：Window层面设置背景后，移除无意义的布局背景；避免多层嵌套容器各自带背景；使用FlatConstraintLayout等扁平化方案减少布局层级。除了绘制次数，动画也是GPU耗电大户。持续的属性动画会强制屏幕以60帧甚至120帧刷新，如果动画对象不可见（比如已经被滑动出屏幕），一定要及时取消：
@Override
protected void onDetachedFromWindow() {
super.onDetachedFromWindow();
// 控件离屏时停止动画，避免GPU空转
if (animator != null && animator.isRunning()) {
animator.cancel();
}
}
对于持续性的呼吸灯、跑马灯类效果，建议做降帧处理，比如从60帧降到30帧，视觉效果差异很小，但GPU负载直接减半。同时注意SurfaceView和TextureView的选择：视频播放场景SurfaceView由独立合成器处理，功耗明显低于TextureView；而需要做透明、旋转等变换时才用TextureView。
四、网络优化：减少Radio唤醒次数
移动网络芯片有活跃态和休眠态，从休眠切换到活跃需要较高能耗，且切换后并不会立刻回到休眠，而是保持几十秒的高功耗状态。这意味着，网络优化的核心不是减少传输的数据量，而是减少请求的次数和分散程度。十条间隔五秒的小请求，功耗远高于一次性传输十条数据的一个请求。
具体做法上，第一是请求合并与批量上传：把埋点、日志这类高频上报攒批处理，配合WorkManager在网络可用时统一发送。第二是预加载与缓存：对确定性强的数据（如列表下一页内容）在WiFi时提前拉取，弱网环境直接读本地缓存。第三是长连接心跳调优，心跳间隔过短会频繁唤醒Radio，过长又可能被运营商NAT断开，一般建议在4到8分钟之间，并根据网络类型动态调整：
// 根据网络类型动态设置心跳间隔
long heartbeatInterval;
switch (networkType) {
case NETWORK_WIFI:
heartbeatInterval = 8 * 60 * 1000L; // WiFi下NAT超时较长
break;
case NETWORK_4G:
heartbeatInterval = 4 * 60 * 1000L; // 4G下缩短心跳
break;
default:
heartbeatInterval = 5 * 60 * 1000L;
}
handler.postDelayed(this::sendHeartbeat, heartbeatInterval);
此外还要注意压缩策略。开启HTTP/2可以复用连接减少握手，请求体和响应体用Gzip或Brotli压缩，图片按实际显示尺寸和屏幕密度请求对应规格，不要让客户端下载一张4096像素的大图再缩到200像素显示，这部分解码的CPU开销和流量浪费都是白给的功耗。
五、建立常态化的功耗监控
优化不是一次性的工作，版本迭代中很容易引入新的功耗问题。建议在自动化测试中接入功耗基线对比：每次发版前跑固定时长、固定场景的脚本，用batterystats记录数据并与历史版本对比，CPU均值、唤醒次数、网络请求次数任何一项超出阈值就阻断发布。线上则可以收集设备的电池温度、耗电排行等匿名指标，圈出异常机型和异常场景做针对性治理。
总结一下方法论：先用工具定位，再分模块治理。CPU方向消灭空转和滥用WakeLock，GPU方向控制过度绘制和无效动画，网络方向合并请求、调优心跳。三个方向逐项落地，应用的温度和耗电表现通常会有明显改善，用户留存和商店评分也会随之受益。