W3Cschool
恭喜您成為首批注冊(cè)用戶
獲得88經(jīng)驗(yàn)值獎(jiǎng)勵(lì)
本節(jié)將通過一個(gè)“Http分塊下載”的示例演示一下 dio 的具體用法。
Http 協(xié)議定義了分塊傳輸?shù)捻憫?yīng) header 字段,但具體是否支持取決于 Server 的實(shí)現(xiàn),我們可以指定請(qǐng)求頭的"range"字段來驗(yàn)證服務(wù)器是否支持分塊傳輸。例如,我們可以利用 curl 命令來驗(yàn)證:
bogon:~ duwen$ curl -H "Range: bytes=0-10" http://download.dcloud.net.cn/HBuilder.9.0.2.macosx_64.dmg -v
## 請(qǐng)求頭
> GET /HBuilder.9.0.2.macosx_64.dmg HTTP/1.1
> Host: download.dcloud.net.cn
> User-Agent: curl/7.54.0
> Accept: */*
> Range: bytes=0-10
## 響應(yīng)頭
< HTTP/1.1 206 Partial Content
< Content-Type: application/octet-stream
< Content-Length: 11
< Connection: keep-alive
< Date: Thu, 21 Feb 2019 06:25:15 GMT
< Content-Range: bytes 0-10/233295878
我們?cè)谡?qǐng)求頭中添加"Range: bytes=0-10"的作用是,告訴服務(wù)器本次請(qǐng)求我們只想獲取文件0-10(包括10,共11字節(jié))這塊內(nèi)容。如果服務(wù)器支持分塊傳輸,則響應(yīng)狀態(tài)碼為206,表示“部分內(nèi)容”,并且同時(shí)響應(yīng)頭中包含“Content-Range”字段,如果不支持則不會(huì)包含。我們看看上面“Content-Range”的內(nèi)容:
Content-Range: bytes 0-10/233295878
0-10表示本次返回的區(qū)塊,233295878 代表文件的總長(zhǎng)度,單位都是 byte, 也就是該文件大概233M多一點(diǎn)。
基于此,我們可以設(shè)計(jì)一個(gè)簡(jiǎn)單的多線程的文件分塊下載器,實(shí)現(xiàn)的思路是:
下面是整體的流程:
// 通過第一個(gè)分塊請(qǐng)求檢測(cè)服務(wù)器是否支持分塊傳輸
Response response = await downloadChunk(url, 0, firstChunkSize, 0);
if (response.statusCode == 206) { //如果支持
//解析文件總長(zhǎng)度,進(jìn)而算出剩余長(zhǎng)度
total = int.parse(
response.headers.value(HttpHeaders.contentRangeHeader).split("/").last);
int reserved = total -
int.parse(response.headers.value(HttpHeaders.contentLengthHeader));
//文件的總塊數(shù)(包括第一塊)
int chunk = (reserved / firstChunkSize).ceil() + 1;
if (chunk > 1) {
int chunkSize = firstChunkSize;
if (chunk > maxChunk + 1) {
chunk = maxChunk + 1;
chunkSize = (reserved / maxChunk).ceil();
}
var futures = <Future>[];
for (int i = 0; i < maxChunk; ++i) {
int start = firstChunkSize + i * chunkSize;
//分塊下載剩余文件
futures.add(downloadChunk(url, start, start + chunkSize, i + 1));
}
//等待所有分塊全部下載完成
await Future.wait(futures);
}
//合并文件文件
await mergeTempFiles(chunk);
}
下面我們使用 dio 的download
API 實(shí)現(xiàn)downloadChunk
:
//start 代表當(dāng)前塊的起始位置,end代表結(jié)束位置
//no 代表當(dāng)前是第幾塊
Future<Response> downloadChunk(url, start, end, no) async {
progress.add(0); //progress記錄每一塊已接收數(shù)據(jù)的長(zhǎng)度
--end;
return dio.download(
url,
savePath + "temp$no", //臨時(shí)文件按照塊的序號(hào)命名,方便最后合并
onReceiveProgress: createCallback(no), // 創(chuàng)建進(jìn)度回調(diào),后面實(shí)現(xiàn)
options: Options(
headers: {"range": "bytes=$start-$end"}, //指定請(qǐng)求的內(nèi)容區(qū)間
),
);
}
接下來實(shí)現(xiàn)mergeTempFiles
:
Future mergeTempFiles(chunk) async {
File f = File(savePath + "temp0");
IOSink ioSink= f.openWrite(mode: FileMode.writeOnlyAppend);
//合并臨時(shí)文件
for (int i = 1; i < chunk; ++i) {
File _f = File(savePath + "temp$i");
await ioSink.addStream(_f.openRead());
await _f.delete(); //刪除臨時(shí)文件
}
await ioSink.close();
await f.rename(savePath); //合并后的文件重命名為真正的名稱
}
下面我們看一下完整實(shí)現(xiàn):
/// Downloading by spiting as file in chunks
Future downloadWithChunks(
url,
savePath, {
ProgressCallback onReceiveProgress,
}) async {
const firstChunkSize = 102;
const maxChunk = 3;
int total = 0;
var dio = Dio();
var progress = <int>[];
createCallback(no) {
return (int received, _) {
progress[no] = received;
if (onReceiveProgress != null && total != 0) {
onReceiveProgress(progress.reduce((a, b) => a + b), total);
}
};
}
Future<Response> downloadChunk(url, start, end, no) async {
progress.add(0);
--end;
return dio.download(
url,
savePath + "temp$no",
onReceiveProgress: createCallback(no),
options: Options(
headers: {"range": "bytes=$start-$end"},
),
);
}
Future mergeTempFiles(chunk) async {
File f = File(savePath + "temp0");
IOSink ioSink= f.openWrite(mode: FileMode.writeOnlyAppend);
for (int i = 1; i < chunk; ++i) {
File _f = File(savePath + "temp$i");
await ioSink.addStream(_f.openRead());
await _f.delete();
}
await ioSink.close();
await f.rename(savePath);
}
Response response = await downloadChunk(url, 0, firstChunkSize, 0);
if (response.statusCode == 206) {
total = int.parse(
response.headers.value(HttpHeaders.contentRangeHeader).split("/").last);
int reserved = total -
int.parse(response.headers.value(HttpHeaders.contentLengthHeader));
int chunk = (reserved / firstChunkSize).ceil() + 1;
if (chunk > 1) {
int chunkSize = firstChunkSize;
if (chunk > maxChunk + 1) {
chunk = maxChunk + 1;
chunkSize = (reserved / maxChunk).ceil();
}
var futures = <Future>[];
for (int i = 0; i < maxChunk; ++i) {
int start = firstChunkSize + i * chunkSize;
futures.add(downloadChunk(url, start, start + chunkSize, i + 1));
}
await Future.wait(futures);
}
await mergeTempFiles(chunk);
}
}
現(xiàn)在可以進(jìn)行分塊下載了:
main() async {
var url = "http://download.dcloud.net.cn/HBuilder.9.0.2.macosx_64.dmg";
var savePath = "./example/HBuilder.9.0.2.macosx_64.dmg";
await downloadWithChunks(url, savePath, onReceiveProgress: (received, total) {
if (total != -1) {
print("${(received / total * 100).floor()}%");
}
});
}
其實(shí)下載速度的主要瓶頸是取決于網(wǎng)絡(luò)速度和服務(wù)器的出口速度,如果是同一個(gè)數(shù)據(jù)源,分塊下載的意義并不大,因?yàn)榉?wù)器是同一個(gè),出口速度確定的,主要取決于網(wǎng)速,而上面的例子正式同源分塊下載,讀者可以自己對(duì)比一下分塊和不分塊的的下載速度。如果有多個(gè)下載源,并且每個(gè)下載源的出口帶寬都是有限制的,這時(shí)分塊下載可能會(huì)更快一下,之所以說“可能”,是由于這并不是一定的,比如有三個(gè)源,三個(gè)源的出口帶寬都為 1G/s,而我們?cè)O(shè)備所連網(wǎng)絡(luò)的峰值假設(shè)只有 800M/s,那么瓶頸就在我們的網(wǎng)絡(luò)。即使我們?cè)O(shè)備的帶寬大于任意一個(gè)源,下載速度依然不一定就比單源單線下載快,試想一下,假設(shè)有兩個(gè)源 A 和 B,速度 A 源是 B 源的3倍,如果采用分塊下載,兩個(gè)源各下載一半的話,讀者可以算一下所需的下載時(shí)間,然后再算一下只從 A 源下載所需的時(shí)間,看看哪個(gè)更快。
分塊下載的最終速度受設(shè)備所在網(wǎng)絡(luò)帶寬、源出口速度、每個(gè)塊大小、以及分塊的數(shù)量等諸多因素影響,實(shí)際過程中很難保證速度最優(yōu)。在實(shí)際開發(fā)中,讀者可可以先測(cè)試對(duì)比后再?zèng)Q定是否使用。
分塊下載還有一個(gè)比較使用的場(chǎng)景是斷點(diǎn)續(xù)傳,可以將文件分為若干個(gè)塊,然后維護(hù)一個(gè)下載狀態(tài)文件用以記錄每一個(gè)塊的狀態(tài),這樣即使在網(wǎng)絡(luò)中斷后,也可以恢復(fù)中斷前的狀態(tài),具體實(shí)現(xiàn)讀者可以自己嘗試一下,還是有一些細(xì)節(jié)需要特別注意的,比如分塊大小多少合適?下載到一半的塊如何處理?要不要維護(hù)一個(gè)任務(wù)隊(duì)列?
Copyright©2021 w3cschool編程獅|閩ICP備15016281號(hào)-3|閩公網(wǎng)安備35020302033924號(hào)
違法和不良信息舉報(bào)電話:173-0602-2364|舉報(bào)郵箱:jubao@eeedong.com
掃描二維碼
下載編程獅App
編程獅公眾號(hào)
聯(lián)系方式:
更多建議: