Glide核心设计二:缓存管理

原文链接：Glide核心设计二:缓存管理

引言

Glide作为一个优秀的图片加载框架，缓存管理是必不可少的一部分，这篇文章主要通过各个角度、从整体设计到代码实现，深入的分析Glide的缓存管理模块，力求在同类分析Glide缓存的分析文章中脱颖而出。关于Glide的生命周期绑定，可查看Glide系列文章Glide核心设计一：皮皮虾，我们走。

前提

1. 本文分析Glide缓存管理，将以使用Glide加载网络图片为例子，如加载本地图片、Gif资源等使用不是本文的重点。因不管是何种使用方式，缓存模块都是一样的，只抓住网络加载图片这条主线，逻辑会更清晰。
2. 本文将先给出Glide缓存管理整体设计的结论，然后再分析源码。

整体设计

缓存类型

Glide的缓存类型分为两大类，一类是Resource缓存，一类是Bitmap缓存。

Resource缓存

为什么需要缓存图片Resource，很好理解，因为图片从网络加载，将图片缓存到本地，当需要再次使用时，直接从缓存中取出而无需再次请求网络。

三层缓存

Glide在缓存Resource使用三层缓存，包括：

1. 一级缓存：缓存被回收的资源，使用LRU算法（Least Frequently Used，最近最少使用算法）。当需要再次使用到被回收的资源，直接从内存返回。
2. 二级缓存：使用弱引用缓存正在使用的资源。当系统执行gc操作时，会回收没有强引用的资源。使用弱引用缓存资源，既可以缓存正在使用的强引用资源，也不阻碍系统需要回收无引用资源。
3. 三级缓存：磁盘缓存。网络图片下载成功后将以文件的形式缓存到磁盘中。

Bitmap缓存

Bitmap所占内存大小

Bitmap所占的内存大小由三部分组成：图片的宽度分辨率、高度分辨率和Bitmap质量参数。公式是：Bitmap内存大小 = (宽pix长pix)质量参数所占的位数。单位是字节B。

Bitmap压缩质量参数

质量参数决定每一个像素点用多少位(bit)来显示：

1. ALPHA_8就是Alpha由8位组成(1B)
2. ARGB_4444就是由4个4位组成即16位(2B)
3. ARGB_8888就是由4个8位组成即32位(4B)
4. RGB_565就是R为5位，G为6位，B为5位共16位(2B)

Glide默认使用RGB_565，比系统默认使用的ARGB_8888节省一半的资源，但RGB_565无法显示透明度。
举个例子:在手机上显示100pix*200pix的图片，解压前15KB，是使用Glide加载(默认RGB_565)Bitmap所占用的内存是：(100x200)x2B = 40000B≈40Kb,比以文件的形成存储的增加不少，因为png、jpg等格式的图片经过压缩。正因为Bitmap比较消耗内存，例如使用Recyclerview等滑动控件显示大量图片时，将大量的创建和回收Bitmap,导致内存波动影响性能。

Bitmap缓存算法

在Glide中，使用BitmapPool来缓存Bitmap,使用的也是LRU算法。当需要使用Bitmap时，从Bitmap的池子中取出合适的Bitmap,若取不到合适的，则再新创建。当Bitmap使用完后，不直接调用Bitmap.recycler()回收，而是放入Bitmap的池子。

缓存的Key类型

Glide的缓存使用的形式缓存，Resource和Bitmap都是作为Value的部分，将value存储时，必须要有一个Key标识缓存的内容，根据该Key可查找、移除对应的缓存。

1. 从对比中可看出，Resource三层缓存所使用的key的构造形式是一样的，包括图片id(图片的Url地址),宽高等参数来标识。对于其他参数，举一个例子理解：图片资源从网络加载后，经过解码(decode)、缓存到磁盘、从磁盘中取出、变换资源（加圆角等,transformation）、磁盘缓存变换后的图片资源、转码(transcode)显示。
2. Bitmap的缓存Key的构造相对简单得多,由长、宽的分辨率以及图片压缩参数即可唯一标示一个回收的Bitmap。当需要使用的bitmap时，在BitmapPool中查找对应的长、宽和config都一样的Bitmap并返回，而无需重新创建。

Resource缓存流程

Resource包括三层缓存，通过流程图看它们之间的关系：

因为内存缓存优于磁盘缓存，所以当需要使用资源时，先从内存缓存中查找(一级缓存和二级缓存都是内存缓存,其功能不一样，一级缓存用于在内存中缓存不是正在使用的资源，二级缓存是保存正在使用的资源)，再从磁盘缓存中查找。若都找不到，则从网络加载。

滑动控件多图的性能优化

不论是Resource还是Bitmap缓存，若显示的仅是部分照片，并且不存在频繁使用的场景，则使用Glide没有太大的优势。设计缓存的目的就是为了在重复显示时，更快、更省的显示图片资源。Glide有针对ListView、Recyclerview等控件加载多图时进行优化。此处讨论最常见的场景：Recyclerview显示多图，简略图如下。

如上图所示，当图5划入界面时，会复用图一的Item,设置新的图片之前，会先清空原有图片的资源，清空时会把Resource资源放入一级缓存待将来复用，同时会将回收的Bitmap放入BitmapPool中；当图5向下隐藏，图一出现时，图5的资源会放到一级缓存中，图一的资源则从一级缓存中取出，无须重新网络请求，同时所需要的Bitmap也无须重新创建，直接复用。

LRU算法

BitmapPool的LRU算法流程图如下：

类图

在进行代码分析前，先给出跟Glide缓存管理相关的类图(省略类的大部分变量和方法)。

Glide缓存管理类图大图地址

代码实现

根据以上的Glide缓存管理的结论及类图，可自主跟源码，跳过以下内容。

Glide.with(Context).load(String).into(ImageView)

Glide.with(Context)

返回RequestManager,主要实现和Fragment、Activity生命周期的绑定,详情请看Glide核心设计一：皮皮虾，我们走。

.load(String)

RequestManager的load(String)方法返回DrawableTypeRequest，根据图片地址返回一个用于创建图片请求的Request的Builder,代码如下：

public DrawableTypeRequest load(String string) {
        return (DrawableTypeRequest) fromString().load(string); //调用fromString()和load()方法
    }

fromString()方法调用loadGeneric()方法，代码如下：

public DrawableTypeRequest fromString() {
       return loadGeneric(String.class); 
   }

 private  DrawableTypeRequest loadGeneric(Class modelClass) {
        ModelLoader streamModelLoader = Glide.buildStreamModelLoader(modelClass, context);
        ModelLoader fileDescriptorModelLoader =
                Glide.buildFileDescriptorModelLoader(modelClass, context);
        if (modelClass != null && streamModelLoader == null && fileDescriptorModelLoader == null) {
            throw new IllegalArgumentException("Unknown type " + modelClass + ". You must provide a Model of a type for"
                    + " which there is a registered ModelLoader, if you are using a custom model, you must first call"
                    + " Glide#register with a ModelLoaderFactory for your custom model class");
        }

        return optionsApplier.apply(  //传递的参数中创建了一个DrawableTypeRequest并返回该对象
                new DrawableTypeRequest(modelClass, streamModelLoader, fileDescriptorModelLoader, context,
                        glide, requestTracker, lifecycle, optionsApplier));  
    }

