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

8,043 阅读7分钟

更新

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

前言

最近过了金三银四的金三,顺利拿到了暑假实习生的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…