DownloadManager分析(1)

Summary

DownloadManager是Android系统封装好的一个功能，位于/android/app/目录下，实现了下载功能。文档是这么说的：

download manager是一个处理长时间http下载的系统服务。客户端可以发出请求，让URI下载到特定的文件中。download manager会在后台执行下载，处理HTTP交互，并且在网络变化之后导致连接失败/系统重启后能重新尝试下载。通过传递DOWNLOAD_SERVICE给getSystemService来获得DownloadManager实例。通过这个API请求Download的App应该注册一个ACTION_NOTIFICATION_CLICKED来处理用户在Notification或者UI中点击一个正在下载的进度的操作。

SystemService的启动

读完了Summary这段话有一个疑问，为什么通过getSystemService才能获取实例。在Context的源码中发现，getSystemService是在Context中实现的抽象方法，具体是在framework的ContextImpl.java中实现的，我们看到有一个专门盛放SystemService的SYSTEM_SERVICE_MAP：

    @Override    public Object getSystemService(String name) {        ServiceFetcher fetcher = SYSTEM_SERVICE_MAP.get(name);        return fetcher == null ? null : fetcher.getService(this);    }

看来是有人往这个SYSTEM_SERVICE_MAP里面加ServiceName了。在ContextImpl里面，有一个函数在往MAP里填东西：

    private static void registerService(String serviceName, ServiceFetcher fetcher) {        if (!(fetcher instanceof StaticServiceFetcher)) {            fetcher.mContextCacheIndex = sNextPerContextServiceCacheIndex++;        }        //系统启动时往        SYSTEM_SERVICE_MAP.put(serviceName, fetcher);    }

然后我们看到，同样是在这个类里面实现了所有系统Service的注册：

//通过static方法优先注册所有的service。 static {        registerService(ACCESSIBILITY_SERVICE, new ServiceFetcher() {                public Object getService(ContextImpl ctx) {                    return AccessibilityManager.getInstance(ctx);                }});......

好了，上面我们看到了Service被ServerFetcher取出后添加进MAP的动作；那么这些服务是谁初始化的？答案是SystemServer。SystemServer是Android的核心进程，由zygote创建。所有服务都循环创建在SystemServer上。

另外，ContextImpl跟Context是什么关系？我们在Application.java里面可以看到有ContextImpl的初始化，但是Context跟ContextImpl表面上并没有继承关系，虽然后者确实是前者的实现。

好了，我们得到一个结论，系统启动的时候，zygote帮忙启动了DownloadService这个SystemService，运行在SystemServer进程上。

从调用开始

回到最开始，我们最终开始下载，使用的是dowloadManager.enqueue(request);这样的调用方式，enqueue也就是把一个request加入队列，downloadmanager准备好了并且网络正常的时候会立刻开始下载。

    public long enqueue(Request request) {    //把request添加进ContentValues(类似hashmap)里        ContentValues values = request.toContentValues(mPackageName);        Uri downloadUri = mResolver.insert(Downloads.Impl.CONTENT_URI, values);        long id = Long.parseLong(downloadUri.getLastPathSegment());        return id;    }

这里厉害了，toContentValues方法的说明是:

ContentValues to be passed to DownloadProvider.insert()

也就是说这个request实际上是给DownloadProvider准备的!唉，DownloadManager看了半天，里面根本没有实现下载的操作，几乎全是「是否显示Notification」「下载进度查询」「下载成功监听」之类的管理性质的工作。

我查了资料里面说，在Android N之前的版本，这个DownloadProvider.insert()执行之后，会直接以Context.startService的方式启动DownloadService进行异步下载。先不说Android N之后的版本是怎么处理的，读到这里我脑中大概形成了这样一个模型：

DownloadManager分发任务给DownloadProvider
DownloadProvider调用DownloadService
DownloadService真正执行下载操作

明天继续看。

References:
[1]http://www.cnblogs.com/adm1989/p/4631129.html
[2]https://segmentfault.com/q/1010000004457662
[3]http://www.jianshu.com/p/c9dc04af2f54#

EP28-DownloadManager分析(1)

DownloadManager分析(1)

Summary

SystemService的启动

从调用开始

更多相关文章

随机推荐