Filedownloader: 为什么下载的时候从pending 到 progress 中间要很长时间

Created on 29 Jun 2017  ·  17Comments  ·  Source: lingochamp/FileDownloader

单任务下载的时候,开始一个新的下载任务,执行start() 后要很长时间才会开始下载。

question

All 17 comments

除连上面那个评论提到的,还需要特别注意:如果是分块下载,从connectedprogress的过程:

  1. 首次建连结束后会回调connected
  2. 但是由于是分块下载,因此每个块会单独建立新的连接,这块也会耗时。
  3. 根据网络状况,当任意块有数据反馈时,并满足进度回调设定时,此时会回调progress

P.S. 如果不希望分块下载(直接一个连接开始获取数据),可以通过ConnectionCountAdapter返回连接数为1即可。


目前默认的分块策略 ( 具体可参考: DefaultConnectionCountAdapter )

无分块: file length [0, 1MB)
分两块: file length [1MB, 5MB)
分三块: file length [5MB, 50MB)
分四块: file length [50MB, 100MB)
分五块: file length [100MB, -)

@Jacksgong 您好,我也碰到了这个问题,从回调pending 到 回调progress,中间大概间隔了10秒钟。这个时间感觉太久了啊!能有什么办法可以缩短间隔时间吗? 谢谢!

@tommyfeng 如果是由于FileDownloader本身原因是可以的:

  1. filedownloader.properties中配置process.non-separate=true,让下载服务运行在主进程保证首次请求下载时无需创建一个新的进程。
  2. 可以通过ConnectionCountAdapter返回连接数为1,这样就在connected之后立马复用该连接进行下载,无需再重新建立新的连接给每个分块用。(估计是这一个原因导致你感觉pending到第一个progress慢的)

详细

由于从pendingprogress中间其实还有startedconnected的回调。

  1. 如果你的耗时点是在startedconnected,这个我们是无能为力的,因为这个是网络环境以及所下载资源的服务器网络环境导致的;
  2. 如果你的耗时点实在connected到第一个progress,这个是由于分块下载,需要为每个块重新建立独立的连接,这里你通过ConnectionCountAdapter返回1,这样就不会启用分块下载,就会复用connected这个连接的连接;但是如果原本就不是分块下载,这个依然很久,那应该网络环境导致首次取buffer速度很慢导致的。

P.S. 一般的连接超时是在10s-15s,如果你由于业务需求不能接受,可以对这个超时进行定制:

FileDownloader.setupOnApplicationOnCreate(this)
        .connectionCreator(new FileDownloadUrlConnection
                .Creator(new FileDownloadUrlConnection.Configuration()
                .connectTimeout(5000) // 设置为5s
                .readTimeout(8000) // 设置为8s
        )).commit();

@Jacksgong 谢谢你的回复! 这是我的Log信息。版本是1.3.0
qq 20170629181326
但是升级到1.5.8时,打印信息是这样的
qq 20170629180552
我不清楚这个是否是Filedownloader本身的原因。

@tommyfeng 1.5.0之后支持了分块下载,也就是上面提到的第二点原因。

@Jacksgong 谢谢回复!,通过ConnectionCountAdapter返回1 这个是要如何操作。我没看懂。。。

@tommyfeng 参考下这里: https://github.com/lingochamp/FileDownloader/wiki/Customizable-Component

如果还不明白,具体是这样:

1. 实现你自己的ConnectionCountAdapter:

public class MyConnectionCountAdapter implements FileDownloadHelper.ConnectionCountAdapter {

    @Override
    public int determineConnectionCount(int downloadId, String url, String path, long totalLength) {
        return 1;
    }
}

2. 在Application#onCreate中调用FileDownloader.setupOnApplicationOnCreate注册进去:

FileDownloader.setupOnApplicationOnCreate(this)
        .connectionCountAdapter(new MyConnectionCountAdapter())
        .commit();

是像这样的吗?
qq 20170629190025

参考我上面给你的评论: https://github.com/lingochamp/FileDownloader/issues/633#issuecomment-311933698


P.S. 你这样也可以,不过init已经被弃用的,建议还是使用FileDownloader.setupOnApplicationOnCreate

嗯嗯,刚刚我试过了,好像还是会间隔十秒
qq 20170629190637

image
诶,不对啊,你这个说的不是标题的问题,不是pending到progress的耗时,你第一个progress回调,间隔是2s。。。。。。。。。。。。

刚刚1.3.0是这个问题,后面升级到1.5.8就是第一个progress回调和第二个相差时间很长。。。

ok,那么首先你不用修改分块下载这块了。


对与这个问题。咱们重新提一个Issue讨论: #635

就是说第一个progress的回调和第二个progress的回调之间貌似会相隔大概7秒的时间。给人感觉像是卡住了一样,但是实际上,网速是没有问题的。不知道这个问题出在哪里!

@tommyfeng 如果用的是OKHTTP的话,看看是不是开启了OKHTTP的日志。并且级别是BODY的。

下载一会后,直接不回调progress, 如果暂停 在 重新开始的话, 有时会pending connection progress.
有时会 直接卡在pending, 不走任何回调,这种情况不管怎么暂停,重新下载 都会一直卡在pending.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

seransaca picture seransaca  ·  5Comments

chriswiesner picture chriswiesner  ·  4Comments

mzpbvsig picture mzpbvsig  ·  6Comments

itsmallsun picture itsmallsun  ·  4Comments

vd92 picture vd92  ·  3Comments