Android后台网络请求被限制？从Doze到应用待机分组全解析

上个月有个做独立开发的朋友来找我，说他的应用一锁屏，上传任务就断，用户已经骂了一周。他拿来复现的机器是一台刷了原生 Android 9 系统的旧设备，问题非常典型：App 退到后台后，网络请求没有崩溃日志，没有错误弹窗，进程直接在后台消失。重新回到前台，任务失败了，日志里只有一条SocketTimeoutException。

这台机器跑的是标准 AOSP 系统，没有厂商自己那套后台管理，所以问题源头相当干净——就是 Android 系统层面的后台网络请求限制，不是他代码里某个变量写错了。实际上这个问题从 Android 6.0 开始就在逐步收紧，到了 Android 9（API 28）又加入了应用待机分组机制，把后台限制从“一刀切”变成了“按使用频率动态分级”。

这篇文章就围绕这个场景展开：后台网络请求到底被谁限制了、限制的机制是什么、遇到之后怎么一步步排查、正规的解决方案有哪些，以及 Android 9 里最容易被人误判成“后台限制”的明文 HTTP 问题。适合正在做 App 后台同步、文件上传、消息推送、或者面试前想把这些机制彻底搞懂的同学。

1. 先搞清楚“谁在限制你的网络请求”：从 Doze 到应用待机分组

1.1 Doze 模式：不是你的 App 坏了，是系统把所有人关进了同一间“限电宿舍”

很多人第一次遇到后台网络请求失败，第一反应是自己代码有 bug，或者服务器挂了。实际上从 Android 6.0（API 23）开始，系统就引入了一个叫 Doze 的机制。它的触发条件很明确：设备处于静止状态、没有在充电、屏幕已经关闭一段时间。满足这三个条件后，系统会进入休眠模式，在这个模式下，后台网络访问、CPU 任务、闹钟、WakeLock 都会被统一挂起。

我习惯用一个比喻来解释 Doze：它就像一个宿舍管理员，晚上十一点准时强制断电。管理员不会针对某个同学，而是把所有宿舍全部断电，不管是学习还是打游戏，一律不许偷偷开灯。但是管理员每隔一段时间会打开走廊灯，让大家上个厕所、接杯水，这个时间窗口在系统里叫维护窗口（maintenance window）。在维护窗口内，被挂起的任务可以临时跑一小会儿，跑完继续断电。

所以你在 Doze 阶段看到的网络请求失败，本质不是失败，是被延迟了。TCP 连接长时间没有收到数据，触发了超时，客户端以为服务器出问题了，实际上数据包还在系统队列里排队。这个问题一直到 Android 7.0 加入 Light Doze 后依然存在，只是轻量版触发条件宽松一些——设备只要屏幕关闭、未充电，哪怕还在运动，也会进入轻度休眠，后台任务被允许执行的频率更低。

这里有一个很多人不知道的调试细节：如果你在开发时把手机插着 USB 线连着电脑，Doze 基本不会触发，因为“正在充电”是 Doze 的禁止条件。很多开发者折腾半天复现不出来，拔掉数据线、锁屏、静置半小时再试，问题立刻出现。

1.2 Android 9 的应用待机分组：被划到“罕用”档位后，网络请求只能排队

到了 Android 9（API 28），Google 又引入了 App Standby Buckets，中文叫应用待机分组。系统会根据用户近期的使用频率、通知交互次数、上次打开时间，把应用划分到四个档位：活跃（Active）、工作集（Working Set）、常用（Frequent）、罕用（Rare）。

四个档位对后台网络和任务调度的宽容度完全不一样。活跃应用基本不受限制，工作集应用可以比较频繁地跑后台任务；到了常用这一档，系统就开始压低后台 Job 的执行频率了；而罕用应用的网络访问、JobScheduler 任务会被压到很低频，可能很长时间才放行一次。

这个机制对开发者来说最难受的一点是：你没法用代码直接控制自己 App 被分到哪个档位。系统看的是用户与应用的交互行为，比如用户有没有主动打开 App、有没有点你的通知。如果一个用户一周都不打开一次你的 App，它就会被系统慢慢降级到罕用档位，后台同步频率大幅下降，这跟你代码写得多好没有关系。

