首先，本文的代码位置在https://github.com/marcosholgado/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
invoke-virtual {v1}, Ljava/lang/Thread;->start()V
.line 25
return-void
.end method
很明显，我们传入了KLeakActivity的对象，因此就会导致内存泄漏。
啊，终于翻译完了，可以去睡觉了！！
