11.4 实例：Http分块下载
本节将通过一个“Http分块下载”的示例演示一下dio的具体用法。
原理
Http协议定义了分块传输的响应header字段，但具体是否支持取决于Server的实现，我们可以指定请求头的"range"字段来验证服务器是否支持分块传输。例如，我们可以利用curl命令来验证：
1bogon:~ duwen$ curl -H "Range: bytes=0-10" http://download.dcloud.net.cn/HBuilder.9.0.2.macosx_64.dmg -v
2# 请求头
3> GET /HBuilder.9.0.2.macosx_64.dmg HTTP/1.1
4> Host: download.dcloud.net.cn
5> User-Agent: curl/7.54.0
6> Accept: */*
7> Range: bytes=0-10
8# 响应头
9< HTTP/1.1 206 Partial Content
10< Content-Type: application/octet-stream
11< Content-Length: 11
12< Connection: keep-alive
13< Date: Thu, 21 Feb 2019 06:25:15 GMT
14< Content-Range: bytes 0-10/233295878
15我们在请求头中添加"Range: bytes=0-10"的作用是，告诉服务器本次请求我们只想获取文件0-10(包括10，共11字节)这块内容。如果服务器支持分块传输，则响应状态码为206，表示“部分内容”，并且同时响应头中包含“Content-Range”字段，如果不支持则不会包含。我们看看上面“Content-Range”的内容：
1Content-Range: bytes 0-10/2332958780-10表示本次返回的区块，233295878代表文件的总长度，单位都是byte, 也就是该文件大概233M多一点。
基于此，我们可以设计一个简单的多线程的文件分块下载器，实现的思路是：
- 先检测是否支持分块传输，如果不支持，则直接下载；若支持，则将剩余内容分块下载。
- 各个分块下载时保存到各自临时文件，等到所有分块下载完后合并临时文件。
- 删除临时文件。
实现
下面是整体的流程：
1// 通过第一个分块请求检测服务器是否支持分块传输
2Response response = await downloadChunk(url, 0, firstChunkSize, 0);
3if (response.statusCode == 206) { //如果支持
4 //解析文件总长度，进而算出剩余长度
5 total = int.parse(
6 response.headers.value(HttpHeaders.contentRangeHeader).split("/").last);
7 int reserved = total -
8 int.parse(response.headers.value(HttpHeaders.contentLengthHeader));
9 //文件的总块数(包括第一块)
10 int chunk = (reserved / firstChunkSize).ceil() + 1;
11 if (chunk > 1) {
12 int chunkSize = firstChunkSize;
13 if (chunk > maxChunk + 1) {
14 chunk = maxChunk + 1;
15 chunkSize = (reserved / maxChunk).ceil();
16 }
17 var futures = <Future>[];
18 for (int i = 0; i < maxChunk; ++i) {
19 int start = firstChunkSize + i * chunkSize;
20 //分块下载剩余文件
21 futures.add(downloadChunk(url, start, start + chunkSize, i + 1));
22 }
23 //等待所有分块全部下载完成
24 await Future.wait(futures);
25 }
26 //合并文件文件
27 await mergeTempFiles(chunk);
28}下面我们使用dio的download API 实现downloadChunk：
1//start 代表当前块的起始位置，end代表结束位置
2//no 代表当前是第几块
3Future<Response> downloadChunk(url, start, end, no) async {
4 progress.add(0); //progress记录每一块已接收数据的长度
5 --end;
6 return dio.download(
7 url,
8 savePath + "temp$no", //临时文件按照块的序号命名，方便最后合并
9 onReceiveProgress: createCallback(no), // 创建进度回调，后面实现
10 options: Options(
11 headers: {"range": "bytes=$start-$end"}, //指定请求的内容区间
12 ),
13 );
14}接下来实现mergeTempFiles:
1Future mergeTempFiles(chunk) async {
2 File f = File(savePath + "temp0");
3 IOSink ioSink= f.openWrite(mode: FileMode.writeOnlyAppend);
4 //合并临时文件
5 for (int i = 1; i < chunk; ++i) {
6 File _f = File(savePath + "temp$i");
7 await ioSink.addStream(_f.openRead());
8 await _f.delete(); //删除临时文件
9 }
10 await ioSink.close();
11 await f.rename(savePath); //合并后的文件重命名为真正的名称
12}下面我们看一下完整实现：
1/// Downloading by spiting as file in chunks
2Future downloadWithChunks(
3 url,
4 savePath, {
5 ProgressCallback onReceiveProgress,
6}) async {
7 const firstChunkSize = 102;
8 const maxChunk = 3;
9
10 int total = 0;
11 var dio = Dio();
12 var progress = <int>[];
13
14 createCallback(no) {
15 return (int received, _) {
16 progress[no] = received;
17 if (onReceiveProgress != null && total != 0) {
18 onReceiveProgress(progress.reduce((a, b) => a + b), total);
19 }
20 };
21 }
22
23 Future<Response> downloadChunk(url, start, end, no) async {
24 progress.add(0);
25 --end;
26 return dio.download(
27 url,
28 savePath + "temp$no",
29 onReceiveProgress: createCallback(no),
30 options: Options(
31 headers: {"range": "bytes=$start-$end"},
32 ),
33 );
34 }
35
36 Future mergeTempFiles(chunk) async {
37 File f = File(savePath + "temp0");
38 IOSink ioSink= f.openWrite(mode: FileMode.writeOnlyAppend);
39 for (int i = 1; i < chunk; ++i) {
40 File _f = File(savePath + "temp$i");
41 await ioSink.addStream(_f.openRead());
42 await _f.delete();
43 }
44 await ioSink.close();
45 await f.rename(savePath);
46 }
47
48 Response response = await downloadChunk(url, 0, firstChunkSize, 0);
49 if (response.statusCode == 206) {
50 total = int.parse(
51 response.headers.value(HttpHeaders.contentRangeHeader).split("/").last);
52 int reserved = total -
53 int.parse(response.headers.value(HttpHeaders.contentLengthHeader));
54 int chunk = (reserved / firstChunkSize).ceil() + 1;
55 if (chunk > 1) {
56 int chunkSize = firstChunkSize;
57 if (chunk > maxChunk + 1) {
58 chunk = maxChunk + 1;
59 chunkSize = (reserved / maxChunk).ceil();
60 }
61 var futures = <Future>[];
62 for (int i = 0; i < maxChunk; ++i) {
63 int start = firstChunkSize + i * chunkSize;
64 futures.add(downloadChunk(url, start, start + chunkSize, i + 1));
65 }
66 await Future.wait(futures);
67 }
68 await mergeTempFiles(chunk);
69 }
70}现在可以进行分块下载了：
1main() async {
2 var url = "http://download.dcloud.net.cn/HBuilder.9.0.2.macosx_64.dmg";
3 var savePath = "./example/HBuilder.9.0.2.macosx_64.dmg";
4 await downloadWithChunks(url, savePath, onReceiveProgress: (received, total) {
5 if (total != -1) {
6 print("${(received / total * 100).floor()}%");
7 }
8 });
9}思考
分块下载真的能提高下载速度吗？
其实下载速度的主要瓶颈是取决于网络速度和服务器的出口速度，如果是同一个数据源，分块下载的意义并不大，因为服务器是同一个，出口速度确定的，主要取决于网速，而上面的例子正式同源分块下载，读者可以自己对比一下分块和不分块的的下载速度。如果有多个下载源，并且每个下载源的出口带宽都是有限制的，这时分块下载可能会更快一下，之所以说“可能”，是由于这并不是一定的，比如有三个源，三个源的出口带宽都为1G/s，而我们设备所连网络的峰值假设只有800M/s，那么瓶颈就在我们的网络。即使我们设备的带宽大于任意一个源，下载速度依然不一定就比单源单线下载快，试想一下，假设有两个源A和B，速度A源是B源的3倍，如果采用分块下载，两个源各下载一半的话，读者可以算一下所需的下载时间，然后再算一下只从A源下载所需的时间，看看哪个更快。
分块下载的最终速度受设备所在网络带宽、源出口速度、每个块大小、以及分块的数量等诸多因素影响，实际过程中很难保证速度最优。在实际开发中，读者可可以先测试对比后再决定是否使用。
分块下载有什么实际的用处吗？
分块下载还有一个比较使用的场景是断点续传，可以将文件分为若干个块，然后维护一个下载状态文件用以记录每一个块的状态，这样即使在网络中断后，也可以恢复中断前的状态，具体实现读者可以自己尝试一下，还是有一些细节需要特别注意的，比如分块大小多少合适？下载到一半的块如何处理？要不要维护一个任务队列？