如果你在做 IM、新闻资讯这类需要周期性后台拉取数据的应用，要正视这个机制：尽力把用户拉回前台，不管是优化通知点击率，还是引导用户主动打开，都比强行提升后台执行频率靠谱。到了 Android 12，这个方向更进一步，加入了 App Hibernation，几个月不用直接进入休眠状态，后台任务几乎全部冻结，开发者的操作空间只会越来越小。

1.3 厂商 ROM 才是真正的变量：同样的代码在不同手机上表现完全不同

AOSP 原生的 Doze 和待机分组只是“基础题”，真正让安卓开发者头疼的是各家厂商自己加的省电策略。华为的设置里叫“应用启动管理”，小米叫“神隐模式”，OPPO 叫“耗电保护”，vivo 叫“后台耗电管理”。这些策略是在 AOSP 之上叠加的私有逻辑，也就是说，哪怕你在原生 Android 9 上把所有后台机制都适配好了，到了 MIUI 上照样可能被清后台。

这些厂商策略一般分两层：一层是限制应用自启动，另一层是智能清理后台进程。加上各种“纯净后台”“极致省电”的开关，用户经常在不知情的情况下就把你的 App 划进了限制名单。结果就是：你的 App 在别的手机上跑得好好的，到了某个特定品牌的机器上，一锁屏任务就死，打开日志发现连进程都没了，这就是被厂商系统“冻住”了。

对这一类问题，正规的思路是引导用户到系统设置里把你 App 的后台权限放开，前面说的是让你理解限制机制的来源，不是让你去跟系统硬刚。真正要落地的，是下面这套排查和方案选型。

2. 一次真实的任务中断，完整走一遍后台请求排查链路

2.1 第一步永远先看日志：用报错类型判断“锅”在哪一层

接到“后台请求被限制”这类反馈，我的排查顺序永远是先把问题定性：这是请求发不出去？还是发出去了没响应？还是响应超时？还是进程被杀了根本没有日志？不同的现象对应完全不同的根因。

如果你在 Logcat 里看到的是SocketTimeoutException，说明请求其实已经发出，但长时间没有收到响应。这个大概率是 Doze 或厂商省电策略把网络挂起了，数据还在等待通路释放。如果看到的是UnknownHostException，大概率不是后台限制，而是网络切换到无 DNS 的环境，比如手机从 Wi-Fi 切到移动网络时 DNS 缓存失效。如果看到的是ConnectException: Connection refused，那问题基本在服务端，端口没监听或防火墙拦截了，跟后台没多大关系。

还有一种情况，连异常都没有。进程被杀掉后，Application 重新冷启动，原来的上传任务自然就没了。这种最隐蔽，因为它不会在 Logcat 里留下任何网络层的错误信息，只会在am_proc_died这类系统日志里看到进程死亡记录。判断标准是：锁屏前 task 还在，锁屏后 Logcat 里找不到任何你的业务日志，大概率是被系统收回了。

在一个刷了原生 Android 9 的设备上做复现实验时，我通常建议把日志关键字分三层打：第一层是网络库连接状态，第二层是业务层的 task 生命周期，第三层是进程存活标记。这样一旦出问题，看日志顺序就能判断任务到底走到了哪一步。

2.2 用 adb 把 Doze 和待机分组变成可复现实验

很多后台问题难排查，是因为触发条件太随机：要等设备静止、灭屏、不充电，时间不可控。其实 Android 系统早就留好了测试后门，用 adb 命令可以直接强制进入 Doze，几秒钟就能复现问题。

# 模拟设备断开充电，拔掉“电源线” adb shell dumpsys battery unplug # 强制进入 Doze 休眠 adb shell dumpsys deviceidle force-idle # 查看目标应用当前所属的待机分组 adb shell am get-standby-bucket com.example.app

执行完 force-idle 后，屏幕保持熄灭状态，任务基本就被挂起了。这时候你可疑用另一个终端观察网络请求日志，看它是在维护窗口被放行、还是直接超时失败。试验结束后记得恢复环境：

