前言
本文是關於使用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下載功能的實用資訊和思考。
太棒了!鼓勵自己堅持到底。我希望我為你投入的時間增加了一些價值。
如果覺得文章對你有幫助,點贊、收藏、關注、評論,一鍵四連支援,你的支援就是我創作最大的動力。
❤️本文由公眾號程式設計黑板報 原創,關注我,獲取我的最新文章~❤️