感觉FileDownloadListener的回调很慢啊

[xanaduo]

当网速不好的时候（下载多个任务时），按钮半天没有反应，没有修改状态。

[Jacksgong]

FileDownloadListener的部分回调是和网络情况有关系的。

I. started与connected之间的回调也是网络相关的

比如回调完 started 以后，就开始建立链接，如果网络较差始终没有建立上连接，connected就会始终没有回调，不过到最后如果连接上了，肯定就会立马回调connected，如果超时了就会回调error。

II. progress之间的回调是和网速有关:

FileDownloader中控制 progress的回调频率是通过:

1. BaseDownloadTask#setCallbackProgressTimes

这个是控制下载全程 progress回调的最大次数("最大次数"的原因是，比如文件就只有4096byte大小，那么无论设置多大，假如一次从输入流取出就达到4096byte，那么也只有一次回调)。

比如100次(这个是默认值)，要下载的文件是100M，那么也就是每1M回调一次，如果网速太慢，回调的速度也会较慢。因为要下载完1M才回调一次。(当然如果设置为1000，那么就每100KB就回调一次)。

2. BaseDownloadTask#setCallbackProgressMinInterval

这个是控制两次progress回调最小间距(单位: ms)。

在保证下载全程 progress回调的最大次数的前提下，如果回调的间隔小于这里定义的最小间隔，就会忽略该次回调。

当然如果只关注完成而不关注进程，也可以通过 BaseDownloadTask#setCallbackProgressIgnored 让所有的 progress都不进行回调，来保证更好的性能。

[Jacksgong]

当然，对于回调的频率，FileDownloader还做了一些防止回调过于频繁导致UI线程被DDOS的情况: 也可以通过 FileDownloader#disableAvoidDropFrame将该功能关闭，以及通过FileDownloader#setGlobalHandleSubPackageSize控制分包大小，通过FileDownloader#setGlobalPost2UIInterval设置分包间隔。

---

特别值得一提的是，在网速较快，并且流媒体每次输入流取出的buffer都较小的情况下，虽然内部有做了一定的保护，但是建议上层通过BaseDownloadTask#setCallbackProgressMinInterval设置回调间隔，避免消息流堆栈过大，导致很多操作响应延后的问题（如：消息流中存在1000个progress的消息需要递交FileDownloadListener，由于开启了避免UI线程DDOS，每次分包5个，分包间隔10ms，那么要2s才消耗完这1000个消息，这时候调用了暂停，由于暂停的消息在堆栈最后，因此2s后才会被回调到，导致延时。此时如果是设置了progress回调间隔，就能够有效排除无效的progress回调(如UI一帧是16ms，那么如果16ms内出现多次progress回调对于UI来说是冗余的)）。

[Jacksgong]

如果你是因为消息流没有及时回调，这个是由于消息流太多。你可以通过 FileDownloader#disableAvoidDropFrame 进行关闭防止 DDOS，进行快速解决

---

如果你是这个问题: 消息流中存在1000个progress的消息需要递交FileDownloadListener，由于开启了避免UI线程DDOS，每次分包5个，分包间隔10ms，那么要2s才消耗完这1000个消息，这时候调用了暂停，由于暂停的消息在堆栈最后，因此2s后才会被回调到，导致延时。

解决根本问题:

通过 BaseDownloadTask#setCallbackProgressMinInterval 与BaseDownloadTask#setCallbackProgressTimes 来降低 每个任务的回调频次，如果不关注 每个任务自己的进度，甚至可以通过 BaseDownloadTask#setCallbackProgressIgnored 来关闭每个任务自己的 progress回调。

[xanaduo]

嗯，试试吧。

[Jacksgong]

@xanaduo 情况如何？

[xanaduo]

还可以吧，觉得我写的还是不够好。在优化中

[Jacksgong]

好的。

[Jacksgong]

我先关闭了，该Issue还有任何疑惑，随时重新打开。