前言 本文是關於使用flutter_download_manager下載功能的實踐和探索。我們將基於flutter_download_manager的功能擴展，改造成自己想要的樣子。在閱讀本文之前，建議先瞭解前兩篇文章： Flutter 下載篇 - 壹 | flutter_download_mana ...
前言
本文是關於使用flutter_download_manager下載功能的實踐和探索。我們將基於flutter_download_manager的功能擴展，改造成自己想要的樣子。在閱讀本文之前，建議先瞭解前兩篇文章：
本文將基於第二篇中的擴展框架，將網路庫從dio切換為httpclient，並結合改造過程中發現的問題提出自己的想法。
優化點：dynamic的告警問題
在第2和20行中，黃色標記表明，如果第2行中的每個網路庫下載的返回值可能不同，則考慮將其設置為“dynamic”，這可能導致第20行中出現響應狀態碼的告警，因為該屬性可能不存在。
為了確保 download 介面的返回值具有 statusCode 屬性，在這裡定義了一個專門的返回類以進行限制。具體定義如下：
這樣就解決了statusCode告警問題，其中extra可以存放原始download response對象。
HttpClient實現網路庫
只用實現上一篇中的網路介面CustomHttpClient，然後修改IDownloader:createObject其中網路註入對象即可，如下：
//實現這個介面定義
abstract class CustomHttpClient {
Future<DownloadHttpResponse> download(
String urlPath,
String savePath, {
DownloadProgressCallback? onReceiveProgress,
DownloadCancelToken? cancelToken,
Map<String, dynamic>? options,
});
DownloadCancelToken generateToken();
}
------【idownloader.dart】----------
abstract class IDownloader {
factory IDownloader() => createObject(
//將這個註入修改成我們實現的即可 原來：customHttpClient: CustomDioImpl(),
customHttpClient: CustomHttpClientImp(),
);
}
實現代碼：
- 第9-17行：主要是將flutter_download_manager中已下載但未下載完整的文件大小傳遞給後端，以便告知後端從哪裡繼續下載文件。
如果不傳，會浪費帶寬和時間。在處理大文件時，記憶體壓力會增大，中斷的可能性也會增加。此外，用戶界面可能會出現進度條跳躍的問題。
- 第27-45行：將下載流寫入傳入的 savepath 文件中。需要註意
cancelToken.isCancelled方法，因為上一篇中沒有定義isCancelled屬性，這裡必須在DownloadCancelToken中提供該方法（第69行）。 - 第55-65行：這裡實現了HttpClientCancelToken的cancel方法，具體實現就是給標誌位_isCancelled賦值。
遇到官方問題
完成上述實踐後，發現官方進度錯誤BUG。如果多次暫停、取消，然後再恢復下載，會出現進度起始位置錯誤的問題。下載會從已下載文件的長度開始，效果如下所示：
問題原因
在暫停時，暫停前未將下載流寫入已下載的文件中。
解決辦法
如果用戶點擊了暫停，會拋出取消異常，此時捕獲該異常並判斷當前下載任務狀態是暫停態，將已下載的數據流寫入未下載完全的文件中。
已提交PR到官方庫中，見PR地址。
完整代碼傳送門，其中包含了httpclient實現和上述官方進度問題修複方案。
回顧網路庫解耦
在切換flutter_download_manager網路庫時，我們發現解耦方案仍然存在問題。
1. isCanceled
在httpclient中使用了isCancelled方法，不得不將其加入DownloadCancelToken中，這在設計上是有問題的。
我查看了dio的download過程，發現其中也存在對取消狀態的判斷。dio.CancelToken類中也定義了這個方法，那麼為什麼我沒有考慮到呢？原因是我沒有實踐過，當時只是用downloadTokenProxy去代理了CancelToken，它可以跑，就認為設計沒有問題。果然，自己挖的坑需要自己踩一遍才能真正理解其中的問題。
2. flutter_download_manager框架運行約束
為了讓該庫正常運行，必須與相關的網路庫配合使用。
在我使用httpclient進行實現過程中，我發現如果取消操作，必須拋出一個異常（請參考代碼中第32行），才能確保程式能夠順利地執行case1而不出現官方文檔中提到的問題。
Future<void> download(
String url, String savePath, DownloadCancelToken cancelToken,
{forceDownload = false}) async {
late String partialFilePath;
late File partialFile;
try {
var task = getDownload(url);
var response = await customHttpClient.download(...);
} else {
var response = await customHttpClient.download(...
);
}
} catch (e) {
var task = getDownload(url)!;
if (task.status.value != DownloadStatus.canceled &&
//...
} else if (task.status.value == DownloadStatus.paused) {
// 只有拋出取消異常才能走到保持下載流到未下載完全文件中 case1
final ioSink = partialFile.openWrite(mode: FileMode.writeOnlyAppend);
final f = File(partialFilePath + tempExtension);
final fileExist = await f.exists();
if (fileExist) {
await ioSink.addStream(f.openRead());
await f.delete();
}
await ioSink.close();
}
}
約束一：如果需要取消任務，應該拋出取消異常。
因為flutter_download_manager一開始網路庫就是綁定的dio，而dio中對取消操作的結果反饋就是取消異常。如果用戶取消了任何一個請求，就會拋出該異常。
話說，取消發送一條消息難道非得拋出異常才可以嗎？其實有很多方法可以實現這個功能。
約束二：請提供下載請求的返回碼。
由於flutter_download_manager已經處理了返回碼206和200，如果不提供網路請求返回碼，相關邏輯無法執行。
話說，請求成功返回結果的方式也可以是發消息吧。
下載框架設計思路
如果將flutter_download_manager作為代碼片段使用是沒有問題的，但從下載框架設計的角度來看，仍需要進一步改進和優化。
出現上述提到的約束問題，主要是將關係集中在DownloadManager和網路庫上，陷入網路細節中。實際上，這兩者沒有直接關係，主要是flutter_download_manager作者將它們耦合在一起導致的。
從下載框架角度說，類之間依賴關係應該如下：
DownloadManager依賴下載器，下載器依賴網路庫。
三者間交互關係如下：
- DownloadManager 通過維護列表來管理內部任務的增刪改查。每個任務對應一個下載過程。
- Downloader 負責任務下載，並通過同步或非同步消息通知當前下載任務的狀態。DownloadManger 通過這些消息來更新任務列表。
- Downloader 通過向網路庫發送請求來下載任務。網路將結果返回給 Downloader，由 Downloader 來決定內部狀態和斷點續傳邏輯。
總結
本文介紹了Flutter下載功能的實踐和探索，包括網路庫的切換和優化。使用了httpclient實現網路庫，並解決了官方進度錯誤BUG。還回顧了flutter_download_manager的設計缺陷，並提出了下載框架的設計思路。總之，提供了有關Flutter下載功能的實用信息和思考。
太棒了!鼓勵自己堅持到底。我希望我為你投入的時間增加了一些價值。
如果覺得文章對你有幫助，點贊、收藏、關註、評論，一鍵四連支持，你的支持就是我創作最大的動力。
❤️本文由公眾號編程黑板報 原創，關註我，獲取我的最新文章~❤️
