使用 CloseableReference 优雅的释放对象,来自 Fresco

前言

说到 Fresco,想必各位都耳熟能详,出自 Facebook 的大名鼎鼎的图片加载框架,虽然最近几年被 Glide 凭借轻量和易用性而超越,但我们仍无法否认 Fresco 的强大和优秀的性能,这里不再展开。

今天要介绍的是 Fresco 基于 Bitmap 复用逻辑上抽象出的,通用的、安全的可自动释放的引用,官方文档也有专门的页面介绍「可关闭的引用」,但是发现大家真正使用的并不多,因此觉得有必要再介绍一下。

使用

这里引用官方文档的使用介绍

  1. 调用者拥有这个引用

我们创建一个引用,但我们传递给了一个调用者,调用者将持有这个引用。

CloseableReference foo() {
  Val val;
  return CloseableReference.of(val);
}
  1. 持有者在离开作用域之前,需要关闭引用

创建了一个引用,但是没有传递给其他调用者,在结束时,需要关闭:

void gee() {
  CloseableReference ref = foo();
  try {
    haa(ref);
  } finally {
    ref.close();
  }
}

finally 中最适合做此类事情了。

  1. 在赋值给变量前,先进行 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  CloseableReference of(T t)
public static  CloseableReference of(T t, ResourceReleaser resourceReleaser)

这样就比较清晰了,官方示例中使用的是一个 Closeable 的实例,在销毁的时候会调用 Closeable.close 方法,Closeable 是 JDK 中的接口,在源码中非常常见,比如我们最熟悉的 InputStream 就实现了该接口,大家一定还记得在使用完 InputStream 之后要调用 close 方法,避免内存泄露。

那如果我的实例没有实现 Closeable 接口呢,这种情况就需要用到 CloseableReference.of 的另一个重载函数了,那么 ResourceReleaser 又是什么呢

public interface ResourceReleaser {

  /**
   * Release the given value.
   *
   * 

After calling this method, the caller is no longer responsible for managing lifetime of the * value. * *

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  CloseableReference of(@PropagatesNullable T t) {
  return of(t, (ResourceReleaser) DEFAULT_CLOSEABLE_RELEASER);
}

如果是 Closeable 的子类,使用默认的 ResourceReleaser

private static final ResourceReleaser DEFAULT_CLOSEABLE_RELEASER = new ResourceReleaser() {
  @Override
  public void release(Closeable value) {
    try {
      Closeables.close(value, true);
    } catch (IOException ioe) {
    }
  }
};

处理非常简单,直接调用 close 方法。继续往下看

public static  CloseableReference of(@PropagatesNullable T t, ResourceReleaser resourceReleaser) {
  return of(t, resourceReleaser, DEFAULT_LEAK_HANDLER);
}

又调用了一个重载方法,传入了一个默认的 LeakHandlerLeakHandler 的作用主要是在 classfinalize() 方法中,判断引用是否关闭,如果未关闭则调用 LeakHandler.reportLeak 通知泄露。

@Override
protected void finalize() throws Throwable {
  if (mIsClosed) {
    return;
  }

  T ref = mSharedReference.get();
  mLeakHandler.reportLeak((SharedReference) mSharedReference, mStacktrace);
  close();
}
 
 

回到 CloseableReference 的构造流程,最终会调用到

public static  CloseableReference of(T t, ResourceReleaser 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 resourceReleaser, LeakHandler leakHandler, Throwable stacktrace) {
  super(t, resourceReleaser, leakHandler, stacktrace);
}

直接调用了父类 CloseableReference 的构造方法

protected CloseableReference(T t, ResourceReleaser resourceReleaser, LeakHandler leakHandler, Throwable stacktrace) {
  mSharedReference = new SharedReference(t, resourceReleaser);
  mLeakHandler = leakHandler;
  mStacktrace = stacktrace;
}

这里主要是构造了一个 SharedReference 共享引用,保存了 leakHandlerstacktrace

重点来了,对象自动回收的逻辑几乎都在 SharedReference 中,下面我们来一探究竟

public SharedReference(T value, ResourceReleaser 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 是实例本身,那这个实例不是被静态变量持有了?

没错,作者的意图应该是防止实例被回收,所以用了一个全局的静态变量报错所有实例的计数。

到这里,引用构建的流程基本分析完了,下面来看一下克隆。

引用克隆

CloseableReferenceclone 是一个抽象方法,看一下 DefaultCloseableReference 的实现

@Override
public CloseableReference clone() {
  return new DefaultCloseableReference(
      mSharedReference, mLeakHandler, mStacktrace != null ? new Throwable(mStacktrace) : null);
}

最终调用了父类 的构造方法

protected CloseableReference(
    SharedReference 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,然后调用了 SharedReferencedeleteReference,继续看

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 到项目中使用。

最后,感谢大家观看,如果觉得有用,欢迎点赞支持!

你可能感兴趣的:(使用 CloseableReference 优雅的释放对象,来自 Fresco)