DrawableTypeRequest的load()方法如下:

@Override
   public DrawableRequestBuilder load(ModelType model) {
       super.load(model);
       return this;
   }

DrawableTypeRequest父类是DrawableRequestBuilder，父类的父类是GenericRequestBuilder，调用super.load()方法如下：

public GenericRequestBuilder load(ModelType model) {
       this.model = model;
       isModelSet = true;
       return this;
   }

以上代码可知，缓存管理的主要实现代码并不在.load(Sting)代码，接下来继续分析.into(ImageView)代码。

.into(ImageView)

GenericRequestBuilder的into(ImageView)代码如下：

public Target into(ImageView view) {
        Util.assertMainThread();
        if (view == null) { 
            throw new IllegalArgumentException("You must pass in a non null View");
        }

        if (!isTransformationSet && view.getScaleType() != null) {
            switch (view.getScaleType()) {  //根据图片的scaleType做相应处理
                case CENTER_CROP:
                    applyCenterCrop();
                    break;
                case FIT_CENTER:
                case FIT_START:
                case FIT_END:
                    applyFitCenter();
                    break;
                //$CASES-OMITTED$
                default:
                    // Do nothing.
            }
        }
        //调用buildImageViewTarget()方法创建了一个Target类型的对象
        return into(glide.buildImageViewTarget(view, transcodeClass));  
    }

以上代码主要有两个功能：

1. 根据ScaleType进行图片的变换
2. 将ImageView转换成一个Target

继续查看into(Target)的代码：

public > Y into(Y target) {
       Util.assertMainThread();
       if (target == null) {
           throw new IllegalArgumentException("You must pass in a non null Target");
       }
       if (!isModelSet) {
           throw new IllegalArgumentException("You must first set a model (try #load())");
       }

       Request previous = target.getRequest();  //获取请求体Request

       if (previous != null) { //若ImageView是复用过的，则previous不为空
           previous.clear(); //调用clear()方法清空ImageView上的图片资源，此方法会将回收的Resource放入内存缓存中，并不在内存中清空该资源。
           requestTracker.removeRequest(previous); //移除老的请求
           previous.recycle(); //回收Request使用
       }

       Request request = buildRequest(target); //获取新的Request
       target.setRequest(request); //将新的request设置到target中
       lifecycle.addListener(target); //添加生命周期的监听
       requestTracker.runRequest(request); //启动Request

       return target;
   }

以上代码，主要将图片加载的Request绑定到Target中，若原有Target具有旧的Request,得先处理旧的Request,再绑定上新的Request。target.setRequest()和target.getRequest()最终会调用ViewTarget的setRequest()方法和getRequest()方法，代码如下：

public void setRequest(Request request) {
        setTag(request);
    }
    private void setTag(Object tag) {
                 if (tagId == null) {
                     isTagUsedAtLeastOnce = true;
                     view.setTag(tag);//调用view的setTag方法，将Request和view做绑定
                 } else {
                     view.setTag(tagId, tag);//调用view的setTag方法，将Request和view做绑定
                 }
    }
    public Request getRequest() {
                    Object tag = getTag(); //获取view 的tag
                    Request request = null;
                    if (tag != null) {
                        if (tag instanceof Request) {  //若该tag是Request的一个实例
                            request = (Request) tag; 
                        } else {  //用户不能给view设置tag，因为该view的tag要用于保存Glide的Request对象，否则抛出异常
                            throw new IllegalArgumentException("You must not call setTag() on a view Glide is targeting");
                        }
                    }
                    return request;
            }

以上代码可知，Request通过setTag的方式和View进行绑定，当View是复用时，则Request不为空，通过Request可对原来的资源进行缓存与回收。此处通过View的setTag()方法绑定Request,可谓妙用。

以上代码创建了一个Request,requestTracker.runRequest(request);启动了Request，调用Request的begin()方法,该Request实例是GenericRequest，begin()代码如下：

@Override
    public void begin() {
        startTime = LogTime.getLogTime();
        if (model == null) {
            onException(null);
            return;
        }

        status = Status.WAITING_FOR_SIZE; //设置等待图片size的宽高状态
        if (Util.isValidDimensions(overrideWidth, overrideHeight)) { //必须要确定图片的宽高，确定了则调用onSizeReady
            onSizeReady(overrideWidth, overrideHeight);
        } else { //设置回调，监听界面的绘制，当检测到宽高有效时，回调onSizeReady方法
            target.getSize(this);
        }

        if (!isComplete() && !isFailed() && canNotifyStatusChanged()) {
            target.onLoadStarted(getPlaceholderDrawable());
        }
        if (Log.isLoggable(TAG, Log.VERBOSE)) {
            logV("finished run method in " + LogTime.getElapsedMillis(startTime));
        }
    }

加载图片前，必须要确定图片的宽高，因为需要根据确定的宽高来获取资源。onSizeReady代码如下：

@Override
    public void onSizeReady(int width, int height) {
        if (Log.isLoggable(TAG, Log.VERBOSE)) {
            logV("Got onSizeReady in " + LogTime.getElapsedMillis(startTime));
        }
        if (status != Status.WAITING_FOR_SIZE) {//宽高没准备好，返回
            return;
        }
        status = Status.RUNNING;  //状态改为加载运行中

        width = Math.round(sizeMultiplier * width);
        height = Math.round(sizeMultiplier * height);

        ModelLoader modelLoader = loadProvider.getModelLoader();
        final DataFetcher dataFetcher = modelLoader.getResourceFetcher(model, width, height);

        if (dataFetcher == null) {
            onException(new Exception("Failed to load model: \'" + model + "\'"));
            return;
        }
        ResourceTranscoder transcoder = loadProvider.getTranscoder();
        if (Log.isLoggable(TAG, Log.VERBOSE)) {
            logV("finished setup for calling load in " + LogTime.getElapsedMillis(startTime));
        }
        loadedFromMemoryCache = true;
        //真正的加载任务交给engine
        loadStatus = engine.load(signature, width, height, dataFetcher, loadProvider, transformation, transcoder,
                priority, isMemoryCacheable, diskCacheStrategy, this);
        loadedFromMemoryCache = resource != null;
        if (Log.isLoggable(TAG, Log.VERBOSE)) {
            logV("finished onSizeReady in " + LogTime.getElapsedMillis(startTime));
        }
    }

以上代码可知，在确定宽高后，将图片加载的任务交给类型为Engine的对象engine,并调用其load方法，代码如下:

