Skip to content
New issue

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

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

Already on GitHub? # to your account

从第一个progress到第二个progress间隔10s? #635

Closed
Jacksgong opened this issue Jun 29, 2017 · 8 comments
Closed

从第一个progress到第二个progress间隔10s? #635

Jacksgong opened this issue Jun 29, 2017 · 8 comments
Labels

Comments

@Jacksgong
Copy link
Collaborator

@tommyfeng 提出,如图:

qq 20170629190637

@Jacksgong
Copy link
Collaborator Author

@tommyfeng 我看到了,确实比较奇怪。

针对progress的间隔,可以先通过这里快速了解下: #246 (comment)


然后可否给下这个任务的: setCallbackProgressTimessetCallbackProgressMinInterval的值,如果没有,就说没有就行。我看看是哪里出问题。

@tommyfeng
Copy link

我是按照默认的设置的,并没有特别设置!只是修改了 process.non-separate=true

@tommyfeng
Copy link

同一个应用,下载视频会出现那种情况,但是下载图片是非常快的,不知道是啥情况!
qq 20170629193026

@Jacksgong
Copy link
Collaborator Author

Jacksgong commented Jun 29, 2017

Okay,我找到原因了:

  1. 这个是因为默认的progress回调次数是100次,因此每次必须下载: 总大小92204519Byte/100次回调 = 900kb 才能回调。
  2. 有些资源url服务器端配置或服务器端网络环境使得首次打开输入流取数据很慢导致

P.S. 如我在demo project的SingleTaskTestActivity中测试就不存在该问题:

image


推荐解决方案:

  1. 针对网络问题或者是某些url服务端方面的配置或服务端网络情况,可以联系后端同学让其解决
  2. 针对这类资源输入流从网络获取较慢的,建议将progress回调次数调高,保证用户那边有进度反馈,如设置总回调500次: setCallbackProgressTimes(500)

P.S. FileDownloader内部并没有对不同的资源做特殊的处理。

@tommyfeng
Copy link

嗯嗯,我测试看看!

@Jacksgong
Copy link
Collaborator Author

还有一点需要注意的是针对这类下载慢的,UI方面不应该采用100%来计数,而应该采用如按照文件长度来计数(或者是1000/1000、10000/10000这样来计数),这样每次回调回来的略微的进度才能在UI上体现出来。

@tommyfeng
Copy link

刚刚测试还是存在那样的问题。我已经设置setCallbackProgressTimes(500).网络方面应该是没有问题的,因为之前已经有一个demo用的是HttpURLConnection。下载速度在1.8M/S左右。没有出现断流的问题。明天我把链接试着放进demo project看看情况。
qq 20170629195203

@Jacksgong
Copy link
Collaborator Author

Jacksgong commented Jun 29, 2017

这应该就是某个连接后端服务器的问题。


这里也并非断流,而是1.5.8版本将第一个4096的progress返回了回来,之前的版本是不会将第一个4096返回回来的,而是等到满足回调次数与最小间隔才回调。这里确实是该连接资源在刚开始打开输入流时特别慢。


对于你说的你自己通过UrlConnection去写就没有这个问题,我估计是因为你只是觉得每次都有数据回来,但是并没有进行速度方面的对比,如果你配置25000个回调次数(这样每次取4096Byte并且距离上一次回调间隔10ms就回回调一次(FileDownloader中每次取的buffer是4096Byte,并非你看到的回调,回调只是对上层的封装)),这样每次都会有回调回来你也看不出是否是前面慢了。


当然也十分欢迎PR。不过你这个确实是特殊的后台服务器配置问题,FileDownloader并没有做特殊处理,连接器也是支持定制,默认的连接器也是采用UrlConnection(具体可以看这里)。

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

No branches or pull requests

2 participants