📚 课程目录第2章前台服务与CPU占用

前台服务与CPU占用：前台服务为何会导致高CPU占用？

前台服务，说白了就是一个挂了通知的Service。系统会给它高优先级，不会轻易杀掉它。但这玩意儿不是让你为所欲为的——我见过太多团队，以为前台服务就是「免死金牌」，在里面拼命干活，结果CPU直接飙到80%以上。

为什么会这样？因为前台服务本身只是一个"保活"机制，它不限制你的计算行为。你在里面写个死循环，系统也不会拦你。CPU占用高，从来不是前台服务的错，是你写的代码在"裸奔"。

    核心认知：前台服务 ≠ 高性能计算容器。它只是给了你一个不被杀死的"舞台"，演什么戏、怎么演，全看你自己的设计。

前台服务的"保活"幻觉

很多开发者对前台服务有个误解：认为系统会全力保住它，所以可以在里面随便跑任务。我早期做过一个IM项目，团队里有人直接在 onStartCommand 里写了个 while(true) 做心跳长轮询——觉得前台服务嘛，不会被杀。结果呢？CPU占用直接吃掉一个核，手机发烫，用户直接卸载。

前台服务的优先级确实高，但高优先级 ≠ 高性能授权。它只是告诉系统：「这个进程别轻易杀我」，至于你在这个进程里干什么、怎么干，系统根本不管。

我个人的习惯：启动前台服务之前，先问自己三个问题——这个任务必须常驻吗？能退到后台吗？间隔时间是否可以拉长？想清楚再动手。

CPU占用的四大元凶

在我看过的几十个前台服务CPU飙升案例里，原因基本逃不出下面这四类。一个一个说。

原因	典型表现	后果
线程设计不合理	主线程阻塞、线程池无限扩张	ANR + 高频上下文切换
定时任务密集	Handler 10ms间隔、AlarmManager秒级触发	CPU 空转、电池快速耗尽
无节制轮询	网络/传感器轮询间隔 ≤100ms	CPU 持续满载、Binder 通道拥堵
锁与WakeLock滥用	持锁做密集计算、锁粒度太大	线程饥饿、系统无法深度休眠

1. 线程设计不合理

最常见的问题。有人直接在 onStartCommand 里做网络请求或数据库写入，阻塞主线程。还有人用 new Thread() 但不控制并发数，任务一多线程数蹭蹭往上涨。

// ❌ 错误示例：主线程直接执行耗时操作
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
    fetchDataFromNetwork();  // 主线程阻塞！
    return START_STICKY;
}

// ❌ 错误示例：无限制创建线程
new Thread(() -> {
    while (true) {
        pollSensorData();      // 高频轮询
        Thread.sleep(50);
    }
}).start();

我曾经踩过这个坑：在一个物流追踪应用里，前台服务每100ms轮一次GPS，没加任何节流。结果CPU占用持续35%以上，用户手机发烫不说，后台直接被系统限频。后来改成了「自适应间隔+低功耗定位」，CPU占用直接降到3%以下。

2. 定时任务密集

Handler 配合 postDelayed 做定时任务，本身没问题。但如果你间隔设得太短（比如10ms），且任务本身有耗时操作，那消息队列就会积压，CPU 就在「处理消息→等下一个消息」之间疯狂切换。

记住：定时任务的频率，决定了CPU空转的代价。我建议任何前台服务里的定时任务，间隔不要低于200ms。除非你有非常特殊的实时性要求。

3. 无节制轮询

轮询网络、轮询传感器、轮询内容提供者……前台服务最常见的"死法"就是轮询。你想想看，一个 while(true){ fetch(); sleep(100); } 跑在前台服务里，CPU 几乎每100ms就要被唤醒一次，系统不卡才怪。

我一般会用 WorkManager 配合 Constraints 来做周期任务，或者至少使用 HandlerThread 把轮询放到独立线程，并加一个「退避策略」——如果连续几次取到空数据，就拉长间隔。

4. 锁与WakeLock滥用

WakeLock 是防止CPU休眠的"强权工具"。很多人拿了锁就不放，甚至在持锁期间做大量计算。CPU没法休眠，温度上升，系统触发温控降频——结果就是前台服务本身的执行效率也下降了。

还有锁竞争的问题。多个线程抢同一把锁，上下文切换的开销比实际干活还大。说白了，前台服务里的锁设计，要遵循「小粒度、短持有」原则。

    避坑指南（我曾经的经验）：前台服务里尽量不要用 synchronized 块包围耗时操作。如果真的需要同步，用 ReentrantLock + tryLock(timeout)，避免死锁和无限等待。

代码实操：一个"危险"的前台服务

下面这个例子综合了上面四个问题。你可以对照着看看，你的项目里有没有类似的"定时炸弹"。

public class DangerousService extends Service {
    private Handler handler = new Handler(Looper.getMainLooper());
    private PowerManager.WakeLock wakeLock;

    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        // 拿锁不放手
        PowerManager pm = (PowerManager) getSystemService(POWER_SERVICE);
        wakeLock = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "Danger:lock");
        wakeLock.acquire();

        // 高频定时任务，直接跑在主线程
        handler.postDelayed(new Runnable() {
            @Override
            public void run() {
                fetchData();          // 网络请求阻塞主线程
                processData();        // 大量计算
                handler.postDelayed(this, 50); // 50ms 间隔！
            }
        }, 0);

        return START_STICKY;
    }

    private void fetchData() { /* 网络请求 */ }
    private void processData() { /* CPU密集计算 */ }

    @Override
    public void onDestroy() {
        super.onDestroy();
        // 锁忘记释放！
    }
}

这个服务同时踩了四个雷：主线程阻塞、50ms高频定时器、持锁不放、锁泄漏。只要一启动，CPU立刻飙升，Compose 页面的重组次数也会跟着飞涨——这正好是后面几章要深挖的内容。

如何诊断CPU占用是否来自前台服务？

发现问题只是第一步。你得有办法定位到具体是哪段代码在"吃"CPU。我平时会用这三板斧：

adb shell dumpsys cpuinfo —— 看进程级CPU占比，确认是不是你的前台服务进程在狂飙。
Android Profiler (CPU 采样) —— 抓5秒采样，直接看哪个方法调用栈最深、耗时最长。
线程 dump + 火焰图 —— 如果你用的是 Simpleperf 或 Perfetto，能精确到每一行代码的CPU开销。

一个小技巧：在测试环境，可以手动调低前台服务的线程优先级（Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND)），看同样任务量下CPU占用是否下降。如果下降明显，说明你的线程竞争太激烈了。

总结一下

前台服务导致高CPU占用的根本原因，不是机制问题，是代码设计问题。你把前台服务当"超人"使，它就会给你一个"发烫的手机"。把线程、定时器、轮询、锁这四个方面管好了，CPU占用自然就降下来了。

嗯，这一章先讲到这里。核心就是一句话：前台服务不背锅，背锅的是不节制的代码逻辑。