Kotlin是如何帮助你避免内存泄漏的？

首先，本文的代码位置在 https:// github.com/marcosholgad o/performance-test/tree/kotlin-mem-leak 中的 kotlin-mem-leak 分支上。 我是通过创建一个会导致内存泄漏的 Activity ，然后观察其使用 Java 和 Kotlin 编写时的表现来进行测试的。 其中 Java 代码如下：

public class LeakActivity extends Activity {
  @Override protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_leak);
    View button = findViewById(R.id.button);
    button.setOnClickListener(new View.OnClickListener() {
      @Override
      public void onClick(View v) {
        startAsyncWork();
  @SuppressLint("StaticFieldLeak")
  void startAsyncWork() {
    Runnable work = new Runnable() {
      @Override public void run() {
        SystemClock.sleep(20000);
    new Thread(work).start();
}

如上述代码所示，我们的 button 点击之后，执行了一个耗时任务。这样如果我们在20s之内关闭 LeakActivity 的话就会产生内存泄漏，因为这个新开的线程持有对 LeakActivity 的引用。如果我们是在20s之后再关闭这个 Activity 的话，就不会导致内存泄漏。 然后我们把这段代码改成 Kotlin 版本：

class KLeakActivity : Activity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_leak)
        button.setOnClickListener { startAsyncWork() }
    private fun startAsyncWork() {
        val work = Runnable { SystemClock.sleep(20000) }
        Thread(work).start()
}

咋一看，好像就只是在 Runable 中使用 lambda 表达式替换了原来的样板代码。然后我使用 leakcanary 和我自己的 @LeakTest 注释写了一个内存泄漏测试用例。

class LeakTest {
    @get:Rule
    var mainActivityActivityTestRule = ActivityTestRule(KLeakActivity::class.java)
    @Test
    @LeakTest
    fun testLeaks() {
        onView(withId(R.id.button)).perform(click())
}

我们使用这个用例分别对 Java 写的 LeakActivity 和 Kotlin 写的 KLeakActivity 进行测试。测试结果是 Java 写的出现内存泄漏，而 Kotlin 写的则没有出现内存泄漏。 这个问题困扰了我很长时间，一度接近自闭。。

然后某天，我突然灵光一现，感觉应该和编译后字节码有关系。

分析LeakActivity.java的字节码

Java 类产生的字节码如下：

.method startAsyncWork()V
    .registers 3
    .annotation build Landroid/annotation/SuppressLint;
        value = {
            "StaticFieldLeak"
    .end annotation
    .line 29
    new-instance v0, Lcom/marcosholgado/performancetest/LeakActivity$2;
    invoke-direct {v0, p0}, Lcom/marcosholgado/performancetest/LeakActivity$2;-><init>
                               (Lcom/marcosholgado/performancetest/LeakActivity;)V
    .line 34
    .local v0, "work":Ljava/lang/Runnable;
    new-instance v1, Ljava/lang/Thread;
    invoke-direct {v1, v0}, Ljava/lang/Thread;-><init>(Ljava/lang/Runnable;)V
    invoke-virtual {v1}, Ljava/lang/Thread;->start()V
    .line 35
    return-void
.end method

我们知道匿名内部类持有对外部类的引用，正是这个引用导致了内存泄漏的产生，接下来我们就在字节码中找出这个引用。

new-instance v0, Lcom/marcosholgado/performancetest/LeakActivity$2;

上述字节码的含义是： 首先我们创建了一个 LeakActivity$2 的实例。。

奇怪的是我们没有创建这个类啊，那这个类应该是系统自动生成的，那它的作用是什么啊？ 我们打开 LeakActivity$2 的字节码看下

.class Lcom/marcosholgado/performancetest/LeakActivity$2;
.super Ljava/lang/Object;
.source "LeakActivity.java"
# interfaces
.implements Ljava/lang/Runnable;
# instance fields
.field final synthetic this$0:Lcom/marcosholgado/performancetest/LeakActivity;
# direct methods
.method constructor <init>(Lcom/marcosholgado/performancetest/LeakActivity;)V
    .registers 2
    .param p1, "this$0"    # Lcom/marcosholgado/performancetest/LeakActivity;
    .line 29
    iput-object p1, p0, Lcom/marcosholgado/performancetest/LeakActivity$2;
                    ->this$0:Lcom/marcosholgado/performancetest/LeakActivity;
    invoke-direct {p0}, Ljava/lang/Object;-><init>()V
    return-void
.end method

第一个有意思的事是这个 LeakActivity$2 实现了 Runnable 接口。

这就说明 LeakActivity$2 就是那个持有 LeakActivity 对象引用的匿名内部类的对象。

# interfaces
.implements Ljava/lang/Runnable;

就像我们前面说的，这个 LeakActivity$2 应该持有 LeakActivity 的引用，那我们继续找。

# instance fields
.field final synthetic        
    this$0:Lcom/marcosholgado/performancetest/LeakActivity;

果然，我们发现了外部类LeakActivity的对象的引用。 那这个引用是什么时候传入的呢？只有可能是在构造器中传入的，那我们继续找它的构造器。

.method constructor 
    <init>(Lcom/marcosholgado/performancetest/LeakActivity;)V

果然，在构造器中传入了 LeakActivity 对象的引用。 让我们回到 LeakActivity 的字节码中，看看这个 LeakActivity$2 被初始化的时候。

new-instance v0, Lcom/marcosholgado/performancetest/LeakActivity$2;
invoke-direct {v0, p0},   
    Lcom/marcosholgado/performancetest/LeakActivity$2;-><init>    
    (Lcom/marcosholgado/performancetest/LeakActivity;)V

可以看到，我们使用 LeakActivity 对象来初始化 LeakActivity$2 对象，这样就解释了为什么 LeakActivity.java 会出现内存泄漏的现象。

分析 KLeakActivity.kt的字节码

KLeakActivity.kt 中我们关注 startAsyncWork 这个方法的字节码，因为其他部分和 Java 写法是一样的，只有这部分不一样。 该方法的字节码如下所示：

.method private final startAsyncWork()V
    .registers 3
    .line 20
    sget-object v0, 
      Lcom/marcosholgado/performancetest/KLeakActivity$startAsyncWork$work$1;
      ->INSTANCE:Lcom/marcosholgado/performancetest/KLeakActivity$startAsyncWork$work$1;
    check-cast v0, Ljava/lang/Runnable;
    .line 24
    .local v0, "work":Ljava/lang/Runnable;
    new-instance v1, Ljava/lang/Thread;
    invoke-direct {v1, v0}, Ljava/lang/Thread;-><init>(Ljava/lang/Runnable;)V
    invoke-virtual {v1}, Ljava/lang/Thread;->start()V
    .line 25
    return-void
.end method

可以看出，与 Java 字节码中初始化一个包含 Activity 引用的实现 Runnable 接口对象不同的是，这个字节码使用了静态变量来执行静态方法。

sget-object v0,         
Lcom/marcosholgado/performancetest/KLeakActivity$startAsyncWork$work$1; -> 
INSTANCE:Lcom/marcosholgado/performancetest/KLeakActivity$startAsyncWork$work$1;

我们深入 KLeakActivity\$startAsyncWork\$work$1 的字节码看下：

.class final Lcom/marcosholgado/performancetest/KLeakActivity$startAsyncWork$work$1;
.super Ljava/lang/Object;
.source "KLeakActivity.kt"
# interfaces
.implements Ljava/lang/Runnable;
.method static constructor <clinit>()V
    .registers 1
    new-instance v0, 
      Lcom/marcosholgado/performancetest/KLeakActivity$startAsyncWork$work$1;
    invoke-direct {v0}, 
      Lcom/marcosholgado/performancetest/KLeakActivity$startAsyncWork$work$1;-><init>()V
    sput-object v0, 
      Lcom/marcosholgado/performancetest/KLeakActivity$startAsyncWork$work$1;
      ->INSTANCE:Lcom/marcosholgado/performancetest/KLeakActivity$startAsyncWork$work$1;
    return-void
.end method
.method constructor <init>()V
    .registers 1
    invoke-direct {p0}, Ljava/lang/Object;-><init>()V
    return-void
.end method

可以看出， KLeakActivity\$startAsyncWork\$work$1 实现了 Runnable 接口，但是其拥有的是静态方法，因此不需要外部类对象的引用。 所以 Kotlin 不出现内存泄漏的原因出来了，在 Kotlin 中，我们使用 lambda (实际上是一个 SAM)来代替 Java 中的匿名内部类。没有 Activity 对象的引用就不会发生内存泄漏。 当然并不是说只有 Kotlin 才有这个功能，如果你使用 Java8 中的 lambda 的话，一样不会发生内存泄漏。 如果你想对这部分做更深入的了解，可以参看这篇文章 Translation of Lambda Expressions 。 如果有需要翻译的同学可以在评论里面说就行啦。

现在把其中比较重要的一部分说下：

上述段落中的Lamdba表达式可以被认为是静态方法。因为它们没有使用类中的实例属性，例如使用super、this或者该类中的成员变量。 我们把这种Lambda称为 Non-instance-capturing lambdas （这里我感觉还是不翻译为好）。而那些需要实例属性的Lambda则称为 instance-capturing lambdas 。

Non-instance-capturing lambdas 可以被认为是private、static方法。 instance-capturing lambdas 可以被认为是普通的private、instance方法。

这段话放在我们这篇文章中是什么意思呢？

因为我们 Kotlin 中的 lambda 没有使用实例属性，所以其是一个 non-instance-capturing lambda ，可以被当成静态方法来看待，就不会产生内存泄漏。

如果我们在其中添加一个外部类对象属性的引用的话，这个 lambda 就转变成 instance-capturing lambdas ，就会产生内存泄漏。

class KLeakActivity : Activity() {
    private var test: Int = 0
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_leak)
        button.setOnClickListener { startAsyncWork() }
    private fun startAsyncWork() {
        val work = Runnable {
            test = 1 // comment this line to pass the test
            SystemClock.sleep(20000)
        Thread(work).start()

如上述代码所示，我们使用了 test 这个实例属性，就会导致内存泄漏。 startAsyncWork 方法的字节码如下所示：

.method private final startAsyncWork()V
    .registers 3
    .line 20
    new-instance v0, Lcom/marcosholgado/performancetest/KLeakActivity$startAsyncWork$work$1;
    invoke-direct {v0, p0}, 
       Lcom/marcosholgado/performancetest/KLeakActivity$startAsyncWork$work$1;
       -><init>(Lcom/marcosholgado/performancetest/KLeakActivity;)V
    check-cast v0, Ljava/lang/Runnable;
    .line 24
    .local v0, "work":Ljava/lang/Runnable;
    new-instance v1, Ljava/lang/Thread;
    invoke-direct {v1, v0}, Ljava/lang/Thread;-><init>(Ljava/lang/Runnable;)V