public  LoadStatus load(Key signature, int width, int height, DataFetcher fetcher,
           DataLoadProvider loadProvider, Transformation transformation, ResourceTranscoder transcoder,
           Priority priority, boolean isMemoryCacheable, DiskCacheStrategy diskCacheStrategy, ResourceCallback cb) {
       Util.assertMainThread();
       long startTime = LogTime.getLogTime();

       final String id = fetcher.getId(); //该id为图片的网络地址
       //缓存key的组成部分，使用工厂模式
       EngineKey key = keyFactory.buildKey(id, signature, width, height, loadProvider.getCacheDecoder(),
               loadProvider.getSourceDecoder(), transformation, loadProvider.getEncoder(),
               transcoder, loadProvider.getSourceEncoder());
       //使用一级缓存，从回收的内存缓存中查找EngineResource
       EngineResource cached = loadFromCache(key, isMemoryCacheable);
       if (cached != null) { //命中则直接返回
           cb.onResourceReady(cached);
           if (Log.isLoggable(TAG, Log.VERBOSE)) {
               logWithTimeAndKey("Loaded resource from cache", startTime, key);
           }
           return null;
       }
       //从二级缓存中查找
       EngineResource active = loadFromActiveResources(key, isMemoryCacheable);
       if (active != null) {//命中则直接返回
           cb.onResourceReady(active);
           if (Log.isLoggable(TAG, Log.VERBOSE)) {
               logWithTimeAndKey("Loaded resource from active resources", startTime, key);
           }
           return null;
       }

       EngineJob current = jobs.get(key);
       if (current != null) {//该任务已经在执行，只需要添加回调接口，在任务执行完后调用接口告知即可
           current.addCallback(cb);
           if (Log.isLoggable(TAG, Log.VERBOSE)) {
               logWithTimeAndKey("Added to existing load", startTime, key);
           }
           return new LoadStatus(cb, current);
       }
       //一级缓存和二级缓存都不命中的情况下，启动新的任务
       EngineJob engineJob = engineJobFactory.build(key, isMemoryCacheable);//创建EngineJob
       DecodeJob decodeJob = new DecodeJob(key, width, height, fetcher, loadProvider, transformation,
               transcoder, diskCacheProvider, diskCacheStrategy, priority); //创建DecodeJob
       EngineRunnable runnable = new EngineRunnable(engineJob, decodeJob, priority); 
       jobs.put(key, engineJob);
       engineJob.addCallback(cb);
       engineJob.start(runnable); //启动EngineRunnable runnable，使用线程池FifoPriorityThreadPoolExecutor管理

       if (Log.isLoggable(TAG, Log.VERBOSE)) {
           logWithTimeAndKey("Started new load", startTime, key);
       }
       return new LoadStatus(cb, engineJob);
   }

分析至此，我们终于看到实现一级缓存和二级缓存的相关代码，可以猜测三级缓存的实现跟EngineRunnable有关。engineJob.start(runnable)会启动EngineRunnable的start()方法。代码如下：

@Override
   public void run() {
       if (isCancelled) {
           return;
       }

       Exception exception = null;
       Resource resource = null;
       try {
           resource = decode();  //调用decode()方法
       } catch (Exception e) {
           if (Log.isLoggable(TAG, Log.VERBOSE)) {
               Log.v(TAG, "Exception decoding", e);
           }
           exception = e;
       }

       if (isCancelled) { //请求被取消
           if (resource != null) {
               resource.recycle();
           }
           return;
       }

       if (resource == null) { //加载失败
           onLoadFailed(exception);
       } else { //加载成功
           onLoadComplete(resource);
       }
   }

查看decode()方法如下：

private Resource decode() throws Exception {
        if (isDecodingFromCache()) {
            return decodeFromCache();  //从磁盘缓存中获取
        } else {
            return decodeFromSource(); //从网络中获取资源
        }
    }

至此，我们看到磁盘缓存和网络请求获取图片资源的代码。查看onLoadFailed()的代码逻辑可知，默认先从磁盘获取，失败则从网络获取。

BitmapPool缓存逻辑

以上就是Resource三层缓存的代码，接下来看BitmapPool的缓存实现代码。
在decodeFromSource()的代码中，会返回一个类型为BitmapResource的对象。在RecyclerView的例子中，当ImageView被复用时，会在Tag中取出Request,调用request.clear()代码。该方法最终会调用BitmapResource的recycler()方法，代码如下：

public void recycle() {
       if (!bitmapPool.put(bitmap)) {
           bitmap.recycle();
       }
   }

该代码调用bitmapPool.put(bitmap)，bitmapPool的实例是LruBitmapPool代码如下:

public synchronized boolean put(Bitmap bitmap) {
       if (bitmap == null) {
           throw new NullPointerException("Bitmap must not be null");
       }
       if (!bitmap.isMutable() || strategy.getSize(bitmap) > maxSize || !allowedConfigs.contains(bitmap.getConfig())) {
           if (Log.isLoggable(TAG, Log.VERBOSE)) {
               Log.v(TAG, "Reject bitmap from pool"
                       + ", bitmap: " + strategy.logBitmap(bitmap)
                       + ", is mutable: " + bitmap.isMutable()
                       + ", is allowed config: " + allowedConfigs.contains(bitmap.getConfig()));
           }
           return false;
       }

       final int size = strategy.getSize(bitmap);
       strategy.put(bitmap);//该strategy的实例是Lru算法
       tracker.add(bitmap); //log跟踪

       puts++; //缓存的bitmap数量标记加一
       currentSize += size;//缓存bitmap的总大小

       if (Log.isLoggable(TAG, Log.VERBOSE)) {
           Log.v(TAG, "Put bitmap in pool=" + strategy.logBitmap(bitmap));
       }
       dump(); //仅用于Log

       evict();  //判断是否超出指定的内存大小，若超出则移除
       return true;
   }

可以看出，正常情况下调用put方法返回true，证明缓存该Bitmap成功，缓存成功则不调用bitmap.recycler()方法。当需要使用Bitmap时，先从Bitmap中查找是否有符合条件的Bitmap。在RecyclerView中使用Glide的例子中，将大量复用宽高及Bitmap.Config都相等的Bitmap,极大的优化系统内存性能，减少频繁的创建回收Bitmap。

小结

Glide的缓存管理至此就分析完了，主要抓住Resource和Bitmap的缓存来讲解。在代码的阅读中还发现了工厂、装饰者等设计模式。Glide的解耦给开发者提供很大的便利性，可根据自身需求设置缓存参数，例如默认Bitmap.Config、BitmapPool缓存大小等。最后，针对Glide的缓存设计，提出几点小建议：

1. Glide虽然默认使用的Bitmap.Config是RGB_565,但在进行transform(例如圆角显示图片)时往往默认是ARGB_8888,因为RGB_565没有透明色，此时可重写圆角变换的代码，继续使用RGB_565，同时给canvas设置背景色。
2. BitmapPool缓存的Bitmap大小跟Bitmap的分辨率也有关系，在加载图片的过程中，可调用.override(width, height)指定图片的宽高，再调整ImageView控件的大小适应布局。
3. Resource的一级缓存和Bitmap都是内存缓存，虽然极大的提升了复用，但也会导致部分内存在系统执行GC时无法释放。若内存达到手机性能瓶颈，应在合适的时机调用Glide.get(this).clearMemory()释放内存。

