需求背景

继上篇《Flutter 下载篇 - 壹 | flutter_download_manager 源码解析》中详细介绍了 flutter_download_manager 用法和原理。在优缺点中提到，该库纯 Dart 实现，支持下载管理，暂停，恢复，取消和断点续传。其中有个缺点是网络库与 dio 强耦合，不支持自定义网络库扩展。

有人会说: dio 这么牛逼，直接用不就好了，为啥还要支持别的网络库，没事别瞎折腾。

我想说：

世界不只有一种声音，那不然多无趣。
第三方库对应用本身来说是黑盒，开发者一般疏于关注其功能改动对应用影响除非产生重大事故，这种不可控的情况应谨慎。
设计上遵循 DIP 原则，抽象不要依赖具体实现细节，具体细节依赖抽象，我们需要抽象网络层来给项目依赖而非直接依赖 dio。
快速切换到其他网路库。

本文将从现状出发，一步步带你解耦 flutter_download_manager 中的网络库。

现状说明

从类图上整体了解 flutter_download_manager 类设计过程中对 dio 强耦合概括，然后通过代码具体讲解。

类图体现

代码体现

耦合点一：dio.CancelToken

每个下载任务请求中都会使用到 dio:CancelToken 通过 dio 网络库间接实现任务的取消功能。

耦合点二：dio.download

cancelToken.cancel() 算依赖 CancelToken

如上简写代码中调用链关系，最终调用链及对 dio 依赖关系总结：

下载库对 dio 的依赖在于: CancelToken 和 download 方法。

如何定制网络库

通过上述对现状分析总结，结合设计基本原则：封装变化将不变从变化中隔离出来。其中变化的就是网络库的下载，CancelToken 和取消功能。只用封装这部分变化，将网络库下载和 Token 抽象出来进行封装。

1. 网络层设计

目的：让 flutter_download_manager 与 dio.download 解耦。

思路：将网络相关操作抽象成接口，依赖注入到 downloadManager 对象中。

实施步骤：

抽象网络层接口

考虑到 download 返回 Future 中对象问题，因为会用到 response.statusCode，这里直接用 dynamic 来，具体可以细化成封装成 DownloadResponse，其中包含 statusCode 属性。

customhttpclient 通过依赖注入传入 DownloadManager，让其不依赖具体实现而依赖抽象，依赖注入实现对象之间的组合关系提高扩展性。

2. CancelToken 设计

目的：让 flutter_download_manager 与 dio.CancelToken 解耦。

思路：CancelToken 与取消息息相关，而且必须提供一个 cancel 方法来供 downloadmanager 中暂停等方法使用。考虑到每个 custom_http_client 的 CancelToken 结构体存在不一样，而 cancel 方法命名多样性原则，这里设计一个统一的 DownloadCancelToken 接口，提供 cancel 方法，将其中实现代理给具体网络库的 CancelToken 对象。

实施步骤：