Android端如何实现POST请求持续重试直至发送成功

现有连接超时配置的认知偏差 #

• urlConnection.setConnectTimeout(0) 仅代表TCP连接建立阶段不设置超时上限，生效前提是系统能正常完成域名解析、具备触达服务器的网络路径。遇到UnknownHostException这类DNS解析失败的场景，是系统直接判定主机不可达抛出的异常，根本不会走到等待连接建立的流程，和超时参数没有任何关系。
• 无限制的连接等待在真实环境中会直接造成后台线程永久阻塞，没有实际使用价值。

catch块内直接重启AsyncTask的方案存在多处硬伤 #

• 代码语法错误：new SendAlarm 缺少构造调用的括号，正确写法为new SendAlarm()，这段代码本身就无法编译运行。
• 无退避机制的高频重试：遇到持续网络异常时，会没有任何间隔地连续发起请求，短时间内快速消耗电量、占用系统资源，甚至触发系统对后台应用的限流机制。
• 生命周期与线程模型缺陷：
  • AsyncTask从Android 3.0开始就是单线程串行执行，所有任务共用同一个后台线程，如果之前的任务卡在阻塞状态，新发起的重试任务会一直排队得不到执行。
  • AsyncTask依附于创建它的组件生命周期，如果承载任务的页面被销毁，新创建的任务会持有无效的组件引用，直接造成内存泄漏。
• 场景适配性为0：这种完全基于内存的重试逻辑，覆盖不了设备开启飞行模式数小时、应用被系统强制杀进程的场景——只要应用进程不存在，所有挂起的重试逻辑会直接消失，根本不可能等网络恢复后自动补发请求。

可落地的必达POST请求实现方案 #

要满足“设备长期离线、进程重启后依然能在网络恢复时自动重试直到请求成功”的要求，不能靠裸HttpURLConnection加手动重试，需要按三层逻辑搭建可靠链路：

1. 请求持久化存储
   • 所有标记为必达的POST请求，在发起前先把URL、请求头、请求体、创建时间、重试次数等全量参数持久化到本地数据库中，不要把请求状态存在内存里。只有收到服务器返回的2xx成功响应后，才把这条存储的记录标记为已完成并删除。
2. 可靠的任务调度
   • 不要用AsyncTask做重试调度，改用Android原生的WorkManager实现任务管理：它会自动匹配任务执行约束（比如网络可用、设备非低电状态）触发后台任务，哪怕设备重启、应用进程被系统杀死，已经入队的任务也不会丢失。
   • 给任务配置默认的指数退避重试策略：比如第一次失败后等待10秒重试，第二次失败等待20秒，第三次等待40秒，避免高频无效请求浪费资源。
3. 网络请求执行与异常处理
   • 任务被调度触发后，从本地存储读出待发送的请求参数，发起HTTP请求时设置合理的超时阈值（建议连接超时15秒，读取超时30秒，适配弱网场景），不要设置无限制的超时。
   • 全量捕获所有网络场景下的异常：包括DNS解析失败、连接超时、读取超时、非2xx的服务器错误，只要没有收到明确的请求成功响应，就把任务交还给调度层安排下一次重试，不要自行捕获异常后直接终止流程。
4. 兜底优化
   • 可以给长期重试的请求设置最大重试次数上限，超过阈值的失败请求可以单独记录日志，避免永久运行的任务长期占用系统资源。
   • 注册系统网络状态变化的监听，当检测到网络从不可用恢复为可用时，主动触发一次待发送请求的扫描，缩短离线场景下的补发延迟。

内容的提问来源于stack exchange，提问作者gwicks