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

32次阅读

共计 3800 个字符,预计需要花费 10 分钟才能阅读完成。

前言

本文是对于应用 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。如果屡次暂停、勾销,而后再复原下载,会呈现进度起始地位谬误的问题。下载会从已下载文件的长度开始,成果如下所示:

<p align=center><img src=”https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7cf94ec2b45348b3b0ceee9aeeacdc0d~tplv-k3u1fbpfcp-watermark.image?” alt=”221539959-e5af41bc-b3b1-41cc-9a46-1ba549c4fd86.gif” width=”40%” /></p>

问题起因

在暂停时,暂停前未将下载流写入已下载的文件中。

解决办法

如果用户点击了暂停,会抛出勾销异样,此时捕捉该异样并判断以后下载工作状态是暂停态,将已下载的数据流写入未下载齐全的文件中。

已提交 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 下载性能的实用信息和思考。

太棒了! 激励本人坚持到底。我心愿我为你投入的工夫减少了一些价值。

如果感觉文章对你有帮忙,点赞、珍藏、关注、评论,一键四连反对,你的反对就是我创作最大的能源。

❤️本文由公众号 编程黑板报 原创,关注我,获取我的最新文章~❤️

正文完
 0