Glide如何通过引用计数复用Bitmap

前文《Android图片加载问题分析》中提到3.0及以上的Android系统上，BitmapFactory创建Bitmap时可以复用之前创建的Bitmap，特别是在5.0及以上时复用的Bitmap不再要求和新Bitmap的像素数据一样大。

但是运行时哪些Bitmap才能被拿来复用呢？

下面将通过的Glide源码的分析，了解Glide是怎样做的。

理解RequestManager

Glide.with做了什么

Glide.with有5个重载方法，返回值都是RequestManager，参数分别为

android.content.Context
android.app.Activity
android.app.Fragment
android.support.v4.app.Fragment
android.support.v4.app.FragmentActivity

这些with方法最终都会通过以下三个方法创建RequestManager。

  private RequestManager getApplicationManager(Context context) {
    MediaScannerConnection.scanFile(null, null, null,null);
    if (applicationManager == null) {
      synchronized (this) {
        if (applicationManager == null) {
          Glide glide = Glide.get(context);
          applicationManager =
              new RequestManager(
                  glide, new ApplicationLifecycle(), new EmptyRequestManagerTreeNode());
        }
      }
    }

    return applicationManager;
  }
  
  @TargetApi(Build.VERSION_CODES.HONEYCOMB)
  RequestManager fragmentGet(Context context, android.app.FragmentManager fm,
      android.app.Fragment parentHint) {
    RequestManagerFragment current = getRequestManagerFragment(fm, parentHint);
    RequestManager requestManager = current.getRequestManager();
    if (requestManager == null) {
      Glide glide = Glide.get(context);
      requestManager =
          new RequestManager(glide, current.getLifecycle(), current.getRequestManagerTreeNode());
      current.setRequestManager(requestManager);
    }
    return requestManager;
  }
  
  RequestManager supportFragmentGet(Context context, FragmentManager fm, Fragment parentHint) {
    SupportRequestManagerFragment current = getSupportRequestManagerFragment(fm, parentHint);
    RequestManager requestManager = current.getRequestManager();
    if (requestManager == null) {
      Glide glide = Glide.get(context);
      requestManager =
          new RequestManager(glide, current.getLifecycle(), current.getRequestManagerTreeNode());
      current.setRequestManager(requestManager);
    }
    return requestManager;
  }

getApplicationManager获得的是一个单例的对象，表示全局只有一个applicationManager。
后两个是将RequestManager与SupportRequestManagerFragment或RequestManagerFragment绑定
这两种Fragment又是通过FragmentManager fm和Fragment parentHint获取的
RequestManager创建时，使用了RequestManagerFragment#current.getLifecycle

以上三个方法都是被RequestManagerRetriever#get调用的。在RequestManagerRetriever#get的几个重载方法中能看到：

在后台线程中获取的RequestManager都是applicationManager，这是因为后台线程可能比页面存活的时间更长。
在3.0及以下的系统上，通过Actitivy获取的RequestManager也是applicationManager，这是因为老的Activity中还不能添加Fragment。

RequestManagerFragment是什么

  @TargetApi(Build.VERSION_CODES.JELLY_BEAN_MR1)
  RequestManagerFragment getRequestManagerFragment(
      final android.app.FragmentManager fm, android.app.Fragment parentHint) {
    RequestManagerFragment current = (RequestManagerFragment) fm.findFragmentByTag(FRAGMENT_TAG);
    if (current == null) {
      current = pendingRequestManagerFragments.get(fm);
      if (current == null) {
        current = new RequestManagerFragment();
        current.setParentFragmentHint(parentHint);
        pendingRequestManagerFragments.put(fm, current);
        fm.beginTransaction().add(current, FRAGMENT_TAG).commitAllowingStateLoss();
        handler.obtainMessage(ID_REMOVE_FRAGMENT_MANAGER, fm).sendToTarget();
      }
    }
    return current;
  }

RequestManagerFragment是一个Fragment，并被FragmentManager添加到特定的页面了（可能是Activity或Fragment）
同一个页面只会存在一个RequestManagerFragment与之对应

看到这里，我们自然会想到，RequestManager通过RequestManagerFragment获得了所在页面的生命周期。在页面onDestroy时，RequestManager#onDestroy也会被调用。这里不再贴这部分的详细代码了。只看看RequestManager#onDestroy做了什么，其中的clear(target)将是下一节中释放过程的入口。

  /**
   * Lifecycle callback that cancels all in progress requests and clears and recycles resources for
   * all completed requests.
   */
  @Override
  public void onDestroy() {
    targetTracker.onDestroy();
    for (Target target : targetTracker.getAll()) {
      clear(target);
    }
    targetTracker.clear();
    requestTracker.clearRequests();
    lifecycle.removeListener(this);
    lifecycle.removeListener(connectivityMonitor);
    mainHandler.removeCallbacks(addSelfToLifecycle);
    glide.unregisterRequestManager(this);
  }

Glide中的缓存管理和Bitmap复用

通过Glide的源码，我们很容易发现一个进程中只会存在一个Engine实例。我们这里主要关注Engine中的三个变量

Map>> activeResources
MemoryCache cache
LazyDiskCacheProvider diskCacheProvider