# 退出 Doze adb shell dumpsys deviceidle unforce # 恢复充电状态 adb shell dumpsys battery reset

这个流程我建议在每一个涉及后台任务的改版里都跑一遍，尤其是从 Android 8 升到 Android 9 的项目，因为待机分组逻辑是新加的，很多老代码都没适配过。

2.3 区分“进程被杀”和“任务被挂起”：处理路径完全不同

同样表现为后台任务失败，处理思路却可能完全相反。如果只是任务被挂起、进程还活着，你要做的是优化超时重试策略，加长超时时间，让任务在系统放行后能继续跑。如果是进程被杀，你要考虑的是把关键任务改到前台服务里，或者拆分任务交给 WorkManager，而不是单纯调网络库参数。

判断方法也有讲究。锁屏后等 15 分钟，然后重新亮屏、回到 App，如果任务直接恢复继续执行，多半是挂起而非被杀。如果在任务列表里已经找不到这个 App，或者亮屏后 App 是冷启动界面，那进程已经死了。

我之前在 Android 9 的盒子上做过测试：把视频上传任务放到普通 Service 里，锁屏 10 分钟，进程就被回收了；改成前台服务后，同样条件下进程存活，只是网络请求被 Doze 延迟。这个实验说明，区分这两种情况，决定了你是要“修网络层”还是“改架构层”。

3. 前台服务、WorkManager、系统推送：三条正规通道怎么选

3.1 前台服务：唯一能保证持续执行的方案，代价是常驻通知

Android 8.0（API 26）之后，后台启动普通 Service 的行为被严格限制。应用处于后台时，不能随意调用startService()，否则会抛IllegalStateException。要想在后台持续跑一个任务，正路只有一条：使用前台服务。

前台服务通过一个常驻通知栏告诉用户“这个应用还在干活”，系统会把它当成用户可见的组件，不会轻易回收。文件上传、音频播放、导航这类需要长时间持续运行的任务，都应该用前台服务承载。

代价也很明显：用户会看到一条常驻通知，如果业务本身在用户感知上不适合长期驻留，容易被用户手动杀掉。另外，前台服务不是免死金牌，部分厂商 ROM 还是会清理它，只是优先级比普通 Service 高很多。

Android 14（API 34）之后，前台服务还必须声明具体类型，比如dataSync、mediaPlayback、location等，并在运行时申请对应的权限。如果你的 App 还要兼容新系统，写前台服务时最好把foregroundServiceType一并配好。

3.2 WorkManager：把同步任务交给系统调度

如果你的业务场景是“数据晚一点同步没关系，但一定要同步”，WorkManager 是更合适的选择。它内部封装了 JobScheduler、AlarmManager 等底层机制，能根据设备电量、网络状态、Doze 周期自动安排执行时间。

WorkManager 最大的优点是系统会保证任务最终被执行，即使进程被杀死，下次系统有空闲窗口也会重新调度。它还自带重试和退避策略，失败后可以按指数退避重新执行，省去你自己写重试逻辑的麻烦。

代价是执行时机不可控。Doze 期间，系统可能把任务拖到维护窗口才执行，具体延迟多久完全由系统决定，你的代码只能干等。所以如果任务是用户正在等待的关键操作，比如用户点“立即上传”后希望马上看到结果，这种不适合用 WorkManager；但如果只是“把日志上报给服务器”“把缓存数据同步上去”，用 WorkManager 反而减少不必要的后台唤醒。

3.3 长连接的心跳与重连：减少后台频率比硬保活更可靠

有些场景绕不开长连接，比如 IM 收消息、股票行情、远程控制。长连接最大的问题是心跳，锁屏状态下心跳被 Doze 挂起，连接就可能被服务端判定超时断开。

我见过的错误做法是，为了让连接存活，把心跳间隔调到几十秒甚至更短，结果就是频繁唤醒设备，耗电剧增，反而更容易被系统限制。正确的思路是接受系统调度：锁屏且进入 Doze 后，连接断开就断开，等用户点亮屏幕、网络恢复后，再快速重连并补齐离线消息。

