Android多线程断点续传实战：从原理到多任务调度与避坑

简介这份资源面向Android中高级开发者聚焦多线程、断点续传与同时下载多个大文件这一性能优化场景帮助解决大文件下载中UI阻塞、重复下载和并发失控等常见问题。压缩包共1142个文件约8.63MB以476个png、415个xml、128个json等资源与配置为主另有65个class、22个java源码、12个jar及6个aidl接口文件并包含4个apk与dex等可运行产物便于直接对照调试。内容围绕ThreadPoolExecutor线程池管理、下载进度本地持久化、异常恢复与UI同步等关键环节展开同时涉及OkHttp、Retrofit等第三方库的断点续传实现思路。已有804人学习下载适合需要系统掌握并发下载与线程调度、并希望获得可参考工程结构的开发者研读。1. 从一次下载翻车说起Android 多线程断点续传到底解决什么问题去年帮一个做视频素材库的团队排查问题他们的 App 需要在弱网环境下批量拉取几十个上百 MB 的素材包。最初用的是系统自带的 DownloadManager单任务串行结果用户在地铁里切一次网络进度条直接归零重来投诉量居高不下。后来换成自己写的多线程断点续传同样的网络环境下载成功率从六成出头拉到了九成五以上。这就是这个资源要讲清楚的事在 Android 上怎么把一个大文件切成多段并发下载怎么在断网、杀进程、切后台之后还能接着上次的位置继续以及怎么同时管理多个这样的下载任务而不把手机资源和流量搞崩。它适合两类人一类是正在做离线缓存、素材预加载、OTA 包更新这类功能的 Android 开发另一类是已经用了 OkHttp 但只会enqueue一个整包请求、没处理过Range头和随机读写文件的同学。下面按「原理选型 → 单任务实现 → 多任务调度 → 踩坑排查 → 进阶技巧」的顺序拆代码可以直接抄参数我会标清楚为什么这么设。2. 断点续传的底层逻辑Range 请求与 RandomAccessFile 怎么配合2.1 为什么必须用 HTTP Range而不是自己记偏移量断点续传的核心不是「记住下载到哪了」而是「让服务端只给你没拿到的那一段」。HTTP/1.1 的Range头就是干这个的格式是Range: bytesstart-end服务端如果支持会返回206 Partial Content和Content-Range头。这里有个容易被忽略的前提服务端必须支持 Range 请求。判断方法是先发一个HEAD请求看响应头里有没有Accept-Ranges: bytes。如果没有你客户端写得再花哨也只能整包重下。我一般会在下载开始前做一次探测# 用 curl 探测服务端是否支持断点续传 curl -I -H Range: bytes0-1 https://example.com/bigfile.zip # 关注两个响应头 # HTTP/1.1 206 Partial Content - 支持 # Accept-Ranges: bytes - 支持 # 如果返回 200 OK 且没有 Accept-Ranges说明不支持逻辑说明发一个只请求前 2 字节的 Range 请求成本极低。如果返回 206说明服务端认这个头返回 200 说明它忽略了 Range直接给你整包。参数上bytes0-1只是探测真正下载时 start 和 end 由分片策略决定。2.2 RandomAccessFile多线程写同一个文件的唯一正确姿势多线程下载最容易翻车的地方是「多个线程同时写一个文件」。用普通的FileOutputStream加seek是不行的因为它的写指针是共享的。正确做法是每个线程各自持有一个RandomAccessFile实例通过seek(position)定位到自己的分片起点再写。文件在下载前要先setLength(totalLength)预分配好大小否则多线程写入时文件长度会乱。// 每个分片线程独立打开 RandomAccessFile定位到自己的起点 RandomAccessFile raf new RandomAccessFile(file, rwd); raf.seek(startPos); // 定位到本分片的起始字节 byte[] buffer new byte[8192]; int len; while ((len inputStream.read(buffer)) ! -1) { raf.write(buffer, 0, len); downloaded len; // 这里要持久化进度见 2.3 } raf.close();参数说明rwd模式表示每次写入都同步到磁盘比rw安全但慢一些。对于下载场景我一般用rw配合定期fd.sync()兼顾速度和可靠性。buffer大小 8192 是经验值太小系统调用频繁太大内存占用高8KB 到 64KB 都合理。2.3 进度持久化别把进度只存在内存里断点续传的「断点」必须落到磁盘否则进程一被杀就全丢了。常见做法是用一个轻量的数据库表记录每个任务的每个分片状态。字段至少要有任务 ID、分片索引、起始字节、结束字节、已下载字节、分片状态。每次写入一批数据后更新一次不要每写一个 buffer 就更新数据库那样 IO 会成为瓶颈。-- 分片进度表SQLite 即可 CREATE TABLE download_chunk ( task_id TEXT NOT NULL, chunk_index INTEGER NOT NULL, start_pos INTEGER NOT NULL, end_pos INTEGER NOT NULL, downloaded INTEGER DEFAULT 0, state INTEGER DEFAULT 0, -- 0待下载 1下载中 2已完成 PRIMARY KEY (task_id, chunk_index) );逻辑说明恢复下载时先查这个表把所有state ! 2的分片重新入队每个分片的起点是start_pos downloaded。这样即使只下了一半也能从半截继续。注意downloaded要定期更新我一般每写入 512KB 或每 2 秒更新一次太频繁会拖慢下载。3. 单任务多线程下载的完整实现线程池、分片与合并3.1 分片策略固定大小还是按线程数均分分片有两种常见做法。一种是固定分片大小比如每片 1MB大文件自然切成很多片适合线程池动态调度另一种是按线程数均分比如 4 个线程就把文件切成 4 段。前者更灵活后者实现简单。我一般用固定分片大小因为大文件下均分会导致每个分片仍然很大单线程下载时间长不利于负载均衡。// 按固定分片大小切分最后一片可能不足 chunkSize long chunkSize 1024 * 1024; // 1MB 一片 long totalLength contentLength; int chunkCount (int) Math.ceil((double) totalLength / chunkSize); for (int i 0; i chunkCount; i) { long start i * chunkSize; long end Math.min(start chunkSize - 1, totalLength - 1); // 把 (i, start, end) 写入 download_chunk 表state0 }参数说明chunkSize设 1MB 是个平衡点。太小会导致分片数量爆炸数据库和线程调度压力大太大则失去并发粒度。对于几百 MB 的文件1MB 到 4MB 都合适。end要减 1 是因为 HTTP Range 是闭区间bytes0-1048575表示前 1MB。3.2 线程池配置别用 Executors.newFixedThreadPool很多教程直接用Executors.newFixedThreadPool(4)这在下载场景里是有隐患的。固定线程池的队列是无界的如果同时有几十个任务队列会堆积大量待执行的分片内存和调度都会出问题。更稳的做法是用ThreadPoolExecutor显式指定有界队列和拒绝策略或者干脆每个任务一个独立的线程池任务之间隔离。// 每个下载任务独立的线程池避免任务间互相影响 int coreThreads 4; ThreadPoolExecutor executor new ThreadPoolExecutor( coreThreads, coreThreads, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue(64), // 有界队列防止无限堆积 new ThreadFactory() { private final AtomicInteger count new AtomicInteger(0); Override public Thread newThread(Runnable r) { Thread t new Thread(r, download- count.incrementAndGet()); t.setPriority(Thread.NORM_PRIORITY - 1); // 略低于 UI 线程 return t; } }, new ThreadPoolExecutor.CallerRunsPolicy() // 队列满时由调用线程执行形成背压 );逻辑说明核心和最大线程数都设 4是因为移动网络下并发太高反而会因为丢包和重传导致总吞吐下降。队列容量 64 配合CallerRunsPolicy当分片生产速度超过消费速度时提交分片的线程会被拉来干活自然限流。线程优先级略降避免下载抢占 UI 线程的 CPU。3.3 分片下载与合并注意文件句柄和校验每个分片下载完成后把download_chunk表里对应记录的state置为 2。所有分片都完成后文件其实已经写好了因为每个线程都是直接写目标文件的对应位置不需要额外的合并步骤。但这里有个坑必须确认所有分片的RandomAccessFile都已关闭否则文件句柄泄漏后续读取或删除会失败。// 分片下载完成后检查是否全部完成 boolean allDone true; for (Chunk c : chunks) { if (c.state ! 2) { allDone false; break; } } if (allDone) { // 可选做一次整体校验比如比对 Content-Length 或 MD5 if (file.length() totalLength) { // 标记任务完成通知 UI } else { // 长度不对说明有分片写漏了需要排查 } }参数说明file.length()比对totalLength是最低成本的完整性检查。如果服务端提供了Content-MD5或你自己有 MD5 值可以进一步校验。注意不要在下载线程里做 MD5大文件算 MD5 很耗时放到独立线程或下载完成后再做。4. 多任务并发调度怎么同时下多个大文件还不卡4.1 全局并发控制任务级和分片级的两层限流同时下载多个大文件时如果每个任务都开 4 个线程5 个任务就是 20 个线程同时抢带宽结果每个都慢。合理的做法是两层限流任务级限制同时进行的任务数比如 3 个分片级限制全局同时下载的分片数比如 8 个。任务级用信号量控制分片级用一个全局的Semaphore或者共享线程池。// 全局分片并发信号量所有任务共享 Semaphore globalChunkSemaphore new Semaphore(8); // 每个分片下载前获取许可 globalChunkSemaphore.acquire(); try { // 执行分片下载 } finally { globalChunkSemaphore.release(); }逻辑说明acquire()会阻塞直到有空闲许可这样即使有 10 个任务同时想下实际同时进行的分片也不会超过 8 个。许可数 8 是经验值对应移动网络下比较舒服的并发度。WiFi 下可以适当调高到 12 到 16但要注意服务端可能有限流。4.2 任务队列与状态机等待、下载中、暂停、完成多任务管理需要一个清晰的状态机。我一般定义这几个状态WAITING排队中、DOWNLOADING下载中、PAUSED暂停、COMPLETED完成、FAILED失败。任务提交后先进入WAITING由调度器按顺序激活。用户暂停时把任务状态置为PAUSED同时中断所有分片线程恢复时重新入队。// 任务状态枚举 public enum TaskState { WAITING, DOWNLOADING, PAUSED, COMPLETED, FAILED } // 调度器核心逻辑从等待队列取任务激活到下载中 private void scheduleNext() { if (activeCount.get() maxActiveTasks) return; DownloadTask next waitingQueue.poll(); if (next null) return; activeCount.incrementAndGet(); next.setState(TaskState.DOWNLOADING); next.start(); // 内部提交分片到线程池 }参数说明maxActiveTasks建议设 2 到 3。设 1 就退化成串行设太大则每个任务都慢。waitingQueue用PriorityQueue可以支持优先级比如用户手动点开的任务优先。4.3 网络切换与后台限制Android 8.0 之后的坑Android 8.0 之后后台应用启动前台服务有限制长时间下载必须用ForegroundService并显示通知否则系统会在几分钟内杀掉你的下载。另外网络切换WiFi 切 4G时已经建立的连接会断开分片线程会抛异常。我一般会注册ConnectivityManager.NetworkCallback在网络切换时暂停所有任务等新网络稳定后再恢复。// 注册网络回调网络切换时暂停下载 ConnectivityManager cm (ConnectivityManager) getSystemService(CONNECTIVITY_SERVICE); cm.registerDefaultNetworkCallback(new ConnectivityManager.NetworkCallback() { Override public void onLost(Network network) { // 网络断开暂停所有下载任务 downloadManager.pauseAll(); } Override public void onAvailable(Network network) { // 新网络可用恢复等待中的任务 downloadManager.resumeAll(); } });逻辑说明onLost触发时不要立即重试因为可能只是短暂切换。我一般加一个 2 秒的延迟再恢复避免频繁重连。另外ForegroundService的通知要显示总进度否则用户会以为 App 卡死了。5. 避坑与排查那些让我加班到凌晨的下载问题5.1 现象下载到 99% 卡住不动原因最常见的是最后一个分片的end计算错了。如果totalLength是 1000000chunkSize是 1048576那么只有一个分片end应该是 999999但如果代码写成start chunkSize - 1就是 1048575超出了文件长度服务端返回 416 或者直接断开。另一个可能是分片状态没更新调度器以为还有分片没完成但实际线程已经退出了。解决分片计算时强制end Math.min(start chunkSize - 1, totalLength - 1)。同时在分片线程的finally块里确保状态更新即使异常也要把状态置为失败或待重试不能让记录悬空。5.2 现象多任务同时下载时某个任务进度长时间不变原因全局信号量被其他任务的分片占满了这个任务的分片一直在等许可。如果其他任务的分片下载很慢比如服务端限速就会导致这个任务饿死。解决给每个任务设置一个最小并发保障比如每个任务至少能同时跑 1 个分片。实现上可以用两级信号量或者调度器轮转分配许可。我一般会在任务级别加一个Semaphore(1)确保每个活跃任务至少有一个分片在跑。5.3 现象下载完成后文件打不开或校验失败原因多个线程写同一个文件时如果没有预分配文件大小或者某个线程的seek位置算错会导致数据写串。另一个常见原因是RandomAccessFile没有正确关闭缓冲区数据没刷到磁盘。解决下载前必须raf.setLength(totalLength)预分配。每个分片线程用自己的RandomAccessFile实例用完在finally里close()。如果用了BufferedOutputStream包装记得flush()。校验时比对文件长度和Content-Length有条件再比对 MD5。5.4 现象Android 10 以上下载的文件在相册或文件管理器里看不到原因Android 10 引入了分区存储应用不能直接往公共目录写文件除非用MediaStore或者SAF。如果你用RandomAccessFile往外部存储的公共路径写会抛FileNotFoundException或者写到一个应用私有目录里用户看不到。解决下载到应用私有目录getExternalFilesDir()完成后再通过MediaStore插入到公共媒体库或者用FileProvider分享。如果必须直接写公共目录用MediaStore.Downloads的openFileDescriptor拿到FileDescriptor再构造RandomAccessFile。5.5 现象暂停后恢复进度从 0 开始原因暂停时只中断了线程但没有把已下载的字节数持久化到数据库。恢复时读到的downloaded还是 0于是从分片起点重新下。解决暂停操作要等当前写入批次完成后先更新数据库再中断线程。我一般用一个volatile boolean paused标志分片线程每写完一个 buffer 检查一次如果暂停就更新进度并退出。恢复时从数据库读start_pos downloaded作为新起点。6. 进阶技巧用 WorkManager 做可靠调度与一个校验习惯如果你不想自己维护前台服务和网络回调可以用WorkManager来调度下载任务。WorkManager天然支持约束条件比如只在 WiFi 下下载、失败重试和进程被杀后恢复。把每个大文件下载封装成一个Worker在doWork()里启动多线程分片下载用setProgress()上报进度。WorkManager会在合适的时机重新调度省去不少样板代码。// 用 WorkManager 调度下载任务约束 WiFi 和充电 val constraints Constraints.Builder() .setRequiredNetworkType(NetworkType.UNMETERED) // 只在 WiFi 下 .setRequiresCharging(false) .build() val downloadRequest OneTimeWorkRequestBuilderDownloadWorker() .setConstraints(constraints) .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 30, TimeUnit.SECONDS) .addTag(download_task_001) .build() WorkManager.getInstance(context).enqueueUniqueWork( download_task_001, ExistingWorkPolicy.KEEP, // 已存在则不重复入队 downloadRequest )参数说明NetworkType.UNMETERED表示只在非计费网络下下载适合大文件。BackoffPolicy.EXPONENTIAL配合 30 秒初始延迟失败后重试间隔会指数增长避免频繁重试耗电。ExistingWorkPolicy.KEEP保证同一个任务不会重复入队。最后说一个我踩过多次坑之后养成的习惯每次下载完成后强制走一遍「长度比对 首尾字节抽样比对」。长度比对就是file.length() contentLength首尾抽样是读文件的前 16 字节和后 16 字节和服务端返回的Content-Range里的对应位置比对。这个检查成本极低但能拦住绝大多数因为分片写串或提前关闭导致的文件损坏。从那以后我每次写下载模块不管多赶这个校验都强制走一遍省下了好几次线上事故的后悔药。希望帮到你。本文还有配套的精品资源点击获取