Retrofit2的再封装实战—多线程下载与断点续传(三)

前面两篇文章我们讲了项目整体的设计结构、入口类DownloadManager、下载类DownloadTask,这篇文章我们讲最重要的类DownLoadRequest。
由于离前两篇文章时间比较长了,感觉陌生的同学可以先回顾一下:
Retrofit2的再封装实战—多线程下载与断点续传(一)
Retrofit2的再封装实战—多线程下载与断点续传(二)

流程图


回忆之前文章提到的,我们将需要下载的任务构造成一个List传入DownLoadManager中,DownLoadManager调用方法downLoad生成DownLoadRequest对象,同时将List参数代入,最后调用downLoadRequest.start()方法。

一、Start

start
我们将下载的部分操作封装成DownLoadHandle对象,59行我们调用queryDownLoadData方法,对应上面结构图的查询下载总长度步骤,这是一个耗时操作,不用担心,我们在之前的DownLoadManager中已经创建线程了,这里面的所有操作都是在子线程中进行的,UI线程是不会被阻塞的。
queryDownLoadData:
//汇总所有下载信息
List queryDownLoadData(List list) {
    final Iterator iterator = list.iterator();
    while (iterator.hasNext()) {
        DownLoadEntity downLoadEntity = (DownLoadEntity) iterator.next();
        downLoadEntity.downed = 0;
        Call mResponseCall = null;        
        List dataList = mDownLoadDatabase.query(downLoadEntity.url);
        if (dataList.size() > 0) {
            downLoadEntity.multiList = dataList;
            if (!TextUtils.isEmpty(dataList.get(0).lastModify)) {
                mResponseCall = NetWorkRequest.getInstance().getDownLoadService().getHttpHeaderWithIfRange(downLoadEntity.url, dataList.get(0).lastModify, "bytes=" + 0 + "-" + 0);
            }
        } else {
            mResponseCall = NetWorkRequest.getInstance().getDownLoadService().getHttpHeader(downLoadEntity.url, "bytes=" + 0 + "-" + 0);
        }
        executeGetFileWork(mResponseCall, new GetFileCount(downLoadEntity, mResponseCall));
    }
    while (!mGetFileService.isShutdown() && getCount() != list.size()) {
    }
    return list;
}复制代码

迭代List,先在数据库中查询当前任务的url,如果查询结果大于0,说明我们曾经下载过此url,将dataList赋值给multList,下面介绍一个概念。如果我们下载过一个文件,但是服务器将这个文件的内容置换掉了,客户端如何判断下载文件的时效性?

request
http请求头中有个If-Range属性,下面摘自网络上解释:

If-Range是另一个起条件判断的请求头(我们之前讲过If-Match/If-None-Match,If-Modified-Since/If-Unmodified-Since).If-Range头用来避免客户端在下载了某资源(比如图片)的一部分后,下次重新下载又从头开始下载。使用If-Range之后,客户端每次可以从上次下载的部分之后继续开始下载。
If-Range的使用格式为:If-Range: Etag|Http-Date也就是说If-Range后面可以使用Etag或者Last-Modified返回的值:
If-Range: "df6b0-b4a-3be1b5e1"
If-Range: Tue, 8 Jul 2008 05:05:56 GMT
逻辑上来讲,上面2种方式分别和If-Match,If-Unmodified-Since的工作原理一样,他们的值正是服务器返回的Etag和Last-Modified值。

初次接触你可能是蒙圈的,没关系,这里举例来说明一下,我下载过一个文件A,这是http的response头信息:

response
Last-Modified,直观上很清晰他是一个关于时间戳的属性。他代表着文件最后修改时间,我们需要做的就是保持这个字段到本地,下次请求时候赋值给If-Range头信息,服务器会告诉你这文件是否更新过。怎么判断?

如果请求报文中的Last-Modified与服务器目标内容的Last-Modified相等,即没有发生变化,那么应答报文的状态码为206。如果服务器目标内容发生了变化,那么应答报文的状态码为200。

这里需要注意的是:If-Range首部行必须与Range首部行配套使用。如果请求报文中没有Range首部行,那么If-Range首部行就会被忽略。如果服务器不支持If-Range,那么Range首部行也会被忽略。
好了,理论具备,只欠代码了。继续看queryDownLoadData方法,如果我们下载过此url,并且Modified不为空,调用接口来看看他是否更新过

@GET
Call getHttpHeaderWithIfRange(@Url String fileUrl, @Header("If-Range") String lastModify, @Header("Range") String range);复制代码

和我们之前的downloadFile方法差不多,这里不多解释。继续看,如果没下载过,直接调用getHttpHeader方法,不需要If-Range头。
executeGetFileWork方法很简单只有两行代码:

private void executeGetFileWork(Call call, GetFileCountListener listener) {
    GetFileCountTask getFileCountTask = new GetFileCountTask(call, listener);    
    mGetFileService.submit(getFileCountTask);
}复制代码

GetFileCountTask,看名字就知道了,创建获取文件长度的任务,然后加入线程池。
GetFileCountListener查询结果回调:

public interface GetFileCountListener {
    void success(boolean isSupportMulti, boolean isNew, String modified, Long fileSize);
    void failed()
}复制代码