重连策略要配合网络状态监听，别盲目定时重试。用 ConnectivityManager 监听网络切换事件，在onAvailable回调里统一触发重连，比写死心跳次数靠谱得多。这部分的核心思想是：尽量降低后台时期的资源占用，让系统觉得你的 App “很懂事”，反而不容易被激进清理。

3.4 三条通道的横向对比表

我把三条正规通道的适用场景和限制整理成一张对比表，方便你给任务做技术选型时快速做决策：

如果业务确实需要“进程不在也能恢复任务”，厂商推送是另一条路，它相当于把消息送达交给系统级的推送服务，推送到达后再唤醒 App 处理业务逻辑。这个方案不在本文展开，但你在选型时应该把“系统推送触发”也纳入考虑范围。

4. 代码实现：一套“后台请求尽量不丢”的最小可运行方案

4.1 网络层基础配置：超时、重试、指数退避

说完选型，落到代码上。第一步先把网络层配置写好，很多后台请求失败不是被系统杀掉的，而是超时设置不合理，导致任务在短暂的“被延迟窗口”里直接放弃了。

以 OkHttp 为例，建议的连接超时、读取超时、写入超时设置如下：

OkHttpClient client = new OkHttpClient.Builder() .connectTimeout(15, TimeUnit.SECONDS) .readTimeout(30, TimeUnit.SECONDS) .writeTimeout(30, TimeUnit.SECONDS) .retryOnConnectionFailure(true) .build();

为什么读取超时要给到 30 秒？因为在 Doze 维护窗口内，系统可能只放行很短一段时间，如果服务端处理稍慢，短超时就会直接误判为失败。但超时也不是越长越好，过长会让大量失败任务堆积，占满线程池和内存。15 秒连接超时、30 秒读写超时是我在多数项目里实测下来比较稳的配置。

重试策略上，推荐指数退避：第一次失败后等 2 秒重启试，第二次 4 秒，第三次 8 秒，最高上限到 60 秒左右。这样既能在系统短暂放行时抓住机会，又不会在无网环境下疯狂重试耗电。退避逻辑建议封装在任务调度层，不要写在业务回调里，方便统一维护。

4.2 前台服务的正确写法：5 秒内必须 startForeground

如果你决定用前台服务承载一个上传任务，写法上有一个必须注意的细节：Android 8.0 之后，要用startForegroundService()启动，并且 Service 启动后的 5 秒内必须调用startForeground()，否则系统直接报RemoteServiceException崩溃。

一个最小可用的前台服务核心代码如下：

public class UploadService extends Service { private static final String CHANNEL_ID = "upload_channel"; @Override public void onCreate() { super.onCreate(); createNotificationChannel(); } @Override public int onStartCommand(Intent intent, int flags, int startId) { Notification notification = new Notification.Builder(this, CHANNEL_ID) .setContentTitle("任务同步中") .setContentText("正在上传待同步数据") .setSmallIcon(android.R.drawable.stat_sys_upload) .setOngoing(true) .build(); startForeground(1, notification); // 这里执行实际的上传逻辑 startUploadTask(); return START_STICKY; } private void createNotificationChannel() { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) { NotificationChannel channel = new NotificationChannel( CHANNEL_ID, "上传服务", NotificationManager.IMPORTANCE_LOW ); NotificationManager manager = getSystemService(NotificationManager.class); manager.createNotificationChannel(channel); } } }

启动端代码也要兼容 Android 8.0 以上的新 API：

ContextCompat.startForegroundService(context, new Intent(context, UploadService.class));

如果项目 targetSdk 已经切到 34，别忘了在 Manifest 里声明前台服务类型：

<service android:name=".UploadService" android:foregroundServiceType="dataSync" android:exported="false" />

这个dataSync类型还需要配套的运行时权限，高版本机型的适配坑不少，但如果你的 App 核心任务依赖后台上传，这个适配跑不掉。

4.3 用 WorkManager 承接“迟一点也要传”的任务

不想长期占用前台通知，但又不能丢任务，用 WorkManager 最合适。下面的代码实现了一个简单的同步 Worker：

public class SyncWorker extends Worker { public SyncWorker(@NonNull Context context, @NonNull WorkerParameters params) { super(context, params); } @NonNull @Override public Result doWork() { boolean success = uploadPendingData(); return success ? Result.success() : Result.retry(); } }

提交任务时，建议显式声明网络和电量约束，避免在无网或低电量环境下盲目执行：

Constraints constraints = new Constraints.Builder() .setRequiredNetworkType(NetworkType.CONNECTED) .setRequiresBatteryNotLow(true) .build(); OneTimeWorkRequest request = new OneTimeWorkRequest.Builder(SyncWorker.class) .setConstraints(constraints) .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 30, TimeUnit.SECONDS) .build(); WorkManager.getInstance(context).enqueue(request);

我把 WorkManager 理解为“系统帮你排队取号”：它不会立刻执行，但一定会执行。你在代码里要做的就是把任务拆细一点，每次只处理一批数据，避免单个 Worker 执行时间过长被系统中断。

4.4 电池优化豁免：可申请，但要克制

Android 系统提供了一个白名单机制，可以让 App 绕过部分电池优化限制，对应REQUEST_IGNORE_BATTERY_OPTIMIZATIONS。申请代码如下：

PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE); if (pm != null && !pm.isIgnoringBatteryOptimizations(getPackageName())) { Intent intent = new Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS); intent.setData(Uri.parse("package:" + getPackageName())); startActivity(intent); }

