(干货) Android Volley框架源码详细解析
2016-04-26 12:29
656 查看
前言
经常接触Android网络编程的我们,对于Volley肯定不陌生,但我们不禁要问,对于Volley我们真的很了解吗?Volley的内部是怎样实现的?为什么几行代码就能快速搭建好一个网络请求?我们不但要知其然,也要知其所以然,抱着这样的目的,本文主要详细讲述Volley的源码,对内部流程进行详细解析。Part 1.从RequestQueue说起
(1)还记得搭建请求的第一步是什么吗?是新建一个请求队列,比如说这样:RequestQueue queue = Volley.newRequestQueue(context)
虽然表面上只是一句代码的事情,但是背后做了很多准备工作,我们追踪源码,找到Volley#newRequestQueue()方法:
/** * Creates a default instance of the worker pool and calls {@link RequestQueue#start()} on it. * You may set a maximum size of the disk cache in bytes. * * @param context A {@link Context} to use for creating the cache dir. * @param stack An {@link HttpStack} to use for the network, or null for default. * @param maxDiskCacheBytes the maximum size of the disk cache, in bytes. Use -1 for default size. * @return A started {@link RequestQueue} instance. */ public static RequestQueue newRequestQueue(Context context, HttpStack stack, int maxDiskCacheBytes) { File cacheDir = new File(context.getCacheDir(), DEFAULT_CACHE_DIR); String userAgent = "volley/0"; try { String packageName = context.getPackageName(); PackageInfo info = context.getPackageManager().getPackageInfo(packageName, 0); userAgent = packageName + "/" + info.versionCode; } catch (NameNotFoundException e) { } /** * 根据不同的系统版本号实例化不同的请求类,如果版本号小于9,用HttpClient * 如果版本号大于9,用HttpUrlConnection */ if (stack == null) { if (Build.VERSION.SDK_INT >= 9) { stack = new HurlStack(); } else { // Prior to Gingerbread, HttpUrlConnection was unreliable. // See: http://android-developers.blogspot.com/2011/09/androids-http-clients.html stack = new HttpClientStack(AndroidHttpClient.newInstance(userAgent)); } } //把实例化的stack传递进BasicNetwork,实例化Network Network network = new BasicNetwork(stack); RequestQueue queue; if (maxDiskCacheBytes <= -1){ // No maximum size specified //实例化RequestQueue类 queue = new RequestQueue(new DiskBasedCache(cacheDir), network); } else { // Disk cache size specified queue = new RequestQueue(new DiskBasedCache(cacheDir, maxDiskCacheBytes), network); } //调用RequestQueue的start()方法 queue.start(); return queue; }
首先我们看参数,有三个,实际上我们默认使用了只有一个参数context的方法,这个是对应的重载方法,最终调用的是三个参数的方法,context是上下文环境;stack代表需要使用的网络连接请求类,这个一般不用设置,方法内部会根据当前系统的版本号调用不同的网络连接请求类(HttpUrlConnection和HttpClient);最后一个参数是缓存的大小。接着我们看方法内部,这里先创建了缓存文件,然后根据不同的系统版本号实例化不同的请求类,用stack引用这个类。接着又实例化了一个BasicNetwork,这个类在下面会说到。然后到了实际实例化请求队列的地方:new RequestQueue(),这里接收两个参数,分别是缓存和network(BasicNetwork)。实例化RequestQueue后,调用了start()方法,最后返回这个RequestQueue。
(2)我们跟着RequestQueue看看它的构造器做了哪些工作:
/** * Creates the worker pool. Processing will not begin until {@link #start()} is called. * * @param cache A Cache to use for persisting responses to disk * @param network A Network interface for performing HTTP requests * @param threadPoolSize Number of network dispatcher threads to create * @param delivery A ResponseDelivery interface for posting responses and errors */ public RequestQueue(Cache cache, Network network, int threadPoolSize, ResponseDelivery delivery) { mCache = cache; mNetwork = network; //实例化网络请求数组,数组大小默认是4 mDispatchers = new NetworkDispatcher[threadPoolSize]; mDelivery = delivery; } public RequestQueue(Cache cache, Network network, int threadPoolSize) { this(cache, network, threadPoolSize, //ResponseDelivery是一个接口,实现类是ExecutorDelivery new ExecutorDelivery(new Handler(Looper.getMainLooper()))); } public RequestQueue(Cache cache, Network network) { this(cache, network, DEFAULT_NETWORK_THREAD_POOL_SIZE); }
可以看到,把传递过来的cache和network作为变量传递给了四个参数的构造器,在这里,初始化了RequestQueue的几个成员变量:mCache(文件缓存)、mNetwork(BasicNetwork实例)、mDispatchers(网络请求线程数组)、以及mDelivery(派发请求结果的接口),具体意义可看上面的注解。
(3)构造完RequestQueue后,从(1)可知,最后调用了它的start()方法,我们来看看这个方法,RequestQueue#start():
public void start() { stop(); // Make sure any currently running dispatchers are stopped. // Create the cache dispatcher and start it. mCacheDispatcher = new CacheDispatcher(mCacheQueue, mNetworkQueue, mCache, mDelivery); mCacheDispatcher.start(); // Create network dispatchers (and corresponding threads) up to the pool size. for (int i = 0; i < mDispatchers.length; i++) { NetworkDispatcher networkDispatcher = new NetworkDispatcher(mNetworkQueue, mNetwork, mCache, mDelivery); mDispatchers[i] = networkDispatcher; networkDispatcher.start(); } }
首先实例化了CacheDispatcher,CacheDispatcher类继承自Thread,接着调用了它的start()方法,开始了一条新的缓存线程。接着是一个for循环,根据设置的mDispatchers数组大小来开启多个网络请求线程,默认是4条网络请求线程。
到目前为止,Volley.newRequestQueue()方法完成了,即我们的网络请求第一步,建立请求队列完成。
先小结一下:建立请求队列所做的工作是,创建文件缓存(默认),实例化BasicNetwork,实例化Delivery用于发送线程请求,创建一条缓存线程和四条网络请求线程(默认)并运行。
Part 2.网络请求的实现原理
在创建完请求队列后,接着就是建立一个请求,请求的方式可以是StringRequest、JsonArrayRequest或者ImageRequest等,那么这些请求的背后原理是什么呢?我们拿最简单的StringRequest来说,它继承自Request,而Request则是所有请求的父类,所以说如果你要自定义一个网络请求,就应该继承自Request。接下来我们看看StringRequest的源码,因为不管Request的子类是什么,大体的实现思路都是一致的,所以我们弄懂了StringRequest,那么对于其他的请求类的理解是相通的。如下是StringRequest源码:public class StringRequest extends Request<String> { private Listener<String> mListener; public StringRequest(int method, String url, Listener<String> listener, ErrorListener errorListener) { super(method, url, errorListener); mListener = listener; } ... @Override protected void deliverResponse(String response) { if (mListener != null) { mListener.onResponse(response); } } @Override protected Response<String> parseNetworkResponse(NetworkResponse response) { String parsed; try { parsed = new String(response.data, HttpHeaderParser.parseCharset(response.headers)); } catch (UnsupportedEncodingException e) { parsed = new String(response.data); } return Response.success(parsed, HttpHeaderParser.parseCacheHeaders(response)); } }
源码并不长,我们主要关注的是deliverResponse方法和parseNetworkResponse。可以看出,这两个方法都是重写的,我们翻看父类Request的对应方法,发现是抽象方法,说明这两个方法在每一个自定义的Request中都必须重写。这里简单说说这两个方法的作用。先看deliverResponse方法:它内部调用了mListener.onResponse(response)方法,而这个方法正是我们在写一个请求的时候,添加的listener所重写的onResponse方法,也就是说,响应成功后在这里调用了onResponse()方法。接着看pareNetworkResponse方法,可以看出这里主要是对response响应做出一些处理。可以对比一下不同请求类的这个方法,都会不同的,所以说,这个方法是针对不同的请求类型而对响应做出不同的处理。比如说,如果是StringRequest,则将响应包装成String类型;如果是JsonObjectRequest,则将响应包装成JsonObject。那么现在应该清楚了:对于想要得到某一种特殊类型的请求,我们可以自定义一个Request,重写这两个方法即可。
这里**小结一下:**Request类做的工作主要是初始化一些参数,比如说请求类型、请求的url、错误的回调方法;而它的任一子类重写deliverResponse方法来实现成功的回调,重写parseNetworkResponse()方法来处理响应数据;至此,一个完整的Request请求搭建完毕。
Part 3.添加请求
前面已经完成了请求队列的创建,Request请求的创建,那么接下来就是把请求添加进队列了。我们看RequestQueue#add()源码:/** * Adds a Request to the dispatch queue. * @param request The request to service * @return The passed-in request */ public <T> Request<T> add(Request<T> request) { // Tag the request as belonging to this queue and add it to the set of current requests. //标记当前请求,表示这个请求由当前RequestQueue处理 request.setRequestQueue(this); synchronized (mCurrentRequests) { mCurrentRequests.add(request); } // Process requests in the order they are added. //获得当前请求的序号 request.setSequence(getSequenceNumber()); request.addMarker("add-to-queue"); // If the request is uncacheable, skip the cache queue and go straight to the network. //如果请求不能缓存,直接添加到网络请求队列,默认是可以缓存 if (!request.shouldCache()) { mNetworkQueue.add(request); return request; } // Insert request into stage if there's already a request with the same cache key in flight. // 锁定当前代码块,只能一条线程执行 synchronized (mWaitingRequests) { String cacheKey = request.getCacheKey(); //是否有相同请求正在处理 if (mWaitingRequests.containsKey(cacheKey)) { // There is already a request in flight. Queue up. //如果有相同请求正在处理,那么把这个请求放进mWaitingRequest中,等待。 Queue<Request<?>> stagedRequests = mWaitingRequests.get(cacheKey); if (stagedRequests == null) { stagedRequests = new LinkedList<Request<?>>(); } stagedRequests.add(request); mWaitingRequests.put(cacheKey, stagedRequests); if (VolleyLog.DEBUG) { VolleyLog.v("Request for cacheKey=%s is in flight, putting on hold.", cacheKey); } } else { // Insert 'null' queue for this cacheKey, indicating there is now a request in // flight. //没有相同的请求,那么把请求放进mWaitingRequests中,同时也放进mCacheQueue缓存队列中 //这代表这个请求已经开始在缓存线程中运行了 mWaitingRequests.put(cacheKey, null); mCacheQueue.add(request); } return request; } }
结合相应的注释,我们得出如下结论:在这个add方法中,主要判断一个Request请求是否可以缓存(默认是可以缓存的),如果不可以则直接添加到网络请求队列开始网络通信;如果可以,则进一步判断当前是否有相同的请求正在进行,如果有相同的请求,则让这个请求排队等待,如果没有相同的请求,则直接放进缓存队列中。如果对此还有什么疑问,可以看下面的流程图(图片来自网络):
Part 4.缓存线程
在part1的最后实例化了缓存线程并开始运行,一直处于等待状态,而上面把请求添加进了缓存线程,此时缓存线程就开始真正的工作了。我们来看缓存线程的源码,主要看它的run()方法,CacheDispatcher#run():@Override public void run() { if (DEBUG) VolleyLog.v("start new dispatcher"); Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND); // Make a blocking call to initialize the cache. mCache.initialize(); Request<?> request; while (true) { // release previous request object to avoid leaking request object when mQueue is drained. request = null; try { // Take a request from the queue. //从缓存队列中取出请求 request = mCacheQueue.take(); } ... try { request.addMarker("cache-queue-take"); // If the request has been canceled, don't bother dispatching it. if (request.isCanceled()) { request.finish("cache-discard-canceled"); continue; } // Attempt to retrieve this item from cache. //从文件缓存中取出这个请求的结果 Cache.Entry entry = mCache.get(request.getCacheKey()); if (entry == null) { request.addMarker("cache-miss"); // Cache miss; send off to the network dispatcher. mNetworkQueue.put(request); continue; } // If it is completely expired, just send it to the network. //判断缓存是否过期 if (entry.isExpired()) { request.addMarker("cache-hit-expired"); request.setCacheEntry(entry); mNetworkQueue.put(request); continue; } // We have a cache hit; parse its data for delivery back to the request. request.addMarker("cache-hit"); //先将响应的结果包装成NetworkResponse,然后调用Request子类的 //parseNetworkResponse方法解析数据 Response<?> response = request.parseNetworkResponse( new NetworkResponse(entry.data, entry.responseHeaders)); request.addMarker("cache-hit-parsed"); if (!entry.refreshNeeded()) { // Completely unexpired cache hit. Just deliver the response. //调用ExecutorDelivey#postResponse方法 mDelivery.postResponse(request, response); } else { .... } } catch (Exception e) { VolleyLog.e(e, "Unhandled exception %s", e.toString()); } } }
在run()方法中,我们可以看到最开始有一个while(true)循环,表示它一直在等待缓存队列的新请求的出现。接着,先判断这个请求是否有对应的缓存结果,如果没有则直接添加到网络请求队列;接着再判断这个缓存结果是否过期了,如果过期则同样地添加到网络请求队列;接下来便是对缓存结果的处理了,我们可以看到,先是把缓存结果包装成NetworkResponse类,然后调用了Request的parseNetworkResponse,这个方法我们在part2说过,子类需要重写这个方法来处理响应数据。最后,把处理好的数据post到主线程,这里用到了ExecutorDelivery#postResponse()方法,下面会分析到。
小结:CacheDispatcher线程主要对请求进行判断,是否已经有缓存,是否已经过期,根据需要放进网络请求队列。同时对相应结果进行包装、处理,然后交由ExecutorDelivery处理。这里以一张流程图显示它的完整工作流程:
Part 5.网络请求线程
上面提到,请求不能缓存、缓存结果不存在、缓存过期的时候会把请求添加进请求队列,此时一直等待的网络请求线程由于获取到请求,终于要开始工作了,我们来看NetworkDispatcher#run()方法:@Override public void run() { Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND); Request<?> request; while (true) { long startTimeMs = SystemClock.elapsedRealtime(); // release previous request object to avoid leaking request object when mQueue is drained. request = null; try { // Take a request from the queue. request = mQueue.take(); } ... try { ... // Perform the network request. //调用BasicNetwork实现类进行网络请求,并获得响应 1 NetworkResponse networkResponse = mNetwork.performRequest(request); ... // Parse the response here on the worker thread. //对响应进行解析 Response<?> response = request.parseNetworkResponse(networkResponse); request.addMarker("network-parse-complete"); ... request.markDelivered(); mDelivery.postResponse(request, response); // Write to cache if applicable. //将响应结果写进缓存 if (request.shouldCache() && response.cacheEntry != null) { mCache.put(request.getCacheKey(), response.cacheEntry); request.addMarker("network-cache-written"); } } ... } }
源码做了适当的删减,大体上和CacheDispatcher的逻辑相同,这里关注①号代码,这里调用了BasicNetwork#perfromRequest()方法,把请求传递进去,可以猜测,这个方法内部实现了网络请求的相关操作,那么我们进去看看,BasicNetwork#perfromRequest():
@Override public NetworkResponse performRequest(Request<?> request) throws VolleyError { long requestStart = SystemClock.elapsedRealtime(); while (true) { HttpResponse httpResponse = null; byte[] responseContents = null; Map<String, String> responseHeaders = Collections.emptyMap(); try { // Gather headers. Map<String, String> headers = new HashMap<String, String>(); addCacheHeaders(headers, request.getCacheEntry()); httpResponse = mHttpStack.performRequest(request, headers); // 1 StatusLine statusLine = httpResponse.getStatusLine(); int statusCode = statusLine.getStatusCode(); responseHeaders = convertHeaders(httpResponse.getAllHeaders()); // Handle cache validation. if (statusCode == HttpStatus.SC_NOT_MODIFIED) { Entry entry = request.getCacheEntry(); if (entry == null) { return new NetworkResponse(HttpStatus.SC_NOT_MODIFIED, null, responseHeaders, true, SystemClock.elapsedRealtime() - requestStart); // 2 } // A HTTP 304 response does not have all header fields. We // have to use the header fields from the cache entry plus // the new ones from the response. // http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5 entry.responseHeaders.putAll(responseHeaders); return new NetworkResponse(HttpStatus.SC_NOT_MODIFIED, entry.data, entry.responseHeaders, true, SystemClock.elapsedRealtime() - requestStart); } ... } }
我们主要看①号代码,mHttpStack.performRequest();这里调用了mHttpStack的performRequest方法,那么mHttpStack是什么呢?我们可以翻上去看看part1处实例化BasicNetwork的时候传递的stack值,该值就是根据不同的系统版本号而实例化的HttpStack对象(版本号大于9的是HurlStack,小于9的是HttpClientStack),由此可知,这里实际调用的是HurlStack.performRequest()方法,方法的内部基本是关于HttpUrlConnection的逻辑代码,这里就不展开说了。可以这么说:HurlStack封装好了HttpUrlConnection,而HttpClientStack封装了HttpClient。该方法返回了httpResponse,接着把这个响应交由②处处理,封装成NetworkResponse对象并返回。在NetworkDispatcher#run()方法获取返回的NetworkResponse对象后,对响应解析,通过ExecutorDelivery#postResponse()方法回调解析出来的数据,这个过程和CacheDispatcher相同。
Part 6.ExecutorDelivery 通知主线程
在CacheDispatcher和NetworkDispatcher中最后都有调用到ExecutorDelivery#postResponse()方法,那么这个方法到底是做什么呢?由于缓存线程和网络请求线程都不是主线程,所以主线程需要有“人”通知它网络请求已经完成了,而这个“人”正是由ExecutorDelivery充当。在完成请求后,通过ExecutorDelivery#postResponse()方法,最终会回调到主线程中重写的onResponse()方法。我们看看这个方法的源码ExecutorDelivery#postResponse():@Override public void postResponse(Request<?> request, Response<?> response) { postResponse(request, response, null); } @Override public void postResponse(Request<?> request, Response<?> response, Runnable runnable) { request.markDelivered(); request.addMarker("post-response"); mResponsePoster.execute(new ResponseDeliveryRunnable(request, response, runnable)); }
在方法内部调用了mResponsePoster#execute()方法,那么,这个mResponsePoster是在哪里来的呢?其实这个成员变量是在ExecutorDelivery实例化的时候同时实例化的,而ExecutorDelivery则是在RequestQueue实例化的时候同时实例化的,读者可以自行查看相应的构造方法,其实这些工作在par 1建立请求队列的时候已经全部做好了。接着我们可以看以下代码,ExecutorDelivery#ExecutorDelivery():
public ExecutorDelivery(final Handler handler) { // Make an Executor that just wraps the handler. //实例化Executor,并且重写execute方法 mResponsePoster = new Executor() { @Override public void execute(Runnable command) { //这里获取的handler是主线程的handler,可看part 1 (2) handler.post(command); } }; }
execute()方法接收一个Runnable对象,那么我们回到上面的
mResponsePoster.execute(new ResponseDeliveryRunnable(request, response, runnable));
可以看出这里实例化了一个ResponseDeliveryRunnable对象作为Runnable对象。而这里的ResponseDeliveryRunnable则是当前类Executor的一个内部类,实现了Runnable接口,我们来看看:
/** * A Runnable used for delivering network responses to a listener on the * main thread. */ @SuppressWarnings("rawtypes") private class ResponseDeliveryRunnable implements Runnable { private final Request mRequest; private final Response mResponse; private final Runnable mRunnable; //构造方法 ... @Override public void run() { // If this request has canceled, finish it and don't deliver. if (mRequest.isCanceled()) { mRequest.finish("canceled-at-delivery"); return; } // Deliver a normal response or error, depending. if (mResponse.isSuccess()) { mRequest.deliverResponse(mResponse.result); // 1 } else { mRequest.deliverError(mResponse.error); } ... } } }
在上面,①号代码回调到了Request的deliverResponse方法,即此时通知了主线程,请求已经完成,此时在Request子类重写的deliverResponse方法则会调用onResponse()方法,那么我们的Activity就能方便调用解析好的请求结果了。
到目前为止,关于Volley的源码解析完毕。
总结
用google官方的一幅图来说明以上所说各个部分的关系(图片来自网络):蓝色部分代表主线程,绿色部分代表缓存线程,橙色部分代表网络请求线程。读者可以根据这幅图所展示的关系,再仔细体会part 1-6所说的流程,那么就很容易理解了。最后感谢你的阅读。
相关文章推荐
- 将android 应用强制横屏
- Android之This element neither has attached source nor attached Javadoc and hence no Javadoc could be
- android学习 4-25使用Path 绘制几何图形
- 【Android framework】am命令启动Activity流程
- android学习4-25 使用canvas绘制几何图形(在View内)
- 应用升级介绍
- android studio常用快捷键
- Android ListView的Item点击事件和Item里控件点击事件冲突问题解决
- android应用如何访问C库
- Android数据存储五种方式总结
- Android插件化(一):使用改进的MultiDex动态加载assets中的apk
- Android开发:LayoutParams的用法
- Android 在使用Bitmap的时候为啥要手动调用recycle方法呢?
- android source camera
- ScheduledExecutorService定时周期执行指定的任务
- Android开发之5.0特性深入理解(二)
- android控制板
- Android透明状态栏的实现
- Android-自定義控件使用(方便修改控件的風格,只修改布局文件)
- Android开发之activiti节点跳转