MemoryCache很好理解，就是我们常说的内存缓存。虽然Glide的源码通过LruResourceCache实现MemoryCache，而LruResourceCache通过泛型使其可以缓存各种对象，但这里仅以BitmapResource作为讨论对象，其缓存的就是Bitmap实例。

diskCacheProvider就是对磁盘缓存的封装，Engine不管理磁盘缓存，而是在DecodeJob中使用磁盘缓存。DecodeJob会根据请求的特点，决定存储的转换后的图片，还是原图片。图片的下载也是在DecodeJob中通过DataFetcher处理。

decodeJobFactory = new DecodeJobFactory(diskCacheProvider);

activeResources是Glide通过引用计数实现Bitmap复用的关键

Key是通过每次load的参数生成的

EngineKey key = keyFactory.buildKey(model, signature, width, height, transformations, resourceClass, transcodeClass, options);

Value是EngineResource的弱引用。EngineResource中和Bitmap复用相关的主要有三个方法acquire，release和recyle，正是通过对EngineResource的引用计数，才能找到那些不会系统使用的Bitmap。

  void acquire() {
    if (isRecycled) {
      throw new IllegalStateException("Cannot acquire a recycled resource");
    }
    if (!Looper.getMainLooper().equals(Looper.myLooper())) {
      throw new IllegalThreadStateException("Must call acquire on the main thread");
    }
    ++acquired;
  }
  
  void release() {
    if (acquired <= 0) {
      throw new IllegalStateException("Cannot release a recycled or not yet acquired resource");
    }
    if (!Looper.getMainLooper().equals(Looper.myLooper())) {
      throw new IllegalThreadStateException("Must call release on the main thread");
    }
    if (--acquired == 0) {
      listener.onResourceReleased(key, this);
    }
  }

  @Override
  public void recycle() {
    if (acquired > 0) {
      throw new IllegalStateException("Cannot recycle a resource while it is still acquired");
    }
    if (isRecycled) {
      throw new IllegalStateException("Cannot recycle a resource that has already been recycled");
    }
    isRecycled = true;
    resource.recycle();
  }

而BitmapResource#recycle则将bitmap放回回收池bitmapPool.put(bitmap);

加载过程

Glide加载图片的过程

可以看到每个成功执行的加载任务都会给调用一次EngineResource#acquire，从而增加引用计数。

释放过程

释放过程的逻辑前文已经基本说清楚了，这里列出完整的调用栈

AcitivityFragmentLifecycle#onDestory
RequestManager#onDestroy -> clear -> untrackOrDelegate
Glide#removeFromManagers
RequestManager#untrack
RequestTracker#clearRemoveAndRecycle
SingleRequest#clear releaseResource
Engine#release
EngineResource#release：当引用计数为0时，触发listener.onResourceReleased(key, this)
ResourceListener#onResourceReleased
Engine#onResourceReleased：如果Recourse能被缓存，则加入MemeoryCache，否则释放资源。
ResourceRecycler#recycle
BitmapResource#recycle：（将Bitmap放入回收池）

//Engine
  @Override
  public void onResourceReleased(Key cacheKey, EngineResource resource) {
    Util.assertMainThread();
    activeResources.remove(cacheKey);
    if (resource.isCacheable()) {
      cache.put(cacheKey, resource);
    } else {
      resourceRecycler.recycle(resource);
    }
  }

除了applicationManager管理的请求，所有的请求都会随着页面的Destroy调用一次EngineResource#release，从而能确保被回收的资源不被任何页面使用。这里看到放入MemoryCache的资源，都是页面不再使用的资源。页面从MemoryCache获取缓存的同时，会将Resouce从MemoryCache中删除。

  private EngineResource getEngineResourceFromCache(Key key) {
    Resource cached = cache.remove(key);

    final EngineResource result;
    if (cached == null) {
      result = null;
    } else if (cached instanceof EngineResource) {
      // Save an object allocation if we've cached an EngineResource (the typical case).
      result = (EngineResource) cached;
    } else {
      result = new EngineResource<>(cached, true /*isMemoryCacheable*/);
    }
    return result;
  }

因此可以确保从MemoryCache中移除的Bitmap能被放到BitmapPool中安全的复用。

Glide中Bitmap的流动

最后通过一张图片，了解Glide中Bitmap的流动

Glide中的Bitmap流动

Glide的假三级缓存和Fresco的真三级缓存

Fresco的三级缓存在上篇文章中介绍过，如下图，它增加了未解码图片的内存缓存，减少文件IO。

fresco缓存示意图

从前文的加载过程可以看到Glide从缓存获取Bitmap的来源也有三个，activeResources，MemoryCache和DiskCache。看上去很像是三级缓存，但实际上activeResources和MemoryCache是互补的。

activeResources存储页面中使用的Bitmap的弱引用
MemoryCache存储页面不再使用的Bitmap

所以activeResources从严格意义上看来不能算是缓存。它存在的最主要的意义是，通过弱引用保存页面使用的Bitmap。通过activeResources和MemoryCache一起，就能精确的了解整个应用中所有通过Glide创建的Bitmap的状态。