Glide核心设计一：皮皮虾，我们走

发表于 2017-02-20    |   暂无评论    |   阅读次数 130

原文链接：Glide核心设计一：皮皮虾，我们走

引言

皮皮虾，又名虾姑，是淡水中的强者。其头部的两个锤节，可以轻易破坏贝类的外壳，身体上的步足可以保证快速移动。这些优秀的品质，使它被表情包盯上。

Glide，作为Android最优秀的图片加载框架之一，能和Activity和Fragment的生命周期绑定，是区别于其它网络框架的核心特征，也是本文分析的重点。

我们将此特征和皮皮虾表情包做一个类比：

图片网络请求紧跟Activity、Fragment的生命周期，当页面不可交互时自动停止加载，当回到可交互状态时，继续加载。就像表情包（Activity、Fragment）控制皮皮虾（图片请求）一样。

框架设计

简单使用

Glide.with(Context).load(String).into(ImageView)可实现从网络中获取图片并展示到ImageView当中。其中和页面作生命周期绑定的主要入口是Glide.with(Context)。按照一般的分析逻辑应该先分析源码，才得出结论，但因一入源码深似海，不利于整体把握，所以先给出结论。Glide.with(Context)返回的是一个RequestManager,我们来看RequestManager的类的说明注释。

A class for managing and starting requests for Glide. Can use activity, fragment and connectivity lifecycle events to intelligently stop, start, and restart requests. Retrieve either by instantiating a new object, or to take advantage built in Activity and Fragment lifecycle handling, use the static Glide.load methods with your Fragment or Activity.

由此可知，该类就是用于将请求和Activity或Framgent的生命周期做绑定。

类图

将和生命周期相关的类图如下（省略大部分类的变量和方法）：

类的简单介绍

1. RequestManagerRetriever:该类用于创建RequestManager或在Activity、Fragment中找出已创建的RequestManager，RequestManagerRetriever是一个单例。
2. RequestManagerFragment:继承Fragment,不可见，仅用于保存RequestManager，还有一个SupportRequestManagerFragment继承v4包的Fragment,功能类似。
3. LifecycleListener：用于监听Activity、Fragment的生命周期事件。
4. Lifecycle：用于添加LifecycleListener。
5. ActivityFragmentLifecycle：实现Livecycle接口，用于通知Activity、Fragment的生命周期事件。
6. RequestTracker：该类用于跟踪、取消和重新启动执行中、已完成和失败的请求。
7. ConnectivityMonitor： 监听网络事件的接口，当网络状态发生变化时，影响网络请求状态，继承LifecycleListener。
8. DefaultConnectivityMonitor： ConnectivityMonitor的实现类，实现监听网络状态的逻辑。
9. RequestManagerConnectivityListener： 实现ConnectivityListener接口，将网络事件传递给RequestTracker。

类的联系

以上对各类有一个简单的了解，接下来将重点讲清楚各类之间的联系。整个生命周期的绑定分为四部分。

1. 调用Glide.with(Context)，根据传入的Context类型创建RequestManager。Context可以为Activity、Fragment和Application。
2. 在传入的参数Activity、或者Fragment中，添加一个不可见的Fragment,监听不可见Fragment的生命周期并将该事件传递给和Fragment一一绑定的RequestManager。
3. RequestManager监听到生命事件后，管理图片请求做出响应。
4. 监听当网络从无到有时，RequestManager要重新启动图片请求。

代码解读

根据以上内容可直接跟代码可跳过以下内容，印象更加深刻。

