Android 高速下载器实现思路——单个任务的提速与优化，flutter 二维码扫描

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

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

而之前在评论区有小伙伴说添加Range怎样获取文件文件长度的问题。我发送的请求Range字段的值是bytes=0-，是从第 0 个字节开始请求文件。因此，如果这个请求能够正常的返回，并且有contentLength头

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

部，那就一定是文件总长度。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)}