但是这里必须泼一盆冷水：这个权限在应用市场审核里被卡得很严，非白名单类应用基本不允许使用。即使在国内市场上架，弹窗让用户“关闭电池优化”也容易招致差评和投诉。我的建议是，除非你的 App 是实打实的即时通信、导航、音乐播放类，否则不要主动弹这个授权请求，最多在设置页里放一个引导入口，把选择权交给用户。

现在顺势把范围扩大一点，Android 9 上还有一个非常容易让人误解的现象：明明网络请求正常，锁屏后回来就失败，日志却指向了另一个完全不同的系统策略——默认禁止明文 HTTP 流量。

5. Android 9 里另一个容易被误判的“限制”：默认禁止明文 HTTP

5.1 现象：后台回来请求直接抛 Cleartext 异常

我接过好几个咨询，开发者都是这样描述的：App 退到后台后过一会儿再回来，网络请求全挂了；一开始以为是被系统限制后台了，后来仔细看日志才发现，报的是Cleartext HTTP traffic to xxx not permitted。

这个报错跟后台限制没有半点关系，它是 Android 9（API 28）的另一项策略：默认禁止应用使用明文 HTTP 流量，强制要求使用 HTTPS。当你的targetSdkVersion >= 28且运行在 Android 9 及以上设备时，任何http://协议的请求，都会被网络策略直接拦下。

为什么这个报错经常跟后台任务扯在一起？因为很多 App 只在后台同步时才走某个内网地址或者老接口，平时前台用的主域名已经切到 HTTPS 了，所以刷到的概率不高。直到锁屏后触发了后台同步任务，那个走了 HTTP 的请求才会冒出来。看起来像是“后台被限制”，实际是“明文流量被拦截”，被现象误导的人非常多。

5.2 根因与适配：networkSecurityConfig 比全局开关更可控

解掉这个问题的正路是给项目加网络安全管理配置。在 Manifest 的 application 节点里声明：

<application android:networkSecurityConfig="@xml/network_security_config" ... >

然后在res/xml/network_security_config.xml里做精细化放行：

<network-security-config> <base-config cleartextTrafficPermitted="false" /> <domain-config cleartextTrafficPermitted="true"> <domain includeSubdomains="true">192.168.1.100</domain> </domain-config> </network-security-config>

这里有个经验点要先说明：<domain>标签只支持域名，不支持 IP 字面量。如果你要用 HTTP 访问局域网 IP 或内网测试地址，直接把 IP 写进<domain>是无效的，这种情况下最省事的是临时把cleartextTrafficPermitted="true"配到 base-config，或者全局开android:usesCleartextTraffic="true"，上线前再收紧。

