前言
本文是關于使用flutter_download_manager下載功能的實踐和探索，我們將基于flutter_download_manager的功能擴展，改造成自己想要的樣子，在閱讀本文之前，建議先了解前兩篇文章：
- Flutter 下載篇 - 壹 | flutter_download_manager原始碼決議
- Flutter 下載篇 - 貳 | 當下載器遇上網路庫切換
本文將基于第二篇中的擴展框架，將網路庫從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 =https://www.cnblogs.com/xuge2it/archive/2023/03/04/= 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下載功能的實用資訊和思考，
太棒了!鼓勵自己堅持到底，我希望我為你投入的時間增加了一些價值，
如果覺得文章對你有幫助，點贊、收藏、關注、評論，一鍵四連支持，你的支持就是我創作最大的動力，
??本文由公眾號編程黑板報 原創，關注我，獲取我的最新文章~??
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/545820.html
標籤：其他