很简单两个方法,成功和失败。GetFileCountTask中通过response的返回报文,判断是否支持多线程下载,是否更新过,modified值,下载长度,代码很简单这里就不贴了,感兴趣的同学自己撸代码看吧。下面看GetFileCountListener回调:

GetFileCountListener回调
先看失败 如果重试次数小于0,停止所有任务,如果未到0,则重新尝试获取长度,重复次数默认为3次。


成功后赋值mDownLoadEntity相关属性,93-108行,如果未更换文件,判断下载文件还是否存在,存在说明只要下载剩余任务就可以了,不存在,当新任务对待。
setCount方法结合queryDownLoadData最后的while循环看,有个全局变量记录任务的完成数,每个url任务完成或者失败后count +1,如果未完成任务,或者线程池未被关闭则一直循环等待。
这里提醒下:尤其每个task都是一个线程,所以这里的计数,必须要考虑线程同步问题!这里我们选择使用synchronized。

整个queryDownLoadData就结束了,再回到start方法继续看,60-86行遍历所有下载任务,如果其中有total未获取到的任务(对应前面获取长度失败),那么直接返回错误,终止下载任务。如果都正常,叠加获得总下载值,如果总下载值=已经下载值,直接回调UI线程,已经下载结束了。88行,onStart()这时就已经回调给主线程下载百分比了,细心的朋友可能发现了,这是使用mMainThread回调UI线程,mMainThread是什么?看过Retrofit源码的朋友肯定不陌生,他的实现原理其实就是运用了拥有MainLooper的hander,因为我们的操作都是在异步线程中进行的,所以需要mMainThread是什么回调主线程(这个在之前已经讲过了),87行生成下载总回调,一个url是一个下载线程,一个下载线程对应一个自己的回调,那么每个线程的回调,统一汇聚到下载总回调,只有这个回调负责和UI接口通信。
一张图可能更能说明:

回调结构图
从下向上看,UI回调和总回调1对1关系,总回调里有UI回调引用,总回调和每个Task的回调,1对多关系,每个Listener中有总回调引用。
现在从上向下看,Listener下载了1MB,告诉总回调:“你可以给UI回调了”,UI回调就老老实实告诉UI我下载了1MB了。简单的说,总回调就是一个代理类。

二、AddDownLoadTask

我们还差什么?入口类完成了,真正的下载类完成了,下载之前的巴拉巴拉已经完成了,那就只差下载任务了对不对?下面就真的easy了。

private void addDownLoadTask(DownLoadEntity downLoadEntity) {
    Map downLoadTaskMap = new ConcurrentHashMap<>();
    MultiDownLoaderListener multiDownLoaderListener = new MultiDownLoaderListener(mDownCallBackListener);
    if (downLoadEntity.multiList != null && downLoadEntity.multiList.size() != 0) {
        for (int i = 0; i < downLoadEntity.multiList.size(); i++) {
            DownLoadEntity entity = downLoadEntity.multiList.get(i);            
            //当前分支是否下载完成
            if (entity.downed + entity.start > entity.end) {                continue;
            }
            DownLoadTask downLoadTask = new DownLoadTask.Builder().downLoadModel(entity).downLoadTaskListener(multiDownLoaderListener).build();
            executeNetWork(entity, downLoadTask, downLoadTaskMap);
        }
    } else {
        //文件不存在 直接下载        
        createDownLoadTask(downLoadEntity, NEW_DOWN_BEGIN, downLoadTaskMap, multiDownLoaderListener);
    }
}复制代码

map是内存缓存,之前就提过了,我们用
Taskprivate Map> mUrlTaskMap = new ConcurrentHashMap<>();
保存缓存信息,String是url,Map是当前url下的任务,为啥又用个Map?因为可能是多线程啊!Integer,下载任务的唯一ID,这里是数据库主键,Future不了解的同学请自行百度,这就是下载任务。
如果有下载记录,就找未完成的生成DownLoadTask, executeNetWork就是加入线程池。如果没有下载记录,就是新文件,createDownLoadTask创建下载任务。

createDownLoadTask
127-141 如果下载任务大于多线程下载的分割值,切成多段进行下载。else 单线程下载。
好了 大概的流程到这里就结束了,还差什么?Task任务回调,主线程回调,这些代码没有贴出来,大家自己去发现吧。这里用了代理模式,还有很多的多线程数据安全方面的代码。下载Error重置下载机制,判断下载是否真正结束机制。对缓存的操作,map套map的增删改查。

总结

到这所有的多线程下载和断点续传就结束了,其实写作过程是痛苦的,但是到结束还是很欣慰的,相信您从开始看到这篇结束,整个项目的流程您是了解的,怎么定制,怎么修改bug应该也没有问题了,毕竟思路有了,就差不停的实践了,对吗?
我希望这篇文章再思路上可以帮助到您,那也是我的初衷啊!
下篇文章我会整理封装的支持上拉,下拉,可以添加Head的RecycleView。
最后,感谢私信过我,鼓励过我,打赏过我的朋友,谢谢你们的支持。
GitHub地址
我希望大家可以积极fork,一起修改,如发现问题,欢迎反馈。
微信:hly1501

你可能感兴趣的:(Retrofit2的再封装实战—多线程下载与断点续传(三))