Service超时机制原理

Service的超时机制，说白了就是系统给Service执行设定的一个“死线”。你想想看，Android系统要管理那么多进程，如果某个Service在前台磨磨蹭蹭一直不返回，整个系统的响应就会被拖垮。所以Google设定了一套严格的超时监控规则——谁超时，谁就触发ANR。

1. Service超时阈值

我在项目中遇到过不止一次——同事把耗时操作直接塞进onStartCommand()里，然后跟我抱怨“怎么老ANR”。我问他：“你查过超时阈值吗？”他一愣。其实阈值就在系统源码里写死了。

具体阈值如下：

组件类型	前台超时	后台超时	备注
Service	20秒	10秒	Android 12+后台收紧到10s
BroadcastReceiver	10秒	—	静态广播超时更短
ContentProvider	—	—	实际通过Binder超时保护
InputDispatch	5秒	—	输入事件ANR

这些阈值的源码位置在ActivityManagerService.java里。具体来说：

// 前台Service超时，单位ms
static final int SERVICE_TIMEOUT = 20 * 1000;
// 后台Service超时（Android 12+）
static final int SERVICE_BACKGROUND_TIMEOUT = 10 * 1000;

我曾经在一款OEM定制ROM上排查过一个问题——厂商把后台超时改成了8秒。所以不要死磕官方值，拿到真机后可以通过dumpsys activity service查看实际超时配置。

2. 系统如何监控Service执行

系统监控Service的方式，说白了就是“埋了一个倒计时的炸弹”。具体流程是这样的：

1. 当startService()被调用，AMS会创建一个ServiceRecord对象。
2. AMS启动一个延时Handler消息，消息内容就是“超时检查”。这个延时时间就是我们刚说的阈值。
3. 当Service执行完onStartCommand()并返回后，AMS会收到一个serviceDoneExecuting()回调，然后把之前的延时消息移除。
4. 如果超时消息没有及时被移除，就会触发ANR。

换句话说，系统其实是在“等一个确认信号”。信号没来，就判定为超时。

源码里的关键逻辑在ActiveServices.java：

// 启动超时监控
void scheduleServiceTimeoutLocked(ServiceRecord r) {
    // 移除之前的超时消息
    mAm.mHandler.removeMessages(SERVICE_TIMEOUT_MSG, r);
    // 发送延时消息
    Message msg = mAm.mHandler.obtainMessage(SERVICE_TIMEOUT_MSG, r);
    mAm.mHandler.sendMessageDelayed(msg, timeout);
}

// 服务执行完成，移除超时消息
void serviceDoneExecutingLocked(ServiceRecord r) {
    mAm.mHandler.removeMessages(SERVICE_TIMEOUT_MSG, r);
}

这里有个细节：onStartCommand()的返回值也会影响超时行为。如果返回START_STICKY，系统会重建Service，但超时监控还是从重建后重新开始算。说白了，返回值的坑并不大，真正要命的是卡主线程。

3. 超时后如何处理

一旦超时消息没有被移除，AMS就会走ANR处理流程。具体步骤：

• AMS在appNotResponding()方法里生成ANR日志，包括CPU使用率、各线程堆栈、锁信息。
• 显示ANR对话框（系统版本不同可能表现不同）。
• 对于前台Service，系统可能直接杀掉进程，然后触发onLowMemory()或直接走Process.killProcess()。
• 后台Service超时，系统一般会在ANR后重新尝试启动，但用户看到的是一串“xxx无响应”的弹窗。

我曾经遇到一个典型案例：某音乐App的Service在onStartCommand()里做了大量JSON解析，解析20秒刚好卡在阈值边缘。用户锁屏后前台Service变后台，超时阈值立刻缩短到10秒，结果频繁ANR。最后我们把JSON解析丢到子线程，问题解决。

所以核心原则就是：绝不阻塞主线程。Service的超时监控本质上是对主线程的监控。只要主线程不卡住，Service就不会超时。

---

这张图已经把Service超时的核心逻辑都串起来了。简单总结就是：系统给Service安了一个定时炸弹，你必须在规定时间内拆掉引信（回调），否则就炸（ANR）。