更新

更新了一下断点下载的实现部分，根据大家的评论做了一些更正和完善。

前言

最近过了金三银四的金三，顺利拿到了暑假实习生的offer。实习部门leader给我布置了入职前学习任务，强化多线程、数据库方面的知识，并建议我实现一个和他们产品中类似的下载器。

实现思路

本文的重点在下载部分的实现。目前我也正在做单个任务下载开发与优化。后续更新完成后如果有好的思路也会分享给大家。项目地址是：https://github.com/SirLYC/Yuchuan-Downloader （处于开发中）

断点下载

首先，下载器有断点续传功能，断点续传实现的基础知识就是HTTP协议中的Range头部。比如，一个文件有500bytes，我要从第200个bytes下载，就在请求的头部添加一个key为Range的项，内容是bytes=200-。因此，在实现的时候，我们需要记录当前的下载量，在恢复下载的时候，就可以从上次的当前下载量开始下载，节省用户流量。

但是并不是所有的服务器都支持断点下载。因此，可以在正式的下载前先发一个请求，在请求中添加Range字段，顺带也可以通过这种方式获取文件长度（ContentLength首部）。

而之前在评论区有小伙伴说添加Range怎样获取文件文件长度的问题。我发送的请求Range字段的值是bytes=0-，是从第0个字节开始请求文件。因此，如果这个请求能够正常的返回，并且有contentLength头部，那就一定是文件总长度。bytes=0-表示请求全部文件，但是对于支持断点续传的服务器，也是会返回206 partial content（我测试过几个链接，都是这样）。

关于这一点我也不敢说非常肯定，但按照协议，在有Range字段时，服务器，服务器应该做的是检查Range是否合理，只要合理并且支持就是206返回。

但如果服务器返回416表示不支持呢？这个时候我们就不能获取到不支持断点的文件长度了，因此我之前的代码实现可能会有问题。实际上还有这个字段If-Range，如果服务器支持断点，会返回206，不支持的话就会返回200并附带全部内容，这样就可以解决这个问题了。

对于bytes=0-可能支持断点的服务器会判断一下返回200的情况，我也想了另一个方法：请求一个字节。使用If-Range=0-0去请求，支持断点时返回Content-Range获取文件总长度。这种方式下，对于下载文件只有1个字节的情况，就算返回的不是206是200（全部返回），是否用断点无差别。

评论区还有小伙伴问到，万一服务器不支持怎么办？我认为，首先，对于产品来讲，首先要适配大部分的情况，而下载的例子，大部分情况就是网络协议，我们认为服务器会按照协议要求来实现，这也是为什么我直接使用前面的方法去检测是否支持断点续传。在实际生产环境中，如果遇到了部分不遵守协议的服务器，就只能做特殊处理了，但实际上这个特殊处理有没有必要呢？这就仁者见仁智者见智了。

这里简单说一下下载文件的原理。在一个GET请求时，服务器首先会把头部报文全部返回给你，如果是下载文件，一般来说都是流下载，有一个标志会告诉你responseBody是流。而HTTP又是基于TCP的，这个流实际上就是TCP的流，在Java中对应的就是InputStream。流可以看作是一个只能向后走的指针，指针指向下一个待读取的字节，并且读取了一个才能读下一个。因此，如果暂停恢复不用部分请求的话，你必须得把前面下载过的字节全部接受一遍，这显然浪费了时间和流量。

多线程下载

首先要知道，多线程是基于断点下载的原理。一个文件实际上就是二进制数据，把文件拆分成多个段，每个线程下载各自的段。因此每个线程在请求时需要控制文件起始和结尾，给每一个线程分配下载的段。因此，不支持断点续传的服务器是不能用多线程下载的。

那为什么多线程下载可以提速呢？首先比较显然的一点是多线程可以利用CPU多核的特性，在相同时间内完成更多的任务。但事实上基于这一点不会提高多大的速度，因为接收端的总带宽是一定的。想象一个这个场景：

上面的小水管就是我们的服务端连接，每个连接限制了最大带宽。大水管就是接收端，接收端带宽一定。当我们启用一个小水管时，我们可以获得的最大流速是min(小水管、大水管)。当我们启用多个水管时，最大速度是min(小水管1+小水管2+...+小水管n，大水管)。可见，在这种场景下的多线程，瓶颈就不会再是服务端的带宽限制。

那线程是不是越多越好呢？ 显然这是不对的。线程本身就是一个很重的对象，创建线程、多线程调度管理会占用CPU时间，会减少用户时间比例。另外就是多线程对内存的占用也是一个问题。因此，启动的下载线程数要有限制。

下载与写线程分开

以前写下载器时，常见的下载模式是

// 伪代码
while (data remains to read) {
    buffer = inputstream.read(bufferSize)
    outputstream.write(buffer)
}

在多线程的情况下大概是这样的

当时现场面试的时候我也讲下载器可以这么实现，结果面试官上来问一句，读和写真的要放在一个线程？从目前来讲，写磁盘的速度一般都是远大于网络获取的速度的。如果我们能把写数据放在一个单独的线程里，假设3个线程以相同的速度读取相同大小的网络字节流放在缓冲区，每个线程都把各自的缓冲区送入写线程，然后又各自去读网络数据。因为我们写的速度大于网络下载速度的，因此在下一次3个缓冲区送入前是可以写完的，这样在理想情况下就节省了1次写磁盘的时间。

但在实际实现时，有很多需要注意的地方。首先下载线程不能无限制的下载。如果写线程阻塞了，下载线程还在不停下载的话，缓冲区会越来越大，造成OOM。另外就是缓冲区的交换，写线程需要拿，下载线程需要送，这是一个典型的消费者——生产者模式。这方面的实现文章就多了，最终我是选用的BlockQueue来实现。大致的流程如下：

上述流程中，还有很多未包括所有内容，比如错误处理，状态转换等。实际上，要写一个用户体验好，性能好的下载器是一件很不容易的事。

后续

目前，我的项目上实现的只有单任务多线程的下载，多任务、下载信息本地保存等还未实现。

除了这些以外，我还会考虑加入多进程的架构，可以实现ui退出后的离线下载。欢迎大家clone跑sample或者提一些意见！

再次挂上项目地址：https://github.com/SirLYC/Yuchuan-Downloader