volle介绍02

最新推荐文章于 2021-12-22 00:13:43 发布

aiba5303

最新推荐文章于 2021-12-22 00:13:43 发布

阅读量171

点赞数

原文链接：http://www.cnblogs.com/aprz512/p/5316673.html

版权

----------------------------------------------------------------------------

转载：http://blog.csdn.net/crazy__chen/article/details/46483329

----------------------------------------------------------------------------

Volley是一款由Google 推出的 Android 异步网络请求框架和图片加载框架，特别适合数据量小，通信频繁的网络操作。

大家可以在这个地址https://android.googlesource.com/platform/frameworks/volley/下载源码

Volley 的主要特点

(1). 扩展性强。Volley 中大多是基于接口的设计，可配置性强。
(2). 一定程度符合 Http 规范，包括返回 ResponseCode(2xx、3xx、4xx、5xx）的处理，请求头的处理，缓存机制的支持等。并支持重试及优先级定义。
(3). 默认 Android2.3 及以上基于 HttpURLConnection，2.3 以下基于 HttpClient 实现
(4). 提供简便的图片加载工具。

本专栏主要通过解析volley的源码，对它的整个架构进行分析，指出它这样设计架构，对应扩展性，耦合等优势。同时，指出volley对于网络请求，考虑到的细节方面，用于指导我们日后自己写网络框架的需求。另外还会根据volley的设计，说明它所应用的场景，volley所面临的不足，以及它本身可以怎么被更完善的扩展。

本篇文章作为专栏的开篇，会先给简单大家介绍volley的使用和volley的整个架构设计，通过对架构的介绍，希望大家对volley的实现模式有个大体的印象。在这篇文章中，大家不必要关注实现的细节(因为在接下来的文章会详细介绍)，主要做到的是体会volley的设计思路，关注整体的实现。

网上介绍volley如何使用的文章有很多，大家可以自行搜索一下，这里我举一个简单的例子说明如何使用volley进行网络请求。

StringRequest stringRequest = new StringRequest("http://www.baidu.com",  
    new Response.Listener<String>() {  
        @Override  
        public void onResponse(String response) {  
            //处理响应  
        }  
    }, new Response.ErrorListener() {  
        @Override  
            public void onErrorResponse(VolleyError error) {  
               //处理错误  
        }  
    });

有上面的代码我们可以看出，我们实例化了一个StringRequest对象，其中有一个网络地址www.baidu.com,两个监听器

观察监听器里面的方法，一个参数是String response,一个是VolleyError error

从字面上的意思理解，我们创建了一个网络请求对象request,传入请求的地址，请求成功以后，会回调两个监听器的方法，两个监听器分别对应请求成功与请求失败的情况。

OK，是不是只要这样就已经开启了线程去请求数据了呢。没有这么简单，我们还要：

RequestQueue mQueue = Volley.newRequestQueue(context); //创建请求队列  
mQueue.add(stringRequest); //将请求添加到请求队列

上面的操作，将我们构造的请求，添加到一个新建的请求队列里面。到此为止，我们就成功地发出了请求，并且在请求结束以后，会回调我们request里面的方法。

这就是volley最简单的使用。

有人会问，为什么要将请求加入队列里面，我直接new一个Request，然后在Request内部建立线程，请求数据，最后回调接口不就好了吗？

这样想是没有错，但是volley这样设计必然有自己的原因，就耦合过紧这一点而言，就可以知道我们上面提出的策略并不是那么的优雅(不代表不可行)。

那么volley是怎么做到呢？我们先来看一张volley的整体架构图(该图出自http://codekk.com/open-source-project-analysis/detail/Android/grumoon/Volley%20%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%90，如果不允许转载，请联系我)

上面的图有点复杂，大家先不要纠结，我们先来看我们之前的结论，volley的使用过程是

1，创建request

2，将request放入队列RequestQueue

3，处理回调结果

注意到例子中使用的StringRequest，对应上面的图，找到Request和StringRequest可以知道，StringRequest是Request的一个子类，从字面上可以知道，这是一个字符串请求，另外还有json,image请求等，都是request的子类，所以我们设想，是不是不同的请求，有一个不同的类呢？

正是这样的，从面向对象的角度，我们把请求看成是一个类，所以我们每次的网络请求，只有new出一个类，然后加入队列就可以了。

那么队列里面是怎么样替我请求数据的呢？这里我给大家介绍其中的奥秘，大家只要了解过程就可以，不必深究细节。

其实RequestQueue里面有两个队列，一个我称为缓存队列mCacheQueue，一个称为网络队列mNetworkQueue

如果请求要求加入缓存队列(例如我们给request设置一个属性ShouldCache，然后提供set方法来设置)，将会试图从硬盘缓存中获取数据，如果没有缓存，这个请求将被放入网络队列

如果请求不要求缓存，则直接加入网络队列。

加入队列以后，我们开启线程，从队列中取出请求。

可想而知，我们最好有一个线程CacheDispatcher从缓存队列中取，一个NetworkDispatcher从网络队列中取，然而网络请求往往大量，所以volley实际上有多个线程同时从网络队列中取出请求(这里涉及线程同步，volley使用PriorityBlockingQueue解决)

为什么要先建立几个线程，从队列中取，而不是每个request开启一个线程呢？这样做的好处是避免重复大量创建线程所带来的开销，另外由于所有的request都存在在一个RequestQueue里面，便于我们对request的管理，例如我们要关闭某个request,又或者我们请求了很多相同的request，对应这些操作，我们如果将request分散，是很难统一解决的，所以这样用类似线程池的思想，统一管理线程。

同时，这样做又会带来不利，因为实际请求线程的线程数目是固定的，意味着当request数目大于线程数目时，有的线程将被阻塞，造成效率下降，更多的问题，会在接下来的文章提到。

至于CacheDispatcher和NetworkDispatcher是怎么请求数据的呢？

对于NetworkDispatcher而言，必然是开启网络连接，然后获取数据的(例如url.openConnection)，这是我们的常用实现，先不做详细解释(volley对这些实现进行了更详细的封装)

再来考虑，获得结果以后，我们怎么回调。

还是面向对象的思路，volley将响应结果封装成一个repsonse类(和request对应)

对应NetworkDispatcher而言，在它的run()方法里面，取得request以后，根据url请求数据，将数据封装成respsonse对象，再有一个分发器ResponseDelivery分发到对应的request

有人会问?解析到response以后，我们给request设计一个方法(例如将parseRespose(Respsonse respsonse))用于使用response，同时在这个方法内，回调监听器不就好了吗？为什么要多此一举，创建一个分发器呢？

原因是这样更灵活，但是还有一个重要的原因是，注意到我们回调，往往是在主线程中进行的(因为很可能要操作UI)，如果我们在NetworkDispatcher(子线程)里面，直接回调，可能造成错误，这是ResponseDelivery存在的另外一个原因。

根据上面的结论，最后来看一张简单的流程图

根据流程分析，我们可以体会到，volley设计框架的基本思路，对比于我们简单的实现，volley的实现方式耦合更加松散，使用面向接口编程，同时使用更多组合方式而不是继承。使用了代理等设计模式，同时提高了线程的利用率。总之volley的架构设计又各种各样的好处。

我在这里介绍几个volley的功能，以及它考虑到的，而我们很可能没有考虑到的问题。这些问题或者说功能上的优势，会伴随着本专栏的深入让大家逐渐体会。

下面只是笼统的介绍，大家可以对比自己的想法，看看自己是不是有什么考虑不周的(如果是你实现这样一个框架的话)

1，Request的设计，我们在得到response之后，我们可能根据项目需求希望有不同形式的数据(例如string,bitmap,jsonObject),volley使用抽象编程，让我们可以继承Request实现自己对response的解析方式(意味着处理volley为我们提供的StringRequest类等，我们自定义request)

2，重试策略，网络请求可能因为网络原因失败(例如手机断网了)，volley为我们提供了重试策略

3，终止请求，例如请求数据途中，我们希望终止该请求

4，request在队列中优先级的问题，例如我们有的请求比较紧迫，就应该排在队列的前面

5，重复请求的问题，利用有多个相同的request在队列之中，请求到其中一个，其他的可能就不必请求了，直接从缓存中取

6，异常的处理，例如io,403,402等授权错

7，地址重定向处理

8，网络问题的处理，例如我们断网了，volley使用了network这个类来处理这一类问题

9，使用HttpClient还是url.openConnection()去请求数据呢？

10，缓存的读取和存储，我们请求到网络数据以后，可以存入本地缓存

11，如何设置请求日志来记录请求信息，用于调试？

12，对于缓存写入和读取的效率优化

13，图片请求的处理

现在就让我们来小试牛刀，先来看Volley这个类，Volley作为整个框架的入口，其实就是创建了一个RequestQueue队列

public class Volley {  
  
    /**  
     * Default on-disk cache directory. 
     * 默认缓存目录名  
     */  
    private static final String DEFAULT_CACHE_DIR = "volley";  
  
    /** 
     * 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. 
     * 硬盘缓存最大值，-1则默认 
     * @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) {  
        }  
  
        if (stack == null) {//如果没有限定stack  
            if (Build.VERSION.SDK_INT >= 9) {//adk版本在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));  
            }  
        }  
  
        Network network = new BasicNetwork(stack);  
          
        RequestQueue queue;  
        if (maxDiskCacheBytes <= -1)//小于等于-1,则默认值  
        {  
            // No maximum size specified  
            queue = new RequestQueue(new DiskBasedCache(cacheDir), network);  
        }  
        else  
        {  
            // Disk cache size specified  
            queue = new RequestQueue(new DiskBasedCache(cacheDir, maxDiskCacheBytes), network);  
        }  
  
        queue.start();  
  
        return queue;  
    }

可以看到，Volley的newRequestQueue()方法里面，根据版本创建了stack(分别是HurlStack和HttpClientStack)。至于不同adk版本会创建不同的stack，是由于android的版本原因，在9以上版本使用HurlStack比HttpClientStack更加好。

然后创建了网络类BasicNetwork，缓存类DiskBasedCache，然后使用这两个来创建RequestQueue对象。

或许现在大家还不明白这两个类的作用，大家只需要记得创建RequestQueue需要这两个类就可以了。

OK，作为本专栏的开篇文章，主要是为大家提供阅读的兴趣和思路。在接下来的文章里面，我就会结合具体的源代码，来说明volley的具体实现。

转载于:https://www.cnblogs.com/aprz512/p/5316673.html