-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Comments
@tommyfeng 我看到了,确实比较奇怪。 针对progress的间隔,可以先通过这里快速了解下: #246 (comment) 然后可否给下这个任务的: |
我是按照默认的设置的,并没有特别设置!只是修改了 process.non-separate=true |
Okay,我找到原因了:
P.S. 如我在demo project的SingleTaskTestActivity中测试就不存在该问题: 推荐解决方案:
P.S. FileDownloader内部并没有对不同的资源做特殊的处理。 |
嗯嗯,我测试看看! |
还有一点需要注意的是针对这类下载慢的,UI方面不应该采用100%来计数,而应该采用如按照文件长度来计数(或者是1000/1000、10000/10000这样来计数),这样每次回调回来的略微的进度才能在UI上体现出来。 |
这应该就是某个连接后端服务器的问题。 这里也并非断流,而是1.5.8版本将第一个4096的progress返回了回来,之前的版本是不会将第一个4096返回回来的,而是等到满足回调次数与最小间隔才回调。这里确实是该连接资源在刚开始打开输入流时特别慢。 对于你说的你自己通过UrlConnection去写就没有这个问题,我估计是因为你只是觉得每次都有数据回来,但是并没有进行速度方面的对比,如果你配置25000个回调次数(这样每次取4096Byte并且距离上一次回调间隔10ms就回回调一次(FileDownloader中每次取的buffer是4096Byte,并非你看到的回调,回调只是对上层的封装)),这样每次都会有回调回来你也看不出是否是前面慢了。 当然也十分欢迎PR。不过你这个确实是特殊的后台服务器配置问题,FileDownloader并没有做特殊处理,连接器也是支持定制,默认的连接器也是采用UrlConnection(具体可以看这里)。 |
由 @tommyfeng 提出,如图:
The text was updated successfully, but these errors were encountered: