ThinDownloadManager源码解析

关于Android自带的DownloadManager可能大家都知道,使用自带的DownloadManager可以很方便的就实现文件下载。还不知道的也没关系,看看下面的示例代码你就知道怎么去使用了。

DownloadManager manager = (DownloadManager) getSystemService(DOWNLOAD_SERVICE);
//下载请求
DownloadManager.Request down = new DownloadManager.Request(Uri.parse("https://ss0.bdstatic.com/5aV1bjqh_Q23odCf/static/superman/img/logo_top_ca79a146.png"));
//设置允许使用的网络类型
down.setAllowedNetworkTypes(DownloadManager.Request.NETWORK_MOBILE | DownloadManager.Request.NETWORK_WIFI);
//禁止发出通知,既后台下载
down.setNotificationVisibility(DownloadManager.Request.VISIBILITY_HIDDEN);
//下载完成文件存放的位置
down.setDestinationInExternalFilesDir(MainActivity.this, null, "logo.png");
//将下载请求放入队列中,开始下载
manager.enqueue(down);

是不是很简单,直接使用系统自带的,几行代码就搞定了一个下载。使用这种方法,默认的会在系统的通知栏告诉用户有个下载的任务正在进行,如果不想让用户知道有任务正在进行你就必须加上

down.setNotificationVisibility(DownloadManager.Request.VISIBILITY_HIDDEN);````

但是单单加这个还是不行的,你不信可以运行一次试试,应用会直接Crash掉。我们还需要在清单文件声明下面这个权限:
```html
<uses-permission android:name="android.permission.DOWNLOAD_WITHOUT_NOTIFICATION" />

如果不再在意这些直接使用系统自带的DownloadManager 就足够了,但是很多人不想声明权限,就想让任务在后台运行(ps:不要问我为什么,我什么都不知道),这样就需要自己去实现下载功能了。

该说说ThinDownloadManager了,其实我也是无意中发现这个的,因为我想在我的开源项目MaterialDesignDemo中实现一个图片下载的功能,但是又不想自己去造轮子,我就想有一个下载功能而已,也不想使用那些很笨重的网络框架,所以就去到处找,最后发现了这个东东,比较轻量级,使用起来也还是比较的方便。因为我自己之前本来也计划自己去撸一个网络相关的框架,但是如果想写一个网络框架涉及的东西太多了,而我现在也还没有达到那个层次,所以就放弃了,平时使用的也就是对一些开源框架的再封装而已。

现在发现了这个,也还是对他的源码比较好奇,所以就决定去研究一下他的源码,看完了之后,我发现这个框架的结构比较简单不算复杂,于是就决定把我怎么去分析ThinDownloadManager这个框架源码的过程记录下来,给那些还不知道怎么去分析源码的同学一点经验。虽然这个库在现在已经有点过时了,但是他的一些思想还是值得我们去学习的。学习Android一定要学会看源码,不要一遇到问题就一昧的去网上搜,这个怎么实现,那个怎么实现,其实你只要先看看源码,可能问题很容易的就解决了,看源码对自己的提升也是显而易见的,就算以后Android不火了,但是他的很多编程思想是值得借鉴的
ThinDownloadManager的GitHub地址:ThinDownloadManager

在分析源码之前我们先来看看ThinDownloadManager怎么去使用吧,如果连怎么使用都不会,分析源码也就是纸上谈兵了



ThinDownloadManager的使用也还是比较简单的,和系统自带的差不多,我这里是为了我以后使用的方便所以就做了一次再封装,只需传入下载地址,保存地址,还有下载时的回调就可以了。

  1. 根据使用的顺序,我们就先来看看DownloadRequest,其实根据单词意思我们都能大概知道这里面是封装的肯定是下载请求的一些参数。
    先来看看他的构造方法
public DownloadRequest(Uri uri) {
        if (uri == null) {
            throw new NullPointerException();
        }

        String scheme = uri.getScheme();
        if (scheme == null || (!scheme.equals("http") && !scheme.equals("https"))) {
            throw new IllegalArgumentException("Can only download HTTP/HTTPS URIs: " + uri);
        }
        mCustomHeader = new HashMap<>();
        mDownloadState = DownloadManager.STATUS_PENDING;
        mUri = uri;
    }

在构造方法中对传入的uri做了校验,以及一些初始化的操作。
在示例代码中我们在使用DownloadRequest的时候,我们用到了setRetryPolicy和setDestinationURI以及setStatusListener,所以现在我们定位到这几个方法的源码中去。
看看setRetryPolicy(关于RetryPolicy 就是重试策略而已,在第一次看的时候,需先走一遍的流程,不需要去在意部分细节)

public DownloadRequest setRetryPolicy(RetryPolicy mRetryPolicy) {
        this.mRetryPolicy = mRetryPolicy;
        return this;
    }

这里的实现就是一个简单的赋值操作而已,既然有赋值方法,那么应该就有对应的取值方法,我Ctrl+F找了一下果然有getRetryPolicy这么一个方法。

public RetryPolicy getRetryPolicy() {
        return mRetryPolicy == null ? new DefaultRetryPolicy() : mRetryPolicy;
    }

从这里看出如果mRetryPolicy 设置了,我们就返回mRetryPolicy ,如果没有被设置我们就返回默认的。从这里可见在示例代码中的那句<code>setRetryPolicy(new DefaultRetryPolicy())</code>
是可以不用设置的,因为默认的就是DefaultRetryPolicy。
再来看看setDestinationURI这个方法

 public DownloadRequest setDestinationURI(Uri destinationURI) {
        this.mDestinationURI = destinationURI;
        return this;
    }

和setRetryPolicy方法一样,就是一个简单的赋值操作而已。
setStatusListener同理,我就不再做多余的解释了。

  1. DownloadRequest配置完成之后,我们就使用到了ThinDownloadManager,也还是先进他的构造方法里面去看看。ThinDownloadManager的构造方法就不只一个了,我们就直接来看看他默认的吧
 public ThinDownloadManager() {
        mRequestQueue = new DownloadRequestQueue();
        mRequestQueue.start();
    }

在这里他新建了一个下载的请求队列DownloadRequestQueue,然后调用了DownloadRequestQueue的start方法。
再来看看ThinDownloadManager的add方法都干了些什么

public int add(DownloadRequest request) throws IllegalArgumentException {
        if(request == null) {
            throw new IllegalArgumentException("DownloadRequest cannot be null");
        }

        return mRequestQueue.add(request);
    }

从源码中可以看到add方法就是把我们的下载请求添加到DownloadRequestQueue这个请求队列中去。

  1. 在分析ThinDownloadManager这个类的时候,我们发现DownloadRequestQueue用到的比较多,并且也比较重要,现在我们就定位到DownloadRequestQueue这个类中去。一样我们还是先来看看其构造方法,一般在使用一个类的时候,我们都需要先初始化他,所以先看构造方法也还是有必要的。
    /**
     * Default constructor.
     */
     public DownloadRequestQueue() {
        initialize(new Handler(Looper.getMainLooper()));
    }

在这里他调用了 initialize方法,所以我们就来看看initialize的实现

private void initialize(Handler callbackHandler) {
        int processors = Runtime.getRuntime().availableProcessors();
        mDownloadDispatchers = new DownloadDispatcher[processors];
        mDelivery = new CallBackDelivery(callbackHandler);
    }

在这里processors 就是java虚拟机可用的处理器个数,最初的时候我也不知道这是啥,最后去查了一下才知道,所以看源码还是能学到很多东西的,废话不多说,我们继续。从代码中可以看出在initialize中新建了一个processors 大小的DownloadDispatcher数组,以及CallBackDelivery。

在ThinDownloadManager的构造方法中调用了DownloadRequestQueue的start方法,所以这里我们就先来看看start方法

public void start() {
        stop(); // Make sure any currently running dispatchers are stopped.
        // Create download dispatchers (and corresponding threads) up to the pool size.
        for (int i = 0; i < mDownloadDispatchers.length; i++) {
            DownloadDispatcher downloadDispatcher = new DownloadDispatcher(mDownloadQueue, mDelivery);
            mDownloadDispatchers[i] = downloadDispatcher;
            downloadDispatcher.start();
        }
    }

stop可以先不用去看他,直接来看for循环里面都干了些什么,可以看到在for循环里就是对mDownloadDispatchers中的每一个DownloadDispatcher 做了一次初始化操作
随后就调用了DownloadDispatcher 的start方法。

4.上面这么多的代码都涉及到了DownloadDispatcher ,下面我们就来看看DownloadDispatcher 的实现吧。
其构造方法如下:

/** Constructor take the dependency (DownloadRequest queue) that all the Dispatcher needs */
    public DownloadDispatcher(BlockingQueue<DownloadRequest> queue,
                              DownloadRequestQueue.CallBackDelivery delivery) {
        mQueue = queue;
        mDelivery = delivery;
    }

在这里就传了一个下载请求的队列和CallBackDelivery(CallBackDelivery是用来进行回调的分发用的,是DownloadRequestQueue的一个内部类,后面自己去看源码就知道了,第一次走流程的时候不需要太在意这个) 进来并给成员变量赋值。在DownloadRequestQueue使用到了downloadDispatcher.start(),所以我就点进start去看看,结果发现怎么进了Thread的start方法了,仔细看了一下DownloadDispatcher 源码,发现原来DownloadDispatcher 继承了Thread,也就是说DownloadDispatcher 其实就是一个线程,所以之前调用了start方法就是让这个线程开始执行,既然继承了Thread那么肯定得有run方法吧,于是我就定位到了run方法:

 public void run() {
        Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
        mTimer = new Timer();
        while(true) {
            try {
                mRequest = mQueue.take();
                mRedirectionCount = 0;
                Log.v(TAG, "Download initiated for " + mRequest.getDownloadId());
                updateDownloadState(DownloadManager.STATUS_STARTED);
                executeDownload(mRequest.getUri().toString());
            } catch (InterruptedException e) {
                // We may have been interrupted because it was time to quit.
                if (mQuit) {
                    if(mRequest != null) {
                        mRequest.finish();
                        updateDownloadFailed(DownloadManager.ERROR_DOWNLOAD_CANCELLED, "Download cancelled");
                        mTimer.cancel();
                    }
                    return;
                }
                continue;               
            }
        }
    }

可见在run方法中有一个while的无限循环,里面的最主要的事的就是从当前的请求队列中取出一个请求然后调用executeDownload去执行下载。(PS:因为这个队列是可阻塞的队列,所以当队列里没有任何请求的话,就会阻塞在mQueue.take(),直到队列中有请求的时候,才会继续向下执行,这个是Java并发编程相关的知识点)

private void executeDownload(String downloadUrl) {
        URL url;
        try {
            url = new URL(downloadUrl);
        } catch (MalformedURLException e) {
            updateDownloadFailed(DownloadManager.ERROR_MALFORMED_URI,"MalformedURLException: URI passed is malformed.");
            return;
        }

        HttpURLConnection conn = null;

        try {
            conn = (HttpURLConnection) url.openConnection();
            conn.setInstanceFollowRedirects(false);
            conn.setConnectTimeout(mRequest.getRetryPolicy().getCurrentTimeout());
            conn.setReadTimeout(mRequest.getRetryPolicy().getCurrentTimeout());

            HashMap<String, String> customHeaders = mRequest.getCustomHeaders();
            if (customHeaders != null) {
                for (String headerName : customHeaders.keySet()) {
                    conn.addRequestProperty(headerName, customHeaders.get(headerName));
                }
            }

            // Status Connecting is set here before
            // urlConnection is trying to connect to destination.
            updateDownloadState(DownloadManager.STATUS_CONNECTING);
            
            final int responseCode = conn.getResponseCode();
            
            Log.v(TAG, "Response code obtained for downloaded Id "
                + mRequest.getDownloadId()
                + " : httpResponse Code "
                + responseCode);
            
            switch (responseCode) {
                case HTTP_PARTIAL:
                case HTTP_OK:
                    shouldAllowRedirects = false;
                    if (readResponseHeaders(conn) == 1) {
                        transferData(conn);
                    } else {
                        updateDownloadFailed(DownloadManager.ERROR_DOWNLOAD_SIZE_UNKNOWN, "Transfer-Encoding not found as well as can't know size of download, giving up");
                    }
                    return;
                case HTTP_MOVED_PERM:
                case HTTP_MOVED_TEMP:
                case HTTP_SEE_OTHER:
                case HTTP_TEMP_REDIRECT:
                    // Take redirect url and call executeDownload recursively until
                    // MAX_REDIRECT is reached.
                    while (mRedirectionCount++ < MAX_REDIRECTS && shouldAllowRedirects) {
                        Log.v(TAG, "Redirect for downloaded Id "+mRequest.getDownloadId());
                        final String location = conn.getHeaderField("Location");
                        executeDownload(location);
                        continue;
                    }

                    if (mRedirectionCount > MAX_REDIRECTS) {
                        updateDownloadFailed(DownloadManager.ERROR_TOO_MANY_REDIRECTS, "Too many redirects, giving up");
                        return;
                    }
                    break;
                case HTTP_REQUESTED_RANGE_NOT_SATISFIABLE:
                    updateDownloadFailed(HTTP_REQUESTED_RANGE_NOT_SATISFIABLE, conn.getResponseMessage());
                    break;
                case HTTP_UNAVAILABLE:
                    updateDownloadFailed(HTTP_UNAVAILABLE, conn.getResponseMessage());
                    break;
                case HTTP_INTERNAL_ERROR:
                    updateDownloadFailed(HTTP_INTERNAL_ERROR, conn.getResponseMessage());
                    break;
                default:
                    updateDownloadFailed(DownloadManager.ERROR_UNHANDLED_HTTP_CODE, "Unhandled HTTP response:" + responseCode +" message:" +conn.getResponseMessage());
                    break;
            }
        } catch(SocketTimeoutException e) {
            e.printStackTrace();
            // Retry.
            attemptRetryOnTimeOutException();
        } catch (ConnectTimeoutException e) {
            e.printStackTrace();
            attemptRetryOnTimeOutException();
        } catch(IOException e) {
            e.printStackTrace();
            updateDownloadFailed(DownloadManager.ERROR_HTTP_DATA_ERROR, "Trouble with low-level sockets");
        } finally {
            if (conn != null) {
                conn.disconnect();
            }
        }
    }

学习过Android网络编程的同学肯定对这里面的代码很熟悉了,从代码中可以看到其实ThinDownloadManager的底层就是用HttpURLConnection去实现的,其他的代码其实就是去更新当前下载的状态,还有网络连接超时的重试等等。

到这里整个过程就分析的差不多了,更详细的实现可以去下载ThinDownloadManager源码自己详看。

通过上面的分析大致流可以总结为:先创建一个下载请求DownloadRequest,随后再新建一个请求队列DownloadRequestQueue和下载器DownloadDispatcher,下载器DownloadDispatcher随即开始执行,然后再将请求加入到下载请求队列中由下载器去从请求队列中取出下载请求,然后下载。

ThinDownloadManager的源码的层次结构还是比较清晰的,所以看起来相对也比较容易,看源码一般都是从我们使用的地方进去,一步一步的跟进,刚开始注重流程,不要太去部分在意细节的实现,流程走通了,然后再来看实现,我相信你会收获的更多,本文主要介绍了看源码的其中一种方法,仅供参考,可以让你看源码的时候多一种思路,希望能给正在阅读的你带来帮助。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 157,198评论 4 359
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 66,663评论 1 290
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 106,985评论 0 237
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,673评论 0 202
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 51,994评论 3 285
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,399评论 1 211
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,717评论 2 310
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,407评论 0 194
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,112评论 1 239
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,371评论 2 241
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,891评论 1 256
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,255评论 2 250
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,881评论 3 233
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,010评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,764评论 0 192
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,412评论 2 269
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,299评论 2 260

推荐阅读更多精彩内容

  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 134,087评论 18 139
  • Android 自定义View的各种姿势1 Activity的显示之ViewRootImpl详解 Activity...
    passiontim阅读 170,544评论 25 707
  • 注:本文转自http://codekk.com/open-source-project-analysis/deta...
    Ten_Minutes阅读 1,258评论 1 16
  • 20170610 今天是公公的生日,按照惯例,总是一家族的人聚在一起整一天,男同志最终都会跑到麻将桌,女同志干完事...
    春芸1216阅读 137评论 4 7
  • 光纤跳线又叫(光纤连接器)是光纤与光纤之间进行可坼卸(活动)连接器件,那么光纤跳线怎样接才正确,什么样的光纤跳线接...
    enrilink阅读 5,176评论 0 0