处理这个问题时我的建议很明确：能用 HTTPS 的接口就尽快切 HTTPS，这是治本；网络配置里的白名单只留给那些实在改造不了的老接口。别为了省事全局放开明文，不然等你想起来收紧的时候，很难排查出还有哪些地方在走 HTTP。

6. 把系统升级的“惊喜”堵在上线之前：后台请求专项测试与回归

6.1 用 adb 模拟 Doze、待机分组和断网的命令清单

后台请求问题最大的风险是“偶发性”，很多团队测不出来就是因为没用对工具。下面这套命令我已经整理成自己的测试脚本，每次涉及后台任务改动都会跑一遍：

# 模拟断充并手动进入 Doze adb shell dumpsys battery unplug adb shell dumpsys deviceidle force-idle # 查询目标应用所在的待机分组 adb shell am get-standby-bucket com.example.app # 强制把应用放到罕用分组 adb shell am set-standby-bucket com.example.app rare # 进入网络不可用状态，模拟弱网/断网 adb shell settings put global airplane_mode_on 1 adb shell am broadcast -a android.intent.action.AIRPLANE_MODE # 退出 Doze 并恢复环境 adb shell dumpsys deviceidle unforce adb shell dumpsys battery reset adb shell settings put global airplane_mode_on 0

测试的核心不是看任务是否失败，而是看任务在系统恢复后能不能自动补齐。把任务丢到 rare 分组后锁屏，等 10 分钟回前台，如果任务自动重试成功，说明你的“任务恢复”机制是合格的；如果任务直接丢了，就要回去检查是不是缺少持久化记录。

6.2 真机测试矩阵：至少覆盖原生 + 三家厂商 ROM

AOSP 的测试结果只能代表系统兼容性的及格线，真机矩阵还得覆盖主流厂商 ROM。我自己一般会保证至少有这几类测试设备：

真机测试的步骤重复性很高，每次都手动操作不现实，我会把“锁屏 → 等待 5 分钟 → 查看任务结果”固化成脚本，利用 adb 批量执行。这里特别提醒一点：测试时要真的拔掉 USB 线或者断开充电，我第一次跑厂商 ROM 测试时就是因为插着数据线，Doze 从来没触发过，白白浪费了半天。

另外测试时 targetSdk 的影响要区分清楚：后台限制主要看设备系统版本，明文流量限制同时看系统版本和 targetSdk。也就是说，哪怕你把 targetSdk 降到 27，在 Android 9 设备上照样会受 Doze 和待机分组约束，你并不能靠降低 targetSdk 绕过后台限制。

6.3 线上监控：给后台任务单独建一张成功率报表

后台任务有一个特点：用户不主动反馈就不会有人发现。所以我建议在上报数据里加一个场景字段，区分“前台发起”和“后台发起”，然后单独统计后台任务的成功率。

实现思路很简单：在任务发起时记录当前亮屏状态和是否充电，比如用 PowerManager 判断isInteractive()和isDeviceIdleMode()，把这两个值固化到上报字段里。这样你就能在监控后台里看到“后台同步成功率”这个指标，而不是混在前台请求数据里看不出问题。

这个指标的价值在于，它能帮你定位系统升级带来的隐性变化。比如某天你把 targetSdk 从 29 升到 33，前台请求一切正常，但后台任务成功率从 95% 掉到 70%，那基本可以断定是新的后台限制生效了，需要重新执行一遍上面说的 Doze 和厂商 ROM 测试流程。没有这个指标，这类问题可能要等用户投诉才会暴露。

我在实际项目中的体会是，后台网络请求被限制这件事，永远不要指望一次适配永久有效。Android 每个大版本都在收紧后台能力，厂商策略也在持续调整。与其花精力去对抗系统、研究各种灰色保活手段，不如把任务设计成“可延迟、可恢复、可重试”的形态，让系统在什么时候执行都由它说了算，但你的代码要保证任务最终能被执行完。发布前专门安排一个迭代去跑真机测试矩阵，把 Doze、待机分组、厂商后台管理这些场景全部过一遍，能挡掉绝大部分线上事故。