关于flutter:Flutter-下载篇-叁-网络库切换实践与思考

前言

本文是对于应用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 == 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下载性能的实用信息和思考。

太棒了!激励本人坚持到底。我心愿我为你投入的工夫减少了一些价值。
如果感觉文章对你有帮忙，点赞、珍藏、关注、评论，一键四连反对，你的反对就是我创作最大的能源。
❤️本文由公众号编程黑板报 原创，关注我，获取我的最新文章~❤️