Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

下载队列,偶现进度不回调,也不报错的情况 #628

Closed
chiemy opened this issue Jun 22, 2017 · 12 comments
Closed

下载队列,偶现进度不回调,也不报错的情况 #628

chiemy opened this issue Jun 22, 2017 · 12 comments
Labels

Comments

@chiemy
Copy link

chiemy commented Jun 22, 2017

下载队列,偶现下载到最后下载进度不动的情况,等了大概几分钟也没报任何错误,然后主动断网会回调 error 。重新联网后调用 reuseAndStart() 后会下载成功。

@Jacksgong
Copy link
Collaborator

Jacksgong commented Jun 22, 2017

这个是资源的问题或中间网络层问题,非FileDownloader的问题,有些资源本身就是很难下载。

为什么说是资源问题?

因为不是所有资源都会遇到该问题,而是有些资源原本服务器带宽低或者配置的问题,导致单个连接很慢。

为什么到最后的时候会有这个问题呢?

由于1.5.0之后版本的FileDownloader采用了分块下载,下载过程中由于是多连接下载,因此总和的速度显得比较合理。

但是到最后的时候,所有的连接都下载完成了,只剩下了一个连接下载时,原本资源单个连接下载慢的问题就凸显出来了。当然由于服务器端配置较低或者中间网络层路由配置问题,也有可能导致长时间获取输入流后速度变慢,这个非FileDownloader可以左右的。

进度也不回调?

回调是和网络速度有关系的,可以参考: 这里

为什么断网联网后又正常了?

如果是这种情况,有可能是路由器的问题,路由器的内存等硬件配置,以及决策会影响单个连接长时间获取输入流的速度。当断网重新连接以后,重新分配ip,重新建立新的连接,便可解决问题,该情况非FileDownloader可以左右。


这类问题是目前整个网络生态的问题,如果针对这种问题,有优化建议,十分欢迎提出以及PR。

@wanghaihui
Copy link

我也遇到这个问题了@Jacksgong

@Jacksgong
Copy link
Collaborator

@wanghaihui 在1.5.6版本中修复了一个无响应的问题:

修复(no-response): 修复在接收到connected回调之后,多线程下载建立连接,此时在检验连接与数据获取连接期间服务端数据发生错误或变更导致启动下载后没有响应的问题。

你看看是否与这个有关。

@wanghaihui
Copy link

@Jacksgong 好像不是,因为我们现在用的就是最新的1.5.7版本,这个问题的复现情况是这样的,下载完后,然后再清除APP缓存数据,然后再下载,会有几率复现,我们打了log,progress是100,但是最后会出现两次progress=99

@wanghaihui
Copy link

然后,完全进度就死在那了,没有任何回调

@Jacksgong
Copy link
Collaborator

这个问题参考下上面的回复

@Gongcong
Copy link

@Jacksgong 我也遇到这个问题,在把下载的内容删除后,重新下载,会有一定概率回调返回2次99,然后就卡住了。

@chiemy
Copy link
Author

chiemy commented Jun 29, 2017

@Jacksgong 我重新测试了下,以下是我测试的方法。
首先,我把所有资源都放到了局域网中,尽量排除第三方服务器的因素。
设置 FileDownloadQueueSet.downloadSequentially 测试了 7 次,全部顺利完成下载,
然后改为 downloadTogether 测试了 4 次,全部都卡在最后,所以怀疑是多线程下载的问题导致的

@Jacksgong
Copy link
Collaborator

Jacksgong commented Jun 29, 2017

@chiemy demo project 中MultitaskTestActivity中的并行下载也是采用downloadTogether都是进行下载的,800多个任务,我反复测试都是ok的,可否将你能够必现问题的简单案例项目推到远端给我或者发邮件给我(igzhenjie@gmail.com)吗?

@chiemy
Copy link
Author

chiemy commented Jun 29, 2017

@Jacksgong 好的,我有时间整理一下发给你
谢谢你的回复

@Jacksgong
Copy link
Collaborator

@chiemy 好的,谢谢了。


也十分欢迎PR。

@chiemy
Copy link
Author

chiemy commented Jun 30, 2017

@Jacksgong 我把你 demo 中的测试链接全部替换成了我自己的资源,确实没有复现出这个问题。我对比了下和 demo 的差异,发现在我的应用中初始化时并没有设置超时时间,然后我把 demo 设置超时时间的代码注释掉了,很容易就能复现出该问题。

如果不设置超时,没有默认值吗?

至于昨天我改为 downloadSequentially 成功率很高的问题,是不是因为这样网络连接更稳定一些?

测试截图

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants