一、背景简介
在项目中使用下载功能的地方有很多。在不同的业务中，开发人员需要根据不同的业务需要，构建各种组织结构的下载处理类。
为了更好的把下载功能和业务逻辑分离开，节省开发人员的时间，提高代码的效率，开发了一组通用的下载结点类。主要实现文件的下载、文件的层级关系的搭建、下载情况的实时反馈、下载异常问题的分析等功能。
使用该类库，可以在实际应用中快速的搭建起一定组织结构的下载处理逻辑。且开发人员不需要关注下载的具体处理细节。只需要定义自己的业务实体，作为业务参数交给通用下载模块即可，当下载进度发生变化，或者出现问题时，所有的事件参数中都会包含用户传入的业务数据信息，方便开发人员进行业务处理。
二、应用场景举例
在某项目的业务中，用户可能需要从服务端更新一种每周推送的内容服务。这种内容的组织是按照周刊->资源->资源文件的层级关系组织的。
在终端软件的逻辑中，需要知道每个资源文件的下载情况，从而分析资源的下载状况，再进而知道周刊的下载情况。如下图:
（一个资源由2个文件组成）
（一个周刊由2个资源构成）
三、设计思路
下面简单说一下它的构思:
在不同业务需求场景中，实现文件的下载，特别是文件按照不同的逻辑关系组织在一起的下载功能时，往往需要为每一种业务定制一套下载处理类，来完成文件的下载和UI的通知更新等。这样做有几个缺点：
a)代码不易维护，业务逻辑与下载任务混杂在一起
b)代码可重用性低，业务逻辑改变，导致强耦合的下载功能类需要改变
------------------------------------------------------------------------------------------------------
考虑设计一种结点类，类似于咱们小时候玩的积木，这些积木大致可以分为2类：
A类积木：积木上有插口，可以插入其他的积木(当然包括A类积木自己)
B类积木：只能插在A类积木上。
对应到常见的下载任务，我们可以把下载任务归为以下2种：
1、负责具体下载事务的结点，我给他们起名为：“叶子结点”，他们的特点是：
a)只存在于下载任务树的最底层
b)一个结点负责一个实体文件的下载，并且向上汇报进度
2、负责管理若干个结点的“管理型结点”，我给他们起名叫做“关联结点”，他们的特点是：
a)不负责具体文件的下载
b)可以将其他结点插入其下，受其管理和控制
c)可以实时收集子结点的状态，也向上汇报自己的进度
四、小结
本篇主要介绍了做这个东西的初衷和想法形成的过程。后面将继续介绍这个东西。有兴趣的朋友可以留言提出自己的意见，谢谢~