七牛云Android SDK架构深度剖析：UploadManager如何统合DNS预解析、事务调度与配置监控-育师

七牛云Android SDK架构深度剖析：UploadManager如何统合DNS预解析、事务调度与配置监控

【免费下载链接】android-sdkQiniu Resource (Cloud) Storage SDK for Android项目地址: https://gitcode.com/gh_mirrors/and/android-sdk

七牛云 Android SDK（qiniu-android-sdk）是七牛云对象存储的官方 Android 客户端。这篇文章带你深入源码，看清 UploadManager 这一核心入口如何把三大后台机制统合在一起：DNS 预解析（提前把域名解析好）、事务调度（每秒一次的统一任务引擎）与服务端配置监控（远程下发开关）。读完你会明白：为什么这个 SDK 上传又快又稳。

一张图看懂启动顺序：构造函数里的"暗线"

很多初学者的疑问是：new UploadManager(config)不过是一行构造，为什么它能"未卜先知"？

答案藏在构造函数里（见 UploadManager.java），它就四行，却启动了整条后台流水线：

TransactionManager.getInstance().start(); // ① 启动事务调度引擎 DnsPrefetchTransaction.addDnsLocalLoadTransaction(); // ② 注册 DNS 加载事务 DnsPrefetchTransaction.setDnsCheckWhetherCachedValidTransactionAction(); // ③ 注册 DNS 缓存校验事务 ServerConfigMonitor.startMonitor(); // ④ 启动服务端配置监控

也就是说：构造一次 UploadManager = 同时启动三套后台子系统。上传本身只是"前台"，这三套机制才是让上传成功率与速度更优的"后台基建"。官方推荐使用同一个 UploadManager 实例反复调用 put()，原因也在这里——后台只启动一次，后续上传全部受益。

事务调度引擎：TransactionManager 如何做到"一表调度"

每秒一次的统一心跳

事务管理器的实现非常精炼（见 TransactionManager.java），核心只有三件东西：

事务链表：ConcurrentLinkedQueue无锁并发队列，多线程增删事务都安全；
定时器：一个 1 秒周期的Timer，每秒遍历链表，把"到点的事务"全部执行一遍；
两种事务类型：普通事务（只执行一次，执行完自动从链表移除）和定时事务（按 interval 周期执行）。

这就是"一表调度"的设计：SDK 里所有需要"稍后执行"或"周期性执行"的事情，统统注册进这一张表，由同一个心跳驱动。好处是：

集中管控：想停就停（stop()），想清就清（destroyResource()），生命周期清晰；
天然去重：注册前用existTransactionsForName()按名称查重，同名事务绝不重复添加；
异常隔离：每个事务执行体单独捕获异常，任何一个任务出错都不会拖垮整个调度器。

值得一提的是，CHANGELOG.md 中 8.10.0 版本专门"解耦了 TransactionManager 定时器生命周期"，说明这个调度引擎在架构中的地位——它是整个 SDK 的"时间中枢"。

DNS 预解析：把"解析耗时"从上传关键路径上摘掉

为什么移动端特别需要 DNS 预解析？

手机网络环境复杂：切网、弱网、DNS 被劫持都会导致解析失败或变慢。如果每次上传都现解析域名，首请求会被白白拖慢。七牛 SDK 的做法是：提前解析、多级兜底、缓存复用。

三种注册方式，各管一段

所有 DNS 事务的注册都集中在 DnsPrefetchTransaction.java：

事务名称	类型	职责
`loadDns`	普通（一次性）	启动时从磁盘恢复 DNS 缓存，并预解析 SDK 内部固定域名
`dnsCheckWhetherCachedValidTransaction`	定时（120s）	首次延迟 10s 后，每 2 分钟校验一次缓存是否过期，过期则重新拉取
以 token 命名的事务	普通（一次性）	每次上传前，把该 Bucket 所在 Zone 的全部上传域名加入预解析清单

注意第三种事务以token 作为事务名：同一个 token 的上传域名只会被登记一次，天然防重。

多源兜底解析链：一个域名四种解析方式

真正干活的单例是 DnsPrefetcher.java，它对每个待解析的 host 依次尝试一条"降级链"：

自定义 DNS → 系统 DNS → HTTP DNS → UDP DNS

只有当前方式全部解析失败，才会落到下一方式；每个 host 默认最多重试 2 次（dnsRepreHostNum）。解析结果写入内存字典addressDictionary，并随当前本机 IP 一起序列化到磁盘缓存——下次冷启动直接恢复，跳过全部网络解析。缓存还带双重时效：单条记录默认 TTL 120 秒，整体最长 600 秒内仍可兜底使用。

这些阈值都可以在 GlobalConfiguration.java 中调整，如dnsResolveTimeout（预解析超时，默认 3 秒）、isDnsOpen（总开关，默认开启）。

配置监控：ServerConfigMonitor 是远程"开关面板"

随机间隔轮询，防"羊群效应"

ServerConfigMonitor.java 的startMonitor()会向事务表注册一个名为ServerConfig的定时事务，间隔是120 + 随机(240) 秒——即 2~6 分钟之间随机。这个随机化看似不起眼，却能避免全网用户在同一时刻集中请求配置接口，是典型的防羊群效应设计。

拉什么配置？改了之后怎么生效？

每一轮monitor()做两件事（见 ServerConfigMonitor.java）：

拉取ServerConfig（平台级配置）：缓存失效时才请求服务端，然后逐项应用到GlobalConfiguration——
- DNS 预解析总开关、UDP DNS 与 DoH 的服务器地址覆盖；
- 连接检测（ConnectCheck）开关与超时；
- 区域信息缓存、DNS 缓存的"带版本号清除"（clearId更大才清，防止脏数据被旧指令误清）；
拉取ServerUserConfig（用户级配置）：如网络检测开关、HTTP/3 协议开关。

请求逻辑在 ServerConfigSynchronizer.java 中还藏着一个细节：只有拿到上传 Token 之后才发起配置请求——没有上传动作就不产生任何多余流量。

上传路径：三大机制如何在一次 put() 中联动

现在把镜头切回上传本身。调用uploadManager.put(file, key, token, handler, options)后，完整链路是：

前置校验：空文件、空 token 等直接回调错误（checkAndNotifyError）；
登记后台任务：DnsPrefetchTransaction.addDnsCheckAndPrefetchTransaction(config, config.zone, t)把 Zone 域名送入预解析清单，ServerConfigMonitor.setToken(token)让配置监控"通电"（见 UploadManager.java）；
分流上传：文件小于putThreshold走表单上传（FormUpload），否则走分片上传（PartsUpload或ConcurrentResumeUpload），统一丢进后台线程池；
完成回传：回调被切回主线程执行，同时reportQuality()把本次上传的耗时、请求数、字节数、错误类型等质量数据打包上报（UploadManager.java）。

整个流程可以概括为一句话：上传动作负责"搬数据"，事务引擎负责"备道路"，配置监控负责"改路规"。

关键配置速查表

配置项（GlobalConfiguration）	默认值	作用
`isDnsOpen`	true	DNS 预解析总开关
`dnsRepreHostNum`	2	单个域名解析失败的最大重试次数
`dnsResolveTimeout`	3 秒	预解析超时
`dnsCacheTime`	120 秒	缓存记录默认 TTL（服务器未返回 TTL 时）
`dnsCacheMaxTTL`	600 秒	缓存过期后的最长兜底有效期
`udpDnsEnable`	true	是否允许 UDP 方式解析
`enableHttp3`	false	HTTP/3 开关（通常由服务端配置下发）