Android高速下载器实现思路——单个任务的提速与优化

更新

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

前言

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

实现思路

本文的重点在下载部分的实现。目前我也正在作单个任务下载开发与优化。后续更新完成后若是有好的思路也会分享给你们。 项目地址是：github.com/SirLYC/Yuch… （处于开发中）

断点下载

首先，下载器有断点续传功能，断点续传实现的基础知识就是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或者提一些意见！

再次挂上项目地址：github.com/SirLYC/Yuch…