基于OkHttp的Android文件下载方案：进度、断点与工程化实践

做 Android 开发这些年我有个很深的感受文件下载是那种看起来简单落地全是坑的需求。JSON 接口调得再熟到了下载 APK、视频、离线包这类场景OkHttp 很多默认行为和你想的不一样——进度怎么回调、断点续传怎么和服务端对齐、大文件为什么内存爆掉、为什么下载一半抛 EOFException。这篇文章把我基于 OkHttp 做完整文件下载方案的实现思路、关键代码和踩坑记录整理出来从最小可用实现讲起到进度、断点、队列、生命周期这些工程细节收尾。无论你是在给 App 加下载能力还是在替换现有下载引擎应该都能找到能直接抄的代码和值得注意的边界条件。1. 下载功能最容易被低估的三个设计决策1.1 为什么不用 DownloadManager而要基于 OkHttp 自己封装很多人一听到Android 文件下载第一反应就是系统自带的 DownloadManager。它确实能用下载通知、网络策略、系统级任务都帮你搞定了但真正做过业务下载的人会很快撞上它的天花板。首先DownloadManager 对请求头的控制非常弱你想加个登录态的 Cookie、动态签名的 Header得走addRequestHeader而且它内部没有公开的进度监听通道你要实时更新 UI 就得轮询数据库里的DownloadManager.COLUMN_BYTES_DOWNLOADED_SO_FAR粒度粗不说在部分国产 ROM 上还经常出现广播丢失、任务状态错乱的问题。另一个重要原因是业务不可控。DownloadManager 的任务状态分散在系统进程里App 被杀死后你拿不到精准的回调做不了业务上的自定义重试、错误分类、文件校验。说句不好听的它在网络请求层面的能力也有限遇到需要自动重定向、自定义 DNS、证书校验的场景就更捉襟见肘。所以我最终选型是网络层用 OkHttp业务层自己封装。OkHttp 本身就解决了 HTTP/1.1、HTTP/2、连接复用、自动重定向、连接池这些问题而且它的ResponseBody是流式的天然适合把内容边读边写进文件。我们真正要做的是在它上面补齐下载任务管理这一层包括进度、断点、队列、生命周期。这比从零写一套 HTTP 客户端靠谱得多也比被 DownloadManager 绑住手脚自由得多。1.2 同步还是异步OkHttp 两种调用方式的取舍OkHttp 提供了execute()同步和enqueue()异步两种调用方式很多初学者喜欢用enqueue觉得异步回调肯定没问题。但实际做下载时我更倾向于底层统一用同步execute把线程模型交给上层控制。原因很简单下载一个文件的逻辑往往是发起请求 - 读流 - 写文件 - 校验的一条长链路如果中间业务要加断点、重试、取消用同步代码写起来是线性的一个try/catch就能把异常收敛住。而enqueue的Callback虽然跑在 OkHttp 的线程池里但有几个容易被忽略的规则onResponse回调前后ResponseBody的有效期是和这次调用绑定的你不能把body存下来等会儿再读另外回调线程不是主线程你要更新 UI 还得自己切线程。用协程之后这个优势更明显suspend fun downloadWithCoroutine(client: OkHttpClient, url: String, targetFile: File) { withContext(Dispatchers.IO) { val request Request.Builder().url(url).build() client.newCall(request).execute().use { response - // 处理响应写文件 } } }代码完全线性取消协程时只要在finally里把Call取消掉行为非常可预测。如果你坚持用enqueue也完全可行但要记得在回调里手动response.close()并且做好线程切换。我这里不讲谁对谁错而是给你一个长期维护成本更低的方案。1.3 自研封装与第三方下载库怎么选市面上有 FileDownloader、RxDownload、Aria 这些成熟的下载库有的底层甚至就是 OkHttp。为什么还值得自己写一层我的判断标准是下载功能在你的业务里是核心链路还是附属功能。如果只是列表页下载几个文件、展示一下进度直接用开源库能省很多事人家已经把断点、队列、通知栏都做完了。但如果下载承载了你的核心业务比如离线包更新、视频课缓存、带 DRM 保护的资源拉取那强烈建议自研。为什么因为下载库对你而言是个黑盒一旦遇到为什么这个 URL 下载失败为什么断点续传不生效这类线上问题你连排查的入口都没有。自研表层的任务管理并不难OnOkHttp 这种稳定扎实的网络底座已经帮我们解决掉最难的协议层了剩下的无非是状态机、文件读写、错误分类这些自己掌控反而更踏实。我见过不止一个项目前期图方便接了下载库后期需求一变要动态拼接下载参数、要限制某个 App 内的最大并发数发现库根本不开放这些能力最后陷入要么改库源码、要么推倒重来的尴尬。所以这个决策值得在项目初期就认真想清楚。2. 从零到能下文件OkHttp 最小可用实现2.1 环境准备依赖、权限与网络安全配置先说依赖。OkHttp 4.x 是 Kotlin 写的API 和 3.x 基本兼容但方法签名更 Kotlin 友好。建议在build.gradle.kts里直接上 4.12.0它同时把 Okio 3.x 也带进来了。implementation(com.squareup.okhttp3:okhttp:4.12.0)权限方面只需要一个网络权限uses-permission android:nameandroid.permission.INTERNET /很多人会在这步栽跟头Android 9 开始默认禁止明文 HTTP 流量。如果你测试时的下载地址是http://开头会直接报java.net.UnknownServiceException: CLEARTEXT communication not permitted。调试阶段可以临时在AndroidManifest.xml里给application加android:usesCleartextTraffictrue但生产环境务必全量 HTTPS。如果公司内部有自定义证书或者需要做证书校验还要在network_security_config.xml里配置对应的 trust anchors这部分和 OkHttp 的CertificatePinner可以配合使用做下载源校验的时候会用到。2.2 同步下载的核心代码骨架最小实现的思路很直白发一个 GET 请求拿ResponseBody把它流式写进目标文件。先看最简单的同步版本fun download(client: OkHttpClient, url: String, targetFile: File): Boolean { val request Request.Builder() .url(url) .get() .build() client.newCall(request).execute().use { response - if (!response.isSuccessful) { throw IOException(下载失败HTTP code: ${response.code}) } val body response.body ?: throw IOException(response body 为空) val source body.source() targetFile.outputStream().use { output - source.readAll(output) } } return true }这段代码基本能跑但有几个点必须先说清楚。第一OkHttpClient建议复用单例。很多人图省事每次下载OkHttpClient()一下这等于每次都新建连接池和线程池网络层完全没有复用性能差一个量级。OkHttpClient 是线程安全的整个 App 一个实例就够了除非你要针对下载场景单独配置超时。第二body.source()返回的是 Okio 的BufferedSource不是 Java 的InputStream。这里用readAll(output)是 Okio 的BufferedSource扩展了一个readAll(OutputStream)方法吗准确说上面代码里source.readAll(output)不是标准 Okio APIOkio 里对应的是source.readAll(sink)传的是 Okio 的 Sink。为了不误导写文件更稳的方式还是下面这种手动搬运。2.3 用流式写入而不是把响应读成 byteArray这是整篇第一个值得记到笔记里的点。很多人写下载会图省事val bytes response.body!!.bytes() // 千万别这么干 file.writeBytes(bytes)ResponseBody.bytes()会把整个响应体一次性读进内存。下载一个 5MB 的文件还凑合下载 500MB 的 APK 或离线包内存直接爆掉OOM 闪退没商量。正确姿势是用缓冲边读边写固定一个 8KB 或 64KB 的缓冲区读一点写一点。可以手动实现也可以用 Okio 的sink配合client.newCall(request).execute().use { response - if (!response.isSuccessful) throw IOException(HTTP ${response.code}) val body response.body ?: returnuse val source: BufferedSource body.source() targetFile.outputStream().use { output - val buffer Buffer() while (true) { val read source.read(buffer, 8192L) if (read -1L) break output.write(buffer.readByteArray(read)) } output.flush() } }原理上讲Buffer是 Okio 内部的内存缓冲source.read(buffer, 8192L)最多从网络读取 8192 字节到 buffer每次循环取走这些字节写入文件。流的读和写就在内存里过一下转交整个过程的内存占用被限制在一个很小的常数范围内这才是真正的流式下载。2.4 最小实现的边界它能做什么不能做什么上面的代码已经具备把 URL 对应的文件完整保存到本地的能力但是请冷静评估一下它离生产环境还差多远。第一没有进度回调用户的界面不会显示任何下载状态第二没有断点续传网络一旦抖一下几百兆的文件要从头再来第三没有任务队列多个文件同时下载时并发怎么控制完全没有概念第四没有命名策略Content-Disposition 里的文件名、URL 里的路径、非法字符这些问题通通没处理。说白了这段代码只是地基它能证明基于 OkHttp 下载文件是可以成立的但真正稳定落地要把后面三章的内容都补上。3. 进度与断点下载真正难搞的部分3.1 用包装 ResponseBody 实现精准进度回调进度需求一来很多人想的方案是下载完成后我知道了总大小和用时算个平均值。这完全不对用户要的是实时进度而且要在下载过程中实时展示百分比。OkHttp 本身没有直接的进度回调但我们可以通过包装ResponseBody来实现。核心思路是拦截source()方法返回的BufferedSource在它的read调用里累计已经读到的字节数再回调出去。听起来复杂其实代码很短class ProgressResponseBody( private val responseBody: ResponseBody, private val onProgress: (bytesRead: Long, totalBytes: Long) - Unit ) : ResponseBody() { private var source: BufferedSource? null private val totalBytes responseBody.contentLength() override fun contentType(): MediaType? responseBody.contentType() override fun contentLength(): Long totalBytes override fun source(): BufferedSource { if (source ! null) return source!! return object : ForwardingSource(responseBody.source()) { private var totalBytesRead 0L override fun read(sink: Buffer, byteCount: Long): Long { val bytesRead super.read(sink, byteCount) if (bytesRead ! -1L) { totalBytesRead bytesRead onProgress(totalBytesRead, totalBytes) } return bytesRead } }.buffer().also { source it } } }注意ForwardingSource是 Okio 里的包装类它把原本的 Source 包了一层super.read(sink, byteCount)会调用真实的网络读取读完就把字节数累计并上报。用的时候把它挂到 Response 上val body response.body val progressBody ProgressResponseBody(body) { read, total - runOnUiThread { progressBar.progress if (total 0) (read * 100 / total).toInt() else 0 } }进度回调会非常频繁每读一个缓冲区就触发一次在 UI 上有可能一秒钟几十次回调。建议加一个 100ms 的节流或者只在进度变化超过 1% 时才通知 UI不然runOnUiThread也会成为性能瓶颈。3.2 总长度未知时进度怎么展示有个很尴尬的情况responseBody.contentLength()返回 -1。这通常发生在服务端使用Transfer-Encoding: chunked分块传输时响应头里没有Content-Length。此时你无法提前知道总大小百分比就无从谈起。我的处理经验分三种。第一种如果能改服务端就尽量让下载接口返回真实的Content-Length这是最干净的做法。第二种客户端可以在正式开始下载之前发一个HEAD请求从响应头里拿Content-Length但有些服务端和 CDN 对 HEAD 支持不好会返回 405。第三种实在拿不到总长进度条就只显示已下载 xxx MB前面定死显示成动态值不做百分比。把大小未知当成产品文案问题来解决而不是技术难题。另外做 Range 断点请求时206 响应里一般会带Content-Range: bytes start-end/totaltotal字段可以解析出来作为总长度。这在断点续传场景下很实用后面的代码会体现。3.3 Range 断点续传客户端与服务端都要处理的事断点续传的原理一句话就能讲清楚HTTP 协议里的Range头客户端告诉服务端我从第 N 个字节开始给我传。关键是你得清楚整个交互链路有哪些分支。客户端要做的第一步是判断已下载大小可以从本地文件长度拿val existingSize if (targetFile.exists()) targetFile.length() else 0L然后带 Range 头发请求val requestBuilder Request.Builder().url(url) if (existingSize 0) { requestBuilder.header(Range, bytes$existingSize-) }服务端可能返回三种状态必须分开处理206 Partial Content正常续传响应体是从existingSize开始的剩余数据追加写入文件即可。200 OK服务端不支持 Range或者忽略了 Range 头返回的是完整文件。此时必须从零开始覆盖写入否则文件头尾错乱。416 Range Not Satisfiable你请求的偏移量已经超出文件大小说明本地文件和服务器资源不一致要重置文件后重新下载。我这边的推荐写法是不管 206 还是 200都走RandomAccessFile写入通过 offset 控制写盘位置避免追加模式和覆盖模式两套逻辑并行fun downloadWithResume( client: OkHttpClient, url: String, targetFile: File, onProgress: (Long, Long) - Unit ) { val existingSize if (targetFile.exists()) targetFile.length() else 0L val requestBuilder Request.Builder().url(url) if (existingSize 0) { requestBuilder.header(Range, bytes$existingSize-) } client.newCall(requestBuilder.build()).execute().use { response - when (response.code) { 200 - { // 服务端不支持断点从头覆盖 val body ProgressResponseBody(response.body!!, onProgress) RandomAccessFile(targetFile, rw).use { raf - raf.setLength(0) raf.seek(0) body.source().readAll(raf.toSink()) // 这里只是示意实际用缓冲循环写 } } 206 - { val total parseTotalFromContentRange(response.header(Content-Range)) // 比如 bytes100-999/2000total2000 val body ProgressResponseBody(response.body!!, onProgress) RandomAccessFile(targetFile, rw).use { raf - raf.seek(existingSize) val buffer Buffer() val source body.source() while (true) { val read source.read(buffer, 8192L) if (read -1L) break raf.write(buffer.readByteArray(read)) } } } 416 - { targetFile.delete() downloadWithResume(client, url, targetFile, onProgress) // 递归重下注意防止死循环 } else - throw IOException(下载失败HTTP code: ${response.code}) } } }上面的parseTotalFromContentRange把Content-Range: bytes start-end/total里的 total 解析出来即可单行正则的事。这层逻辑是断点续传里最精细的部分你必须把 200、206、416 三种语义完全理解才能写出不会有文件损坏的下载器。3.4 断点信息的保存位置与恢复时机很多人问断点信息放哪实际上文件本身的长度就是最可靠的断点标记。下次启动下载任务时检查目标文件是否存在、长度是否为 0不是 0 就从这个偏移量发 Range 请求。这个方案不需要额外存储也不用担心记录和实际文件不同步的问题前提是你保证写入过程中不会把半截文件误当成完整文件。但更严谨的做法是给下载任务维护一条持久化记录至少包含这些字段taskId、url、filePath、totalLength、downloadedLength、status。存到SharedPreferences或数据库都行关键是恢复任务时要做一次校准以file.length()为准来发 Range 请求不要轻信数据库里记的downloadedLength因为上次写盘可能异常中断文件的真实长度才是唯一的真相。还有一个细节下载完成之后必须把记录标记为完成或者直接删除不然下次触发重试时会基于一个完整文件再次发 Range 请求服务端返回 416 虽然能兜底但白白浪费一次网络请求和排查时的心智负担。4. 工程化落地队列、命名、生命周期与断点持久化4.1 并发控制OkHttp Dispatcher 与自定义下载队列下载任务一多并发控制就躲不掉了。OkHttp 的Dispatcher内部维护了异步请求队列默认限制是maxRequests 64maxRequestsPerHost 5。也就是说同一个域名最多 5 个并发请求超过的会在 OkHttp 内部排队。对大文件下载来说5 个并发同时跑带宽和服务器压力都不小我一般会调低val downloadClient OkHttpClient.Builder() .connectTimeout(15, TimeUnit.SECONDS) .readTimeout(30, TimeUnit.SECONDS) .build() .apply { dispatcher.maxRequestsPerHost 2 dispatcher.maxRequests 4 }maxRequestsPerHost限制同主机并发maxRequests限制全局并发。如果你希望不同域名的下载总量可控两个值可以精细调。如果业务上还需要手动暂停调整优先级批量取消那就要在 OkHttp 之外加一层任务队列。我的做法是定义一个DownloadTask数据结构包含 url、目标文件、状态、对应的Call引用。队列用PriorityBlockingQueue维护取出任务后开协程执行执行完毕再取下一条。暂停功能比想象中麻烦因为你不能只停队列还得让正在下载的那个Call真正取消OkHttp 提供了call.cancel()会在当前read处抛IOException捕获后把已下载长度写进持久化记录任务回收队列。这一套组合拳下来暂停恢复才算是闭环。4.2 文件名与路径策略Content-Disposition、URL decode 与哈希兜底文件名是下载模块最容易出幺蛾子的地方。首先要明确优先级服务端返回的Content-Disposition头里的 filename 是权威的它代表服务端意图其次是 URL 最后一段 Path 解码后的名字如果都没有就用 URL 的 MD5 加上一个后缀来兜底避免下载到本地之后文件没法区分。解析Content-Disposition时要注意编码问题。老的写法是filenamefile.apk只支持 ASCII现代规范推荐filename*UTF-8%E6%B5%8B%E8%AF%95.apk这种写法要单独解析。简单方案是fun parseFileName(contentDisposition: String?): String? { if (contentDisposition.isNullOrBlank()) return null val starPattern Regex(filename\\*UTF-8([^;]), RegexOption.IGNORE_CASE) starPattern.find(contentDisposition)?.let { return URLDecoder.decode(it.groupValues[1], UTF-8) } val plainPattern Regex(filename\?([^\;])\?, RegexOption.IGNORE_CASE) plainPattern.find(contentDisposition)?.let { return it.groupValues[1] } return null }拿到文件名后必须做一个清洗过滤掉../、/、\和 Windows 保留字符。这一步不是矫情是正经的安全问题——如果服务端被攻击者控制filename 里塞个../../..下载文件就能穿越到你指定的目录这是非常经典的路径穿越漏洞。清洗函数也很简单把所有非文件名字符替换成_就行。4.3 任务生命周期Activity 销毁、关屏与前台 Service下载任务的生命周期管理是新手和老手的明显分水岭。核心原则一句话下载不要绑在 Activity 上。用户在下载一个 500MB 文件时随时可能旋转屏幕、按 Home、甚至直接划掉 App。如果下载任务在 Activity 里发起onDestroy时协程取消下载就断了体验极差。短小文件的下载可以放在ViewModelviewModelScope里因为 ViewModel 在配置变更后还能存活。长文件下载建议上前台 Service。Android 8 之后有个强制要求启动前台服务要用startForegroundService()并且必须在 5 秒内调用同一服务实例的startForeground()并传一个通知否则系统直接报ForegroundServiceDidNotStartInTimeException这种崩溃在线上很常见就因为这个 5 秒窗口没处理好。还有一个很容易被忽视的点关屏之后 Wi-Fi 可能休眠下载速度会掉到几乎为零。做长文件下载时Service 里要申请 Wi-Fi 锁val wifiLock (getSystemService(Context.WIFI_SERVICE) as WifiManager) .createWifiLock(WifiManager.WIFI_MODE_FULL_HIGH_PERF, download_lock) wifiLock.setReferenceCounted(false) wifiLock.acquire()同样还需要PARTIAL_WAKE_LOCK保持 CPU 唤醒。锁一定要在下载结束时释放否则就是耗电元凶。很多项目下载为啥莫名慢、断流不是代码逻辑问题就是锁没挂上或者没释放。4.4 断点与任务信息的持久化模型任务信息持久化是下载模块的最后一公里。我建议用一个简单的数据库表字段如下字段类型说明taskIdString业务唯一键通常用 url 的 MD5urlString原始下载地址filePathString本地文件绝对路径totalLengthLong总大小-1 表示未知downloadedLengthLong已下载大小每次落盘更新statusInt0 待下载 / 1 下载中 / 2 暂停 / 3 完成 / 4 失败md5String可选用于完成后的校验关于downloadedLength的更新频率我的建议是不要在每次read后都写库磁盘 IO 撑不住。先放在内存里每隔 1 秒或者累计变化超过 1MB 再落盘一次。反正断点信息只需要做到App 被杀死后能恢复到上一次落盘的位置丢失最后几百 KB 的进度完全可接受宁可少写也不频繁写。md5是可选但强烈推荐的。下载完成后如果服务端提供了 MD5本地算一遍比对能拦住绝大部分下载成功但文件损坏的线上事故。没有 MD5 至少比对一下totalLength和实际文件长度不一致一律判定为失败并删除防止脏文件被业务使用。5. 真实项目里的坑一次下载卡死与文件损坏的排查记录5.1 卡死读超时设错下载 30 秒就被取消先说一个我线上真实遇到的下载卡死案例。当时有用户反馈下载某个 200MB 的离线包每次到 30 秒左右就失败而且失败之前进度条一动不动。第一反应是网络超时设置太短但日志里并没有SocketTimeoutException而是协程的CancellationException。排查到最后发现是某位同事在调用下载的地方套了一层withTimeout(30_000L)本意是防止下载接口卡死结果把整个下载链路都限制了。OkHttp 的readTimeout是两次数据读取之间的空闲超时不是整个下载的总超时——只要网络在不断传数据超时永远不会触发所以慢网下载大文件是安全的。但withTimeout是硬性的总时间上限30 秒一到直接抛异常取消协程下载半途而废。这是个非常典型的好心办坏事。建议把这条规则刻进脑子里网络层用 OkHttp 的超时语义任务层不要随便加总时长兜底。如果你实在担心某个请求永久卡住那也要把超时时间设得远超预期比如大文件至少 10 分钟起。5.2 文件损坏只校验下载完成不校验内容真实性另一个坑是下载成功假象。OkHttp 拿到200/206文件也写完了业务层直接拿去用结果在解析 zip、解析资源文件时崩溃。原因是文件确实下完了但数据不完整——比如服务端返回的 Content-Length 不准确、CDN 在传输过程中截断了连接但 TCP 层没触发异常、本地磁盘空间不够导致写入失败但异常被吞掉。我现在要求所有下载任务结束后都必须做完整性校验。最低标准是长度比对严格一点做 MD5。val downloaded targetFile.length() if (downloaded ! expectedTotal) { targetFile.delete() throw IOException(文件长度不匹配期望 $expectedTotal实际 $downloaded) }MD5 校验放在Dispatchers.IO里用MessageDigest配合DigestInputStream读一遍文件几 GB 的文件会花一点时间但值得。线上数据比下载快点重要得多因为脏文件会污染后续所有业务流程排查成本高到离谱。5.3 EOFException连接复用与服务端提前断开下载大文件时还会偶发java.io.EOFException。这个问题非常经典OkHttp 默认开了连接复用keep-alive一个连接在完成一次请求后不会立刻关闭而是放回连接池供下一个请求使用。如果服务端或者中间代理对 keep-alive 支持得不好连接实际上已经断了但客户端不知道下一次复用这个连接去读数据就会在流中间读到 EOF。这时候最容易犯的错误是从头重下。我踩过这个坑之后改成了任何 IOException 都走断点续传逻辑——文件已经写了多少就从这个位置重新发 Range 请求。这等于把网络层的不稳定用应用层的重试机制兜住了。如果某个服务端问题特别严重短时间内无法修复可以在下载请求里显式加Connection: close头让 OkHttp 不要复用这个连接。代价是每次都要重新建连速度会慢一些但至少稳定。这是临时止血方案不建议长期用。5.4 取消任务与响应体关闭泄漏call.cancel()是 OkHttp 提供的取消接口它会中断当前正在进行的读写操作。但有一个坑取消发生在execute()时会抛IOException如果你的错误处理把所有IOException都当成下载失败来记录会产生大量无意义的失败日志。我的做法是给任务维护一个isCancelled标志在异常捕获处判断catch (e: IOException) { if (task.isCancelled) { // 用户主动取消打日志不进失败统计 } else { // 真实网络错误计划重试 } }还有响应体关闭的问题。OkHttp 的Response实现了Closeable你用了execute().use { }就能自动关闭。但如果你在use块里把 body 的source()取出来单独用务必保证用完后response.close()被调用否则连接不会被释放回连接池长时间下载会耗光连接池导致后续请求全部排队超时。这个问题在开发环境不明显一到线上高并发就爆发。5.5 重定向、Cookie 与 Range 头基准变化最后一个坑是关于重定向的。OkHttp 默认followRedirects true遇到 302 会自动带上同一个请求体重新请求。但做断点续传时某些 CDN 会对带 Range 头的请求返回 302 跳转跳到另一个实际文件地址。OkHttp 跟随重定向时会保留大部分请求头但跨 Host 时部分头会被清除尤其是Authorization和Cookie这就可能导致续传请求在跳转后变成匿名请求或者 Range 头被丢弃服务端直接返回 200 完整文件。如果遇到断点续传偶尔失效这类问题排查思路是抓包看 302 跳转后的请求头里还有没有Range。没有的话建议在业务层关闭 OkHttp 的自动重定向自己捕获Location头手动发第二次请求自己决定要带哪些头。虽然代码多了几行但整个下载请求链路的可控性会大幅提升。如果你正在设计下载模块最后分享一点我的体会OkHttp 只负责把网络这一层做得漂亮而下载本质上是一个流式读写与状态管理的系统工程。把断点续传和错误恢复当成一等公民来设计而不是后期打补丁能帮你省下非常可观的返工成本。这套结构趟完上面这些坑之后我的线上下载模块崩溃率基本归零至少目前没有再被文件下载的问题半夜叫醒过。