前言
说到 Fresco，想必各位都耳熟能详，出自 Facebook 的大名鼎鼎的图片加载框架，虽然最近几年被 Glide 凭借轻量和易用性而超越，但我们仍无法否认 Fresco 的强大和优秀的性能，这里不再展开。
今天要介绍的是 Fresco 基于 Bitmap 复用逻辑上抽象出的，通用的、安全的可自动释放的引用，官方文档也有专门的页面介绍「可关闭的引用」，但是发现大家真正使用的并不多，因此觉得有必要再介绍一下。
使用
这里引用官方文档的使用介绍
- 调用者拥有这个引用
我们创建一个引用，但我们传递给了一个调用者，调用者将持有这个引用。
CloseableReference<Val> foo() {
Val val;
return CloseableReference.of(val);
}
- 持有者在离开作用域之前，需要关闭引用
创建了一个引用，但是没有传递给其他调用者，在结束时，需要关闭：
void gee() {
CloseableReference<Val> ref = foo();
try {
haa(ref);
} finally {
ref.close();
}
}
finally 中最适合做此类事情了。
- 在赋值给变量前，先进行
clone
void haa(CloseableReference<?> ref) {
final CloseableReference<?> refClone = ref.clone();
try {
// 交给下个作用域处理
ohaa(refClone);
} finally {
// 当前函数域内可安全关闭，闭包内为已经clone过的引用。
ref.close();
}
}
使用可以说非常简单了
- 通过 CloseableReference.of 创建一个可关闭的引用
- 未关闭的引用通过 CloseableReference.get 获取引用的实例
- 通过 CloseableReference.close 关闭引用
- 通过 CloseableReference.clone 复制一个引用，交给下一个函数处理，当前域的引用即可安全关闭
- 当激活的引用为0时，即会销毁该实例
不知道大家有没有发现一个问题，上面并没有介绍实例是怎么销毁的，这里就需要配合源码一起看了。
CloseableReference.of 方法有两个重载，分别是
public static <T extends Closeable> CloseableReference<T> of(T t)
public static <T> CloseableReference<T> of(T t, ResourceReleaser<T> resourceReleaser)
这样就比较清晰了，官方示例中使用的是一个 Closeable 的实例，在销毁的时候会调用 Closeable.close 方法，Closeable 是 JDK 中的接口，在源码中非常常见，比如我们最熟悉的 InputStream 就实现了该接口，大家一定还记得在使用完 InputStream 之后要调用 close 方法，避免内存泄露。
那如果我的实例没有实现 Closeable 接口呢，这种情况就需要用到 CloseableReference.of 的另一个重载函数了，那么 ResourceReleaser 又是什么呢
public interface ResourceReleaser<T> {
/**
* Release the given value.
*
* <p>After calling this method, the caller is no longer responsible for managing lifetime of the
* value.
*
* <p>This method is not permitted to throw an exception and is always required to succeed. It is
* often called from contexts like catch blocks or finally blocks to cleanup resources. Throwing
* an exception could result in swallowing the original exception.
*
* @param value
*/
void release(T value);
}
其实就是一个对象释放器，这里配合 对象池 一起食用效果更佳。
源码分析
我们以最简单的使用方式分析一下主要流程。
引用构建
先从入口开始，即 CloseableReference.of，假设我们要关闭的是一个实现了 Closeable 接口的实例
public static <T extends Closeable> CloseableReference<T> of(@PropagatesNullable T t) {
return of(t, (ResourceReleaser<T>) DEFAULT_CLOSEABLE_RELEASER);
}
如果是 Closeable 的子类，使用默认的 ResourceReleaser
private static final ResourceReleaser<Closeable> DEFAULT_CLOSEABLE_RELEASER = new ResourceReleaser<Closeable>() {
@Override
public void release(Closeable value) {
try {
Closeables.close(value, true);
} catch (IOException ioe) {
}
}
};
处理非常简单，直接调用 close 方法。继续往下看
public static <T> CloseableReference<T> of(@PropagatesNullable T t, ResourceReleaser<T> resourceReleaser) {
return of(t, resourceReleaser, DEFAULT_LEAK_HANDLER);
}
又调用了一个重载方法，传入了一个默认的 LeakHandler，LeakHandler 的作用主要是在 class 的 finalize() 方法中，判断引用是否关闭，如果未关闭则调用 LeakHandler.reportLeak 通知泄露。
@Override
protected void finalize() throws Throwable {
if (mIsClosed) {
return;
}
T ref = mSharedReference.get();
mLeakHandler.reportLeak((SharedReference<Object>) mSharedReference, mStacktrace);
close();
}
回到 CloseableReference 的构造流程，最终会调用到
public static <T> CloseableReference<T> of(T t, ResourceReleaser<T> resourceReleaser, LeakHandler leakHandler, Throwable stacktrace) {
if (t == null) {
return null;
} else {
if (t instanceof Bitmap || t instanceof HasBitmap) {
switch (sBitmapCloseableRefType) {
case REF_TYPE_FINALIZER:
return new FinalizerCloseableReference<>(t, resourceReleaser, leakHandler, stacktrace);
case REF_TYPE_REF_COUNT:
return new RefCountCloseableReference<>(t, resourceReleaser, leakHandler, stacktrace);
case REF_TYPE_NOOP:
return new NoOpCloseableReference<>(t, resourceReleaser, leakHandler, stacktrace);
case REF_TYPE_DEFAULT:
// return default
}
}
return new DefaultCloseableReference<>(t, resourceReleaser, leakHandler, stacktrace);
}
}
这里做了 Bitmap 类型的判断，根据不同的回收策略，返回对应的 Reference，这里也不深入研究，感兴趣的同学可以去钻研下源码，我们继续分析默认的 DefaultCloseableReference 的构造函数
DefaultCloseableReference(T t, ResourceReleaser<T> resourceReleaser, LeakHandler leakHandler, Throwable stacktrace) {
super(t, resourceReleaser, leakHandler, stacktrace);
}
直接调用了父类 CloseableReference 的构造方法
protected CloseableReference(T t, ResourceReleaser<T> resourceReleaser, LeakHandler leakHandler, Throwable stacktrace) {
mSharedReference = new SharedReference<T>(t, resourceReleaser);
mLeakHandler = leakHandler;
mStacktrace = stacktrace;
}
这里主要是构造了一个 SharedReference 共享引用，保存了 leakHandler 和 stacktrace。
重点来了，对象自动回收的逻辑几乎都在 SharedReference 中，下面我们来一探究竟
public SharedReference(T value, ResourceReleaser<T> resourceReleaser) {
mValue = Preconditions.checkNotNull(value);
mResourceReleaser = Preconditions.checkNotNull(resourceReleaser);
mRefCount = 1;
addLiveReference(value);
}
构造方法中保存了实例和 ResourceReleaser 的引用，然后 mRefCount 引用计数 +1，看到这里大家是不是觉得很熟悉，没错，这不就是我们每次面试前都要看的「引用计数法」么，这其实就是 CloseableReference 的核心。
虽然我们基本了解了原理，但还是继续分析下完整流程，继续看 addLiveReference 方法做了什么
private static void addLiveReference(Object value) {
Integer count = sLiveObjects.get(value);
if (count == null) {
sLiveObjects.put(value, 1);
} else {
sLiveObjects.put(value, count + 1);
}
}
一看 s 开头的就知道是静态变量，这里再次把引用计数 +1，咦，前面不是已经 +1 了吗，这里为什么又有一个计数器，而且 key 是实例本身，那这个实例不是被静态变量持有了？
没错，作者的意图应该是防止实例被回收，所以用了一个全局的静态变量报错所有实例的计数。
到这里，引用构建的流程基本分析完了，下面来看一下克隆。
引用克隆
CloseableReference 的 clone 是一个抽象方法，看一下 DefaultCloseableReference 的实现
@Override
public CloseableReference<T> clone() {
return new DefaultCloseableReference<T>(
mSharedReference, mLeakHandler, mStacktrace != null ? new Throwable(mStacktrace) : null);
}
最终调用了父类 的构造方法
protected CloseableReference(
SharedReference<T> sharedReference, LeakHandler leakHandler, @Nullable Throwable stacktrace) {
mSharedReference = Preconditions.checkNotNull(sharedReference);
sharedReference.addReference();
mLeakHandler = leakHandler;
mStacktrace = stacktrace;
}
非常简单，相当于拷贝了一份对象，复用了计数器，并且将计数 +1。
引用关闭
直接看代码
@Override
public void close() {
synchronized (this) {
if (mIsClosed) {
return;
}
mIsClosed = true;
}
mSharedReference.deleteReference();
}
首先将关闭的标记置为 TRUE，然后调用了 SharedReference 的 deleteReference，继续看
public void deleteReference() {
if (decreaseRefCount() == 0) {
T deleted;
synchronized (this) {
deleted = mValue;
mValue = null;
}
if (deleted != null) {
mResourceReleaser.release(deleted);
removeLiveReference(deleted);
}
}
}
首先计数器 -1，如果计数变为 0，则调用 ResourceReleaser.release 释放实例，这里即是自动释放的触发点。
然后调用 removeLiveReference 更新静态计数器
private static void removeLiveReference(Object value) {
synchronized (sLiveObjects) {
Integer count = sLiveObjects.get(value);
if (count == null) {
// Uh oh.
} else if (count == 1) {
sLiveObjects.remove(value);
} else {
sLiveObjects.put(value, count - 1);
}
}
}
静态计数器 -1，如果计数变为 0，则移除实例的引用。
至此，整个实例的释放流程结束。
这里其实有一个问题，如果一个实例被多个 SharedReference 持有会怎么样？
如果一个 SharedReference 触发了回收操作，那么该实例就会被回收，其他引用对该实例的操作将不可控。
所以一定要注意，一个实例只能被一个引用持有，如果需要多个引用，用 clone 方法来构造，避免出现不可预知的错误！
总结
今天给大家分享了一个 Fresco 中的小彩蛋 —— 可关闭的引用，通过引用计数法，自动释放对象，避免出现无法确定对象释放时机的窘境。
另外，这里的可关闭引用只是为了方便我们安全的回收对象，如果想要复用对象，还需要配合 对象池 一起使用。
如果大家的项目没有依赖 Fresco 也没有关系，这里代码并不多，大概就3个类，而且没有强耦合，可以直接 copy 到项目中使用。
最后，感谢大家观看，如果觉得有用，欢迎点赞支持！