第一部分:Glide.with(Context）

public static RequestManager with(Context context) {
        RequestManagerRetriever retriever = RequestManagerRetriever.get();
        return retriever.get(context);
    }
`

调用RequestManagerRetriever的get方法如下：

public RequestManager get(Context context) {
        if (context == null) {
            throw new IllegalArgumentException("You cannot start a load on a null Context");
        } else if (Util.isOnMainThread() && !(context instanceof Application)) {
            if (context instanceof FragmentActivity) {  //传入的是Fragment
                return get((FragmentActivity) context);
            } else if (context instanceof Activity) {  //传入的是Acitivity
                return get((Activity) context);
            } else if (context instanceof ContextWrapper) { //传入的是Application
                return get(((ContextWrapper) context).getBaseContext());
            }
        }

        return getApplicationManager(context);
    }

以传入参数为Activity类型为例，代码如下：

public RequestManager get(Activity activity) {
      if (Util.isOnBackgroundThread() || Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
          return get(activity.getApplicationContext());
      } else {
          assertNotDestroyed(activity);
          android.app.FragmentManager fm = activity.getFragmentManager();   //获取FragmentManager
          return fragmentGet(activity, fm); 
      }
  }

主要调用fragmentGet方法，代码如下：

RequestManager fragmentGet(Context context, android.app.FragmentManager fm) {
       RequestManagerFragment current = getRequestManagerFragment(fm); 
       RequestManager requestManager = current.getRequestManager();  //根据RequestManagerFragment获取RequestManager，一个RequestManagerFragment包含一个RequestManager
       if (requestManager == null) {  //若RequestManager为空，则新建一个并且设置到RequestManagerFragment中
           requestManager = new RequestManager(context, current.getLifecycle(), current.getRequestManagerTreeNode());
           current.setRequestManager(requestManager);
       }
       return requestManager;
   }

getRequestManagerFragment(fm)函数主要是根据FragmentManager获取Fragment,代码如下：

RequestManagerFragment getRequestManagerFragment(final android.app.FragmentManager fm) {
       RequestManagerFragment current = (RequestManagerFragment) fm.findFragmentByTag(FRAGMENT_TAG);  //通过Tag查找
       if (current == null) { //若为空，从缓存pendingRequestManagerFragments中查找
           current = pendingRequestManagerFragments.get(fm);
           if (current == null) { //缓存中也不存在，则新建一个RequestManagerFragment，并且添加到页面中。
               current = new RequestManagerFragment();
               pendingRequestManagerFragments.put(fm, current);
               fm.beginTransaction().add(current, FRAGMENT_TAG).commitAllowingStateLoss();
               handler.obtainMessage(ID_REMOVE_FRAGMENT_MANAGER, fm).sendToTarget();
           }
       }
       return current;
   }

以上就是根据传入的Context类型创建RequestManager的代码部分。

第二部分：监听不可见Fragment的生命周期并传递给RequestManager

添加不可见Fragment的目的，就是因为该Fragment和父类的Activity具有同样的生命周期，无须改动原有Activity的代码，即可实现生命周期的监听。
RequestManagerFragment生命周期相关的代码如下：

@Override
   public void onStart() {
       super.onStart();
       lifecycle.onStart(); //执行lifecycle的onStart方法
   }

   @Override
   public void onStop() {
       super.onStop();
       lifecycle.onStop();//执行lifecycle的onStop方法
   }

   @Override
   public void onDestroy() {
       super.onDestroy();
       lifecycle.onDestroy();//执行lifecycle的onDestroy方法
   }

可以看出，Fragment的声明周期的监听都转移到类型是ActivityFragmentLifecycle的变量lifecycle中的对应方法执行。查看ActivityFragmentLifecycle的代码：

void onStart() {
      isStarted = true;
      //循环set集合lifecycleListeners中所有LifecycleListener，执行对应的onStart
      for (LifecycleListener lifecycleListener : Util.getSnapshot(lifecycleListeners)) {
          lifecycleListener.onStart();
      }
  }

 //省略onStop()和onDestroy()方法，和onStart()方法类似。

set集合的LifecycleListener是如何添加进去的，看ActivityFragmentLifecycle中的代码：

@Override
    public void addListener(LifecycleListener listener) {
        lifecycleListeners.add(listener);
        if (isDestroyed) {//如果当前页面已经被destroy，则调用对应的onDestroy
            listener.onDestroy();
        } else if (isStarted) {//如果当前页面已经开启，则调用对应的onStart
            listener.onStart();
        } else {  //其他情况调用onStop方法
            listener.onStop();
        }
    }

addListener(LifecycleListener listener)方法是接口Lifecycle的方法。RequestManagerFragment提供一个公有方法：

ActivityFragmentLifecycle getLifecycle() {
        return lifecycle;
    }

回看第一部分创建RequestManager时:

requestManager = new RequestManager(context, current.getLifecycle(), current.getRequestManagerTreeNode());

RequestManagerFragment中的Lifecycle作为RequestManager的构造函数的参数传递给RequestManager。RequestManager构造函数如下：

RequestManager(Context context, final Lifecycle lifecycle, RequestManagerTreeNode treeNode,
           RequestTracker requestTracker, ConnectivityMonitorFactory factory) {
       this.context = context.getApplicationContext();
       this.lifecycle = lifecycle;
       this.treeNode = treeNode;
       this.requestTracker = requestTracker;
       this.glide = Glide.get(context);
       this.optionsApplier = new OptionsApplier();
       //监听网络变化的类
       ConnectivityMonitor connectivityMonitor = factory.build(context,
               new RequestManagerConnectivityListener(requestTracker));

       // If we're the application level request manager, we may be created on a background thread. In that case we
       // cannot risk synchronously pausing or resuming requests, so we hack around the issue by delaying adding
       // ourselves as a lifecycle listener by posting to the main thread. This should be entirely safe.
       if (Util.isOnBackgroundThread()) {
           new Handler(Looper.getMainLooper()).post(new Runnable() {
               @Override
               public void run() {
                   //在主线程中将当前类实现的LifecycleListener添加到lifecycle中。
                   lifecycle.addListener(RequestManager.this);
               }
           });
       } else {
           //在主线程中将当前类实现的LifecycleListener添加到lifecycle中。
           lifecycle.addListener(this);
       }
       lifecycle.addListener(connectivityMonitor);
   }

由此可见，lifecycle添加的就是RequestManager实现的LifecycleListener接口。

第三部分：RequestManager实现LifecycleListener

接着查看RequestManager实现LifecycleListener的方法：

@Override
   public void onStart() {
       // onStart might not be called because this object may be created after the fragment/activity's onStart method.
       resumeRequests();
   }

   @Override
   public void onStop() {
       pauseRequests();
   }

   @Override
   public void onDestroy() {
       requestTracker.clearRequests();
   }

继续进入resumeRequests()、pauseRequests()和requestTracker.clearRequests()方法可知，都是调用RequestTracker相应的方法，RequestTracker类包含一个集合的Request，该集合包含一个Activity获取一个
Fragment的所以图片请求，将根据RequestManagerFragment的生命周期，统一管理图片请求。

第四部分：监听网络状态并作出相应

RequestManager的构造函数有如下方法：

 //省略部分代码...
 //监听网络变化的类
 ConnectivityMonitor connectivityMonitor = factory.build(context,
         new RequestManagerConnectivityListener(requestTracker));
 //省略部分代码...
lifecycle.addListener(connectivityMonitor);         
 //省略部分代码...

以上代码可看出，ConnectivityMonitor也实现了LifecycleListener。继续跟踪代码发现，factory的实例是ConnectivityMonitorFactory，在该工厂中会检查网络权限，同时创建ConnectivityMonitor的实例DefaultConnectivityMonitor。LifecycleListener接口的实现如下：

@Override
   public void onStart() {
       register(); //register（）方法为注册广播监听网络变化
   }

   @Override
   public void onStop() {
       unregister(); //解除监听广播
   }

   @Override
   public void onDestroy() {
       // Do nothing.
   }

广播接收器代码如下：

private final BroadcastReceiver connectivityReceiver = new BroadcastReceiver() {
      @Override
      public void onReceive(Context context, Intent intent) {
          boolean wasConnected = isConnected;
          isConnected = isConnected(context);
          if (wasConnected != isConnected) {  //当网络状态发生变化时，才调用listener.onConnectivityChanged()方法
              listener.onConnectivityChanged(isConnected);
          }
      }
  };

ConnectivityListener 的实例的类型是RequestManager的内部类，代码如下：

private static class RequestManagerConnectivityListener implements ConnectivityMonitor.ConnectivityListener {
       private final RequestTracker requestTracker;

       public RequestManagerConnectivityListener(RequestTracker requestTracker) {
           this.requestTracker = requestTracker;
       }

       @Override
       public void onConnectivityChanged(boolean isConnected) {
           if (isConnected) { //如果当前状态是链接状态
               requestTracker.restartRequests(); //重新开启图片请求
           }
       }
   }

小结

以上就是Glide实现图片加载和Activity、Fragment生命周期绑定的全部分析。会发现使用了观察者模式和工厂模式进行解耦，其中创建一个不可见的Fragment设置到需要被监控生命周期的Activity、Fragment中，最为精彩。接下来将分析Glide核心设计二：图片缓存。敬请期待。

送一个内存泄漏给2016的记几

发表于 2016-12-23    |   2条评论    |   阅读次数 139

原文链接：送一个内存泄漏给2016的记几

背景

年底了，看公司项目的友盟的bug列表，发现java.lang.OutOfMemoryError的问题不少，也该是时候还了。

问题描述

在解决内存泄漏的过程中，遇到一个静态变量导致的内存泄漏，关键是这代码还是自己敲的，明明已经使用弱引用，为什么还是内存泄漏了。看代码：

public class RtHttp {

    public static RtHttp instance = new RtHttp();
    public Context context;

    public static void with(Context context){
        WeakReference wrContext = new WeakReference(context);
        instance.context = wrContext.get();
    }
}

RtHttp为封装客户端网络框架请求的入口，假设两个条件：

1. 其中传入的Context对象只能是Activity，不能使用context.getApplicationContext()（因为此RtHttp还封装了显示网络加载对话框的代码）。
2. 不能在Activity onDestroy()方法中调用RtHttp.instance.context = null;

已经使用了弱引用，为什么还是内存泄漏呢？
记几想不通，还到谷歌搜索使用弱引用依然内存泄漏，WeakReference useless,无果。

如果你已经看出问题了，请直接到评论吐槽。
如果你没看出问题，请把引用的文章看一遍。

总结

一个内存泄漏的问题，反映了Java基础不牢固，在学习知识和解决问题上也不够深入。一直想写一篇2016的总结，希望以此内存泄漏的问题为界，实现在2017的一个技术提升。

引用

Android 内存泄漏总结
Java内存、Android 内存泄漏
Java gc(垃圾回收机制)小结，以及Android优化建议
JVM GC垃圾回收机制

模拟服务器返回数据

发表于 2016-12-15    |   暂无评论    |   阅读次数 259

本篇文章已授权微信公众号 guolin_blog （郭霖）独家发布
原文链接：模拟服务器返回数据

背景

模拟服务器返回的数据，在以下场景具有实际意义：

和服务器开发协商好开发接口，但服务器API尚未部署，想接口定义好就进行开发；
服务器已部署，返回的数据不能测试到各种情况，希望返回期待数据测试边界情况；

如果客户端开发人员能不走服务器，通过模拟数据返回，能提升开发效率和程序质量。

实现思路

本文主要讲解两种实现方式：

1. 使用网络分析工具拦截客户端请求，并返回伪造数据。
   优点：无需改变客户端代码；不依赖客户端平台，android和ios都通用；
   缺点：依赖网络分析工具；调试相对不灵活；

2. 使用客户端网络框架拦截请求并返回。
   优点：返回数据由客户端代码决定，灵活易于调试；
   缺点：需要改变客户端代码；需要根据客户端网络框架进行响应处理，不同的网络框架处理不一样；

对于方案一，主要使用网络分析工具Charles进行拦截并返回，对于方案二，主要讲解使用OkHttp作为网络框架，利用拦截器机制实现模拟返回。

使用Charles模拟数据

准备条件

1. 客户端需要连接到和电脑同一个网络(手机连接电脑发出的wifi)
2. 官网下载安装

配置

配置方法参考Charles:移动端设备网络抓包
完成配置后，可以在Charles中检测到手机的网络请求和响应。

转接服务器地址

转接服务器地址是指，当客户端请求地址B时，本应该向指定的服务器请求数据，但Charles可拦截此ip地址，使不向服务器地址请求，并且返回另外一台服务器模拟的数据。
首先，我们来生成模拟返回数据的api接口；
打开mocky网址,输入想伪造Body数据，点击Generate my HTTP Response按钮生成http的url地址。

如图，当点击http://www.mocky.io/v2/58592298240000ba087c5a92 时，返回json格式的数据。
有了模拟数据的api地址，接着设置需要模拟的api接口。经过配置后，Charles可检测手机的网络请求，选择需要模拟返回数据的网络请求接口，右键选择Map Remote…
Map From为需要拦截的接口，Map To为模拟的api接口，此处我们填入http://www.mocky.io/v2/58592298240000ba087c5a92，如下图：

选择标题栏Tool工具图标，取消选择Map Remote,再勾选Map Remote，让设置的ip地址生效。此时，当客户端请求原地址时，都会返回模拟ip地址的数据，效果图如下：

小结

以上，使用Mocky网络和Charles工具实现模拟数据返回，无需改变客户端原有代码，但是，当需要改变客户端返回的数据时，则需要重新生成http模拟地址，再次设置Charles Map to内容。

自定义OkHttp Interceptor模拟返回

以下内容假设用户掌握OkHttp的简单使用，重点讲解自定义OkHttpInterceptor模拟返回数据。

OkHttp拦截器

如图，OkHttp可在Request和Response中设置任意个数的Intercepor(图中用圆圈标识)，对请求体和响应体进行处理。借助OkHttp Interceptor机制，创建一个MockIntercepor,模拟返回一个Response,虚线部分为模拟的Response。

代码实现

MockInterceptor代码如下：

public class MockInterceptor implements Interceptor{
    @Override
    public Response intercept(Chain chain) throws IOException {
        Gson gson = new Gson();
        Response response = null;
        Response.Builder responseBuilder = new Response.Builder()
                .code(200)
                .message("")
                .request(chain.request())
                .protocol(Protocol.HTTP_1_0)
                .addHeader("content-type", "application/json");
        Request request = chain.request();
        if(request.url().equals("http://url_whitch_need_to_mock")) { //拦截指定地址
            String responseString = "{\n" +    //模拟数据返回body
                    "\t\"code\": 200,\n" +
                    "\t\"message\": \"success\",\n" +
                    "\t\"data\": {}\n" +
                    "}";
            responseBuilder.body(ResponseBody.create(MediaType.parse("application/json"), responseString.getBytes()));//将数据设置到body中
            response = responseBuilder.build(); //builder模式构建response
        }else{
            response = chain.proceed(request);
        }
        return response;
    }
}

在debug模式下，将此Interceptor添加到网络请求的OkHttp中，即可对指定的api地址进行拦截，并且返回特定的数据。

小结

使用OkHttp的拦截机制，可实现改变部分代码则可模拟返回数据，返回的数据可在代码中设置，可使用工厂模式将模拟数据的生成变动代码放到Factory中。依赖网络请求框架，若原项目使用OkHttp或Retrofit作为网络框架,可轻易实现模拟接口。

引用

Charles:移动端设备网络抓包
利用charles模拟Http请求和响应
Hack Retrofit (2) 之 Mock Server
OkHttp Interceptor

创建OkHttp自定义Log

发表于 2016-12-10    |   暂无评论    |   阅读次数 27

原文链接：创建OkHttp自定义Log

背景

本文重点讲解如何在使用OkHttp作为网络请求框架的前提下，如何自定义一个适合自己项目的Http Log，从而提升网络Api开发、调试效率。

Http协议

只有对Http协议有基本的了解，才能更好的调试网络接口。

一个故事

男女主一次偶然的机会，开始信件传情，但他们的信件并不是直接寄给对方，而是先寄到某个地点A，由地点A的主人转发。（好吧，这是《北京遇上西雅图之不二情书》的情节）。我们来看男主发信的过程：

1. 先购买有效邮票；
2. 填写信件的收件人、收件地址等信息；
3. 把信件放到信封里寄出去。

显然，女主收到信后回复信件也是同样的流程。

类比

我们现在将Http协议的消息结构和故事主人公收发信的过程做一个类比：

下面是使用Fiddler工具抓取www.xitu.io的网络请求和响应图：

Http消息结构

由前面的分析可知，Http请求消息由三部分组成：

1. 请求行由3部分组成：①请求的方法,POST还是GET等；②请求路径；③Http协议
2. 请求头，每一行都是name:value的结构,包含各种来自请求客服端的信息
3. 请求体，提交给服务器的信息，GET方法没有此项。

Http响应体跟请求体格式大致一样。

1. 请求体有协议和响应码组成，200为响应成功
2. 响应头，每一行都是name:value的结构,包含各种来自服务器的信息
3. 响应体，返回客户端需要的数据

自定义LogInterceptor

OkHttp Interceptor

OkHttp的一大特点就是可以在发出请求体和收到响应体之间添加任意个数任意任意功能的拦截器，对请求体或者响应体进行操作。还是用《北京遇上西雅图之不二情书》的故事来说，那么地点A的主人就是充当拦截器的角色，在故事中他不仅转发信件，还阅读了信件的内容。

根据需求确定需要Log的信息

Log的信息和划分两类，一类是跟业务相关的信息，一类是与业务无关。

1. 业务相关包括：
   请求地址url;
   请求头：token、sessionId;
   请求体：POST提交的内容;
   响应头：token/sessionId;
   响应体：服务器返回数据;

2. 业务无关包括：
   网络状态码：200为正常反应;
   网络请求时间：从发出网络请求到响应所消耗的时间;
   网络协议:http1、http2等;
   网络Method：POST、GET等；
   不管是业务相关的数据还是业务无关的数据，都是来自于Http请求体和响应体的消息结构中。

Log效果图

以公司项目的测试服务器自动登录接口，log效果如下:

 POST
acid->1075
userId->-1
network code->200
url->http://mobileapi.app100688440.twsapp.com/app/open/open.do?ACID=1075&userId=-1&vendorId=7999&VERS=6.5.1&fromType=1110
time->84.473
request headers->sessionId: 
request->{"data":{"pagenum":0,"uid":-1,"flag":"00000000"},"requeststamp":"20161212151841836466"}
body->{"code":200,"responsestamp":"20161212151841836466","data":{"uid":-1,"nickname":"游客258","uploadUrl":"http://mobileapi.app100688440.twsapp.com/uploadservlet","wxUrl":"http://wx.app100688440.twsapp.com","isEmcee":0,"canLive":0,"goodnum":0,"index":{},"revGift":{},"msgRemind":{},"freshmanMission":{},"account":{},"onlineLimit":"600","userSecretKey":"brjefjzw37ocw46"}}

log解释:
POST:此接口使用POST方法；
acid:标识此接口的id,每个接口有唯一的acid，根据acid可查询到此接口的功能，例如此接口acid = 1075为自动登录接口；
userId:用户id
network code:返回200证明服务器响应成功；
url：此接口请求的url地址；
time:为响应时间，如果某接口响应时间过长，排除网络环境的原因，就可以跟服务端商量是否可优化；
request header：此项目需要传sessionId;
request:此处打印Post方法的请求体，若后台返回参数错误，检查此行log即可；
body:后台数据返回，采用json格式；

代码实现

/**
 * 添加Log
 */
public class LogInterceptor implements Interceptor {

    private static final String TAG = "LogInterceptor";
    private static final Charset UTF8 = Charset.forName("UTF-8"); //urf8编码

    @Override
    public Response intercept(Chain chain) throws IOException {  //实现Interceptor接口方法
        Log.d(TAG,"before chain,request()");
        Request request = chain.request();  //获取request
        String acid = request.url().queryParameter("ACID"); //在url中获取ACID的参数值；
        Response response;
        try {
            long t1 = System.nanoTime();
            response = chain.proceed(request); //OkHttp链式调用
            long t2 = System.nanoTime();
            double time = (t2 - t1) / 1e6d;   //用请求后的时间减去请求前的时间得到耗时

            String userId = request.url().queryParameter("userId");
            String type = "";
            if (request.method().equals("GET")) {    //判断Method类型
                type = "GET";
            } else if (request.method().equals("POST")) {
                type = "POST";
            } else if (request.method().equals("PUT")) {
                type = "PUT";
            } else if (request.method().equals("DELETE")) {
                type = "DELETE";
            }
            BufferedSource source = response.body().source();
            source.request(Long.MAX_VALUE); // Buffer the entire body.
            Buffer buffer = source.buffer();
            String logStr = "\n--------------------".concat(TextUtils.isEmpty(acid) ? "" : acid).concat("  begin--------------------\n")
                    .concat(type)
                    .concat("\nacid->").concat(TextUtils.isEmpty(acid) ? "" : acid)
                    .concat("\nuserId->").concat(TextUtils.isEmpty(userId) ? "" : userId)
                    .concat("\nnetwork code->").concat(response.code() + "")
                    .concat("\nurl->").concat(request.url() + "")
                    .concat("\ntime->").concat(time + "")
                    .concat("\nrequest headers->").concat(request.headers() + "")
                    .concat("request->").concat(bodyToString(request.body()))
                    .concat("\nbody->").concat(buffer.clone().readString(UTF8)); //响应体转String
            Log.i(TAG, logStr);
        } catch (Exception e) {
            Log.d(TAG,e.getClass().toString()+", error:acid = "+acid);  //网络出错，log 出错的acid
            throw e; //不拦截exception，由上层处理网络错误
        }
        return response;
    }

    /**
     * 请求体转String
     * @param request
     * @return
     */
    private static String bodyToString(final RequestBody request) {

        try {
            final Buffer buffer = new Buffer();
            request.writeTo(buffer);
            return buffer.readUtf8();
        } catch (final IOException e) {
            return "did not work";
        }
    }

}

开源项目okhttp-logging-interceptor

如果不想自己编写代码，也可以使用开源项目okhttp-logging-interceptor，支持：1.设置Log的等级；2.使用自定义Log。此开源项目也仅是一个Interceptor。但个人觉得log的样式并不适合调试使用。同时log的内容比较通用，若想突出对应项目的信息，建议还是自定义Http Log。

Okhttp+Retrofit+Rxjava

此Interceptor配合OkHttp使用，关于Okhttp+Retrofit+Rxjava的整合，可查看RxJava+Retrofit+OkHttp封装

引用

okhttp-logging-interceptor
okhttp Interceptors
Http协议详解

RxJava+Retrofit+OkHttp封装

发表于 2016-11-26    |   10条评论    |   阅读次数 2264

原文链接：rxjava+retrofit+OkHttp封装

前言

本文假设读者对RxJava、Retrofit和OkHttp具有基本的了解，以项目为例，重点讲解如何优雅的封装一个网络请求框架，以适应实际项目中的使用需求。

要解决的问题

1. 支持切换网络请求地址，例如项目有分区功能，不同的分区对应不同的服务器地址
2. 服务器返回接口格式不一致，有的接口是返回json格式,有的返回String格式
3. url地址中，包含固定的参数，例如版本号，渠道信息等，怎么统一添加
4. url地址中，包含动态地参数，如何动态添加
5. 是否添加网络请求的Log
6. 是否添加header(sessionId)
7. 网络请求可配置是否显示网络加载动画
8. 封装Observalbe进行数据处理的步骤，可动态改变数据处理的过程
9. 封装错误处理，区分网络错误和应用层响应错误。

优雅封装

相互联系

在三者的关系中，Retrofit主要负责将网络请求接口化，真正的网络请求和响应交给OkHttp，而RxJava在网络框架中扮演数据响应后进行数据处理的角色。做个简单比喻：假设用户需要从上海飞往北京中关村办事，需要办理登机、做飞机、到达北京后前往中关村。登机手续由Retrofit负责，真正的运输是由飞机(Okhttp)完成，客户到达（数据返回）选择交通工具（RtHttp）到达中关村。

设计图

从设计图中可看出，RtHttp为网络请求总入口：
问题1、2交给Retrofit Builder模式解决；
问题3、4、5、6交给OkHttpClient的Builer解决；
问题7将封装到RtHttp类中；
问题8由BaseApi中的Observable Builder解决；
问题9由ApiSubscriber的OnError方法解决。

设计代码

使用

首先，我们来看封装后的网络请求使用：

RtHttp.with(this) //设置Context
                .setShowWaitingDialog(true) //设置显示网络加载动画
                .setObservable(MobileApi.response(map,ProtocolUtils.PROTOCOL_MSG_ID_LOGIN))//MobileApi.response 返回一个Observalbe
                .subscriber(new ApiSubscriber() { //设置Subscriber，ApiSubscriber封装Subscriber;返回JSONObject仅是因为适配替换成Retrofit前的老代码
                    @Override
                    public void onNext(JSONObject result) {    //只实现OnNext方法
                         //具体业务逻辑
                    }
                });

RtHttp

封装后，RtHttp支持链式调用，我们来看RtHttp的代码：

/**
 * 网络请求总入口
 */
public class RtHttp{

    public static final String TAG = "RtHttp";
    public static RtHttp instance = new RtHttp(); //单例模式
    private Observable observable;
    private static WeakReference wrContext;
    private boolean isShowWaitingDialog;

    /**设置Context,使用弱引用
     * @param ct
     * @return
     */
    public static RtHttp with(Context ct){
        wrContext = new WeakReference (ct);
        return instance;
    }

    /**设置是否显示加载动画
     * @param showWaitingDialog
     * @return
     */
    public RtHttp setShowWaitingDialog(boolean showWaitingDialog) {
        isShowWaitingDialog = showWaitingDialog;
        return instance;
    }


    /**设置observable
     * @param observable
     * @return
     */
    public  RtHttp setObservable(Observable observable) {
        this.observable = observable;
        return instance;
    }


    /**设置ApiSubscriber
     * @param subscriber
     * @return
     */
    public RtHttp subscriber(ApiSubscriber subscriber){
        subscriber.setmCtx(wrContext.get());  //给subscriber设置Context，用于显示网络加载动画
        subscriber.setShowWaitDialog(isShowWaitingDialog); //控制是否显示动画
        observable.subscribe(subscriber); //RxJava 方法
        return instance;
    }


    /**
     * 使用Retrofit.Builder和OkHttpClient.Builder构建NetworkApi
     */
    public static class NetworkApiBuilder{
        private String baseUrl;  //根地址
        private boolean isAddSession; //是否添加sessionid
        private HashMap addDynamicParameterMap; //url动态参数
        private boolean isAddParameter; //url是否添加固定参数
        private Retrofit.Builder rtBuilder; 
        private OkHttpClient.Builder okBuild;
        private Converter.Factory convertFactory; 

        public NetworkApiBuilder setConvertFactory(Converter.Factory convertFactory) {
            this.convertFactory = convertFactory;
            return this;
        }

        public NetworkApiBuilder setBaseUrl(String baseUrl) {
            this.baseUrl = baseUrl;
            return this;
        }

        public NetworkApiBuilder addParameter(){
            isAddParameter = true;
            return this;
        }


        public NetworkApiBuilder addSession() {
            isAddSession = true;
            return this;
        }

        public NetworkApiBuilder addDynamicParameter(HashMap map) {
            addDynamicParameterMap = map;
            return this;
        }


        public NetworkApi build(){
            rtBuilder= new Retrofit.Builder();
            okBuild = new OkHttpClient().newBuilder();
            if(!TextUtils.isEmpty(baseUrl)){
                rtBuilder.baseUrl(baseUrl);
            }else{
                rtBuilder.baseUrl(Mobile.getBaseUrl());
            }
            if(isAddSession){
                okBuild.addInterceptor(new HeaderInterceptor(wrContext.get()));
            }
            if(isAddParameter){
                okBuild.addInterceptor(new ParameterInterceptor());
            }
            if(addDynamicParameterMap!=null){
                okBuild.addInterceptor(new DynamicParameterInterceptor(addDynamicParameterMap));
            }
            //warning:must in the last intercepter to log the network;
            if(Log.isDebuggable()){ //改成自己的显示log判断逻辑
                okBuild.addInterceptor(new LogInterceptor());
            }
            if(convertFactory!=null){
                rtBuilder.addConverterFactory(convertFactory);
            }else{
                rtBuilder.addConverterFactory(GsonConverterFactory.create());
            }
            rtBuilder.addCallAdapterFactory(RxJavaCallAdapterFactory.create())
                     .client(okBuild.build());
            return rtBuilder.build().create(NetworkApi.class);
        }
    }
}

RtHttp的代码很简洁，NetworkApiBuilder使用builder模式创建NetWorkApi，可以动态地配置Retrofit和OkHttpClient的参数。
Retrofit可配置参数：

1. baseUrl:可通过设置baseUrl产生不同的retrofit
2. addConverterFactory：通过设置addConverterFactory可适配后台接口返回不同的数据类型，例如json和String

OkHttp可添加任意Interceptor实现网络请求的处理：

1. HeaderInterceptory用于添加header(sessionid)
2. ParameterInterceptor用于添加url固定的参数
3. DynamicParameterInterceptor用于url添加动态参数
4. LogInterceptor 用户显示log

MobileApi

下面我们来看Observable的创建：

public class MobileApi extends BaseApi{

    public static NetworkApi networkApi;
    public static Observable obserable;

    public static NetworkApi getNetworkApi() { //使用NetworkApiBuilder创建networkApi
        if(networkApi==null ){
            networkApi = new RtHttp.NetworkApiBuilder()
                    .addSession()               //添加sessionId
                    .addParameter()             //添加固定参数
                    .build();
        }
        return networkApi;
    }

    public static Observable getObserable(Observable observable) {   
        obserable = new ObserableBuilder(observable)
                .addApiException()   //添加apiExcetion过滤
                .build();
        return obserable;
    }

    public static   Observable response(HashMap map, int protocolId) {
        RequestBody body = toBody(map);
        return getObserable(getNetworkApi().response(protocolId, body));
    }
}

getNetworkApi()方法可以创建特定的NetworkApi，getObserable添加数据返回后特定的处理。

NetWorkApi接口定义

public interface NetworkApi {

    @POST("open/open.do")
    Observable