VBrowser-Android架构剖析：DownloadManager任务调度与前台下载服务

VBrowser-Android架构剖析：DownloadManager任务调度与前台下载服务

【免费下载链接】VBrowser-Android全网视频嗅探缓存APP项目地址: https://gitcode.com/gh_mirrors/vb/VBrowser-Android

VBrowser-Android 是一款开源的全网视频嗅探缓存APP，它不仅能自动嗅探网页中的视频链接，还内置了一套完整的多任务下载引擎。这篇文章将带你深入剖析它的下载核心：DownloadManager任务调度机制与DownloadForegroundService前台下载服务，看看一个视频从"被嗅探到"到"完整保存到手机"的全过程是如何被精心设计的。即使你刚接触 Android 开发，也能从中读懂这套架构的精妙之处。

为什么需要一个统一的下载调度器？🚀

当你在浏览器里点开一个视频，VBrowser-Android 的嗅探器会立刻捕捉到视频地址。但真正下载时，问题就来了：视频可能是 M3U8 直播流（成百上千个 .ts 切片），也可能是普通 MP4 大文件；用户可能同时添加多个任务，而手机网络和内存资源是有限的。如果每个任务都"各干各的"，很容易造成卡顿、崩溃甚至被系统杀死。

所以项目把所有下载请求都集中交给 DownloadManager.java 这个"总调度室"，由它统一排队、分配线程、控制并发，并在后台用前台服务保住下载进程的"性命"。

任务调度三板斧：任务表、等待队列与工作线程

DownloadManager 的核心调度逻辑非常经典，只用三个数据结构就完成了全部工作：

当新任务到来时，addTask()（见 DownloadManager.java）会先把它放入任务表，然后判断当前运行线程数是否达到上限maxConcurrentTask（默认 2）。没满就直接开新线程下载；满了就扔进队列排队。这个"先到先得 + 排队补位"的机制，保证了任意时刻最多只有 2 个任务在同时下载，资源永远不会被打爆。

用 ReentrantLock 保证调度安全

调度逻辑涉及多线程读写任务表，稍不留神就会数据错乱。项目在addTask、cancelAllTask、taskFinished、taskFailed等关键方法外围都加了ReentrantLock互斥锁，确保"判断并发数"和"启动线程"这两个动作原子完成，代码虽简单，严谨度却很高。

任务结束后的"补位"操作

当一个任务完成或失败时，taskFinished()/taskFailed()会从运行表中移除该任务，然后立刻从等待队列里取出下一个任务启动下载。如果发现运行表空了，就调用stopDownloadForegroundService()关闭前台服务——下载全部结束，通知栏也就没必要常驻了。

两种下载线程：M3U8 与普通文件的"分头行动"

getDownloadTaskThread()会根据任务类型创建不同的线程：M3U8 任务走M3u8DownloadTaskThread，普通文件走NormalFileDownloadTaskThread。这两种下载策略差异巨大，值得单独拆开看。

M3U8 视频下载：多线程切片下载的秘密

M3U8 本质是一个索引文件，里面按行记录着每个 .ts 分片的地址。M3u8DownloadTaskThread（见 DownloadManager.java）的流程是：

1. 解析索引：递归解析parseM3u8()，把每个切片 URL 和加密 Key 分别放入"测大小队列"和"下载队列"；
2. 先探测后下载：先发 HEAD 请求获取每个切片的 Content-Length，累加成任务总大小，用于进度条计算；
3. 多线程狂飙：默认启动 20 个（m3U8DownloadThreadNum）工作线程并发拉取切片，失败自动重试最多 50 次；
4. 重写索引：下载完把切片重命名为 UUID 文件名，并改写 M3U8 索引内容，确保离线也能本地播放。

这里还有一个精妙设计：独立的speedCheckerThread每秒清零一次"增量下载字节数"，实时计算瞬时下载速度，让下载中心的速度数字一直保持跳动。

普通视频下载：Range 断点分片与文件合并

对于 MP4 这类单文件，NormalFileDownloadTaskThread采用了 HTTP Range 分片下载：先发 HEAD 请求探测服务器是否支持Accept-Ranges: bytes。支持的话，就把文件按 2MB（normalFileSplitSize）切成 N 段，每段由一个工作线程用Range: bytes=start-end头并发下载（默认 5 线程），最后用 Java NIO 的FileChannel+ByteBuffer把碎片按顺序合并成完整文件；不支持 Range 的服务器则退化为单线程整包下载，兼容性拉满。

前台下载服务：下载任务的"护身符" 🛡️

Android 系统会优先杀死后台进程来释放内存，长时间下载的任务很容易被"误伤"。VBrowser-Android 的解法是启动 DownloadForegroundService.java 前台服务：一旦进入前台，系统就会在通知栏展示常驻通知（"前台任务：正在下载"），大幅降低进程被杀概率，用户也能随时看到下载状态。

这个服务的使用方式很讲究——它不做任何下载工作，纯粹是"保命"用的：

• MainApplication.startDownloadForegroundService()在addTask()里被调用，任务一进来就拉起服务；
• 当最后一个任务结束时自动stopService关掉服务，避免通知栏残留；
• 服务内部兼容 Android 8.0+ 的NotificationChannel通知渠道机制，老旧系统也能正常显示。

前台服务与下载任务的"生命周期"完全同步，代码量虽少，却体现了非常成熟的 Android 后台任务设计思路。

从嗅探到下载：一次完整的任务流转 🔄

把上面所有环节串起来，一条视频的完整旅程是这样的：

1. 嗅探：VideoSniffer在 WebView 里抓到视频地址；
2. 建任务：MainActivity.onAddNewDownloadTaskEvent()（见 MainActivity.java）封装DownloadTask并调用addTask()；
3. 调度：DownloadManager 判断并发名额，启动对应类型的下载线程；
4. 保活：前台服务同步开启，常驻通知栏；
5. 下载：M3U8 切片并发下载或普通文件 Range 分片下载，进度与速度实时刷新；
6. 收尾：任务完成，队列补位；全部结束则关闭前台服务，通知消失。

整个流程中，任务状态机（ready → loading → running → saving → error）由DownloadTask实体管理，下载中心页面则通过 EventBus 事件和每秒一次的定时刷新来同步 UI 进度。

写在最后

从 DownloadManager 的并发控制、双队列调度，到 M3U8/普通文件两套下载策略，再到前台服务的生命周期管理，VBrowser-Android 用并不复杂的代码实现了一个相当可靠的视频下载引擎。对于想学习 Android 多线程下载、任务调度或前台服务用法的开发者来说，这份源码（核心实现集中在 DownloadManager.java 与 DownloadForegroundService.java，配置项见 AppConfig.java）是一份值得反复研读的实战教材。如果你也打算做一个带下载功能的应用，不妨参考它的这套"调度器 + 前台服务"架构，少走很多弯路。

【免费下载链接】VBrowser-Android全网视频嗅探缓存APP项目地址: https://gitcode.com/gh_mirrors/vb/VBrowser-Android