Android 网络层超时、重试与错误映射

摘要：可靠网络层需要把传输细节转换为应用可理解的结果。超时、重试、取消和错误映射应配合业务语义设计，避免重复提交或把所有失败显示成同一条提示。

一、划分网络职责

客户端负责连接与协议解析，数据源负责调用接口，仓库负责组合本地和远端数据，界面模型负责映射展示状态。错误应在层间逐步收敛，而不是让界面解析底层异常文本。

成功、网络暂不可用、需要重新认证和数据冲突是不同结果。不要把所有异常都转换为空列表，因为空结果和加载失败有不同含义。

二、区分超时阶段

连接、上传、读取和整次调用有不同等待含义。超时应依据操作类型和体验需求配置。上传文件与读取轻量配置不适合共用完全相同的等待时间。

客户端超时不代表服务器没有处理请求。对于下单等写操作，服务端可能已完成工作，因此不能把超时当作安全重试的依据。

三、谨慎执行重试

自动重试只应处理适合重试的短暂错误，并限制次数，使用逐步延长的等待和随机抖动。多个客户端同时立即重试可能在服务恢复时制造新流量高峰。

对可能产生副作用的写请求，要使用幂等标识或先查询处理状态。重复提交不能只依靠按钮禁用解决，因为网络层和应用重启仍可能重发。

四、传播取消信号

页面关闭、搜索条件变化或请求被新请求替代时，应取消无用工作。取消异常不是普通网络错误，不应显示失败提示。底层请求支持取消时，应把取消传递到网络客户端。

即使执行了取消，旧请求仍可能在某些服务层继续完成。使用请求序号或状态校验，避免旧结果覆盖新查询。

五、设计错误模型

把底层异常映射成少量稳定类别，例如无网络、服务暂不可用、鉴权失效、参数错误和未知失败。用户提示应简短，日志可记录状态码和请求阶段，但不能记录令牌和敏感载荷。

序列化失败也需要被发现。非关键字段可以设置兼容策略，关键字段解析失败则应明确报错并留下诊断信息。

六、缓存与观测

相同并发读取可以考虑合并请求。缓存需定义有效期、刷新条件和失败时能否返回旧值；缓存键应包含筛选条件和用户身份范围。账户切换后要隔离或清理用户数据。

记录耗时分布、超时比例、重试次数和失败分类，通常比只留异常堆栈更有助于定位问题。日志应去除个人信息。

七、检查清单

1. 验证断网、慢网、连接中断和读取超时。
2. 验证取消后旧结果不能覆盖新状态。
3. 验证重试有限且使用退避。
4. 验证写操作超时后的重复提交行为。
5. 确认错误信息不泄漏服务端内部内容。

八、总结

网络层可靠性来自明确的超时、受控重试、端到端取消和稳定错误模型。对于可能产生副作用的请求，还需将幂等和状态查询纳入业务设计。