前言
最近过了金三银四的金三，顺利拿到了暑假实习生的offer。实习部门leader给我布置了入职前学习任务，强化多线程、数据库方面的知识，并建议我实现一个和他们产品中类似的下载器。
实现思路
本文的重点在下载部分的实现。目前我也正在做单个任务下载开发与优化。后续更新完成后如果有好的思路也会分享给大家。
项目地址是：https://github.com/SirLYC/Yuchuan-Downloader
（处于开发中）
断点下载
首先，下载器有断点续传功能，断点续传实现的基础知识就是HTTP协议中的Range头部。比如，一个文件有500bytes，我要从第200个bytes下载，就在请求的头部添加一个key为Range的项，内容是bytes=200-。因此，在实现的时候，我们需要记录当前的下载量，在恢复下载的时候，就可以从上次的当前下载量开始下载，节省用户流量。
但是并不是所有的服务器都支持断点下载。因此，可以在正式的下载前先发一个请求，在请求中添加Range字段，顺带也可以通过这种方式获取文件长度（ContentLength首部）。
这里简单说一下下载文件的原理。在一个GET请求时，服务器首先会把头部报文全部返回给你，如果是下载文件，一般来说都是流下载，有一个标志会告诉你
responseBody是流。而HTTP又是基于TCP的，这个流实际上就是TCP的流，在Java中对应的就是InputStream。流可以看作是一个只能向后走的指针，指针指向下一个待读取的字节，并且读取了一个才能读下一个。因此，如果暂停恢复不用部分请求的话，你必须得把前面下载过的字节全部接受一遍，这显然浪费了时间和流量。
多线程下载
首先要知道，多线程是基于断点下载的原理。一个文件实际上就是二进制数据，把文件拆分成多个段，每个线程下载各自的段。因此每个线程在请求时需要控制文件起始和结尾，给每一个线程分配下载的段。因此，不支持断点续传的服务器是不能用多线程下载的。
那为什么多线程下载可以提速呢？首先比较显然的一点是多线程可以利用CPU多核的特性，在相同时间内完成更多的任务。但事实上基于这一点不会提高多大的速度，因为接收端的总带宽是一定的。想象一个这个场景：
image
上面的小水管就是我们的服务端连接，每个连接限制了最大带宽。大水管就是接收端，接收端带宽一定。当我们启用一个小水管时，我们可以获得的最大流速是min(小水管、大水管)。当我们启用多个水管时，最大速度是min(小水管1+小水管2+…+小水管n，大水管)。可见，在这种场景下的多线程，瓶颈就不会再是服务端的带宽限制。
那线程是不是越多越好呢？ 显然这是不对的。线程本身就是一个很重的对象，创建线程、多线程调度管理会占用CPU时间，会减少用户时间比例。另外就是多线程对内存的占用也是一个问题。因此，启动的下载线程数要有限制。
下载与写线程分开
以前写下载器时，常见的下载模式是
// 伪代码
while (data remains to read) {
buffer = inputstream.read(bufferSize)
outputstream.write(buffer)
}
在多线程的情况下大概是这样的
image
当时现场面试的时候我也讲下载器可以这么实现，结果面试官上来问一句，读和写真的要放在一个线程？
从目前来讲，写磁盘的速度一般都是远大于网络获取的速度的。如果我们能把写数据放在一个单独的线程里，假设3个线程以相同的速度读取相同大小的网络字节流放在缓冲区，每个线程都把各自的缓冲区送入写线程，然后又各自去读网络数据。因为我们写的速度大于网络下载速度的，因此在下一次3个缓冲区送入前是可以写完的，这样在理想情况下就节省了1次写磁盘的时间。
但在实际实现时，有很多需要注意的地方。首先下载线程不能无限制的下载。如果写线程阻塞了，下载线程还在不停下载的话，缓冲区会越来越大，造成OOM。另外就是缓冲区的交换，写线程需要拿，下载线程需要送，这是一个典型的消费者——生产者模式。这方面的实现文章就多了，最终我是选用的BlockQueue来实现。大致的流程如下：
image
上述流程中，还有很多未包括所有内容，比如错误处理，状态转换等。实际上，要写一个用户体验好，性能好的下载器是一件很不容易的事。
后续
目前，我的项目上实现的只有单任务多线程的下载，多任务、下载信息本地保存等还未实现。
除了这些以外，我还会考虑加入多进程的架构，可以实现ui退出后的离线下载。欢迎大家clone跑sample或者提一些意见！
