后台任务超时原理：Service与AsyncTask中的超时场景、WorkManager的任务过期机制

后台任务超时，说白了就是系统觉得你干活太慢了，直接给你掐了。我最早遇到这个问题是在做即时通讯App的时候，后台Service做网络重连，结果用户那边直接弹出"应用无响应"。嗯，那时候我才开始认真研究这些超时机制。

Service中的超时场景

Service是Android里最老牌的后台组件，但也是ANR重灾区。你想想看，系统给了你5秒的宽限时间，超过了就直接崩。

具体场景分两种：

• 前台Service：通过startForeground()启动，前台通知醒目，但超时依然会ANR。我个人习惯在这个方法里只做轻量操作，复杂任务丢给HandlerThread。
• 绑定Service：onBind()和onUnbind()的超时更严格，虽然不直接ANR，但会导致绑定失败，客户端收不到回调。我曾经遇到一个bug：绑定Service里做了数据库查询，耗时3秒多，结果客户端一直回调超时。

// 一个容易踩坑的例子
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
    // 千万别在UI线程执行耗时操作
    doHeavyWork(); // 超过5秒 → ANR
    return START_STICKY;
}

AsyncTask中的超时场景

AsyncTask在API 30已经被废弃，但存量代码依然很多。它的超时问题很隐晦——不是系统强制的，而是你自己设置的。

默认情况下，AsyncTask的doInBackground()没有超时限制，但如果你调用了get(long timeout, TimeUnit unit)，那就有了。

我当时在做一个图片上传功能，用了AsyncTask的get()等待结果，设置10秒超时。结果网络慢的时候，超时异常抛了，但上传线程还在继续，最后内存泄漏了。解决方案是用回调代替阻塞等待。

// 糟糕的写法：阻塞等待
try {
    String result = new UploadTask().execute(url).get(10, TimeUnit.SECONDS);
} catch (TimeoutException e) {
    // 任务还在跑，但你已经处理不了了
}

WorkManager的任务过期机制

WorkManager是官方推荐的后台任务库，它的超时机制叫"过期时间"（expedited job timeout）。从Android 12开始，系统对立即执行的任务（Expedited Work）有硬性超时：

• 立即任务（Expedited）：如果在10分钟内没有开始执行，系统会抛出WorkManager.OnExpiredWork回调，并触发降级策略
• 普通任务：没有固定超时，但可以通过setInitialDelay()或setBackoffCriteria()控制重试行为

我去年重构一个数据同步任务，用了WorkManager的Expedited模式，结果用户反馈同步失败增多。查日志发现是系统资源紧张时，任务排队超时被降级了。解决方案是把关键任务设置setExpedited(false)配合setBackoffCriteria做指数退避。

// 配置一个有过期机制的任务
val workRequest = OneTimeWorkRequestBuilder<MyWorker>()
    .setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST)
    .build()

三种超时机制的对比

组件	超时来源	超时后果	我的经历
Service	系统强制的5秒（ANR）	应用无响应，可能被杀死	IM重连踩坑
AsyncTask	开发者设置的get()参数	TimeoutException，但任务未取消	图片上传内存泄漏
WorkManager	Expedited任务的10分钟排队超时	降级或Worker的onStopped()	同步任务降级失败