内容简介:首先,本文的代码位置在我是通过创建一个会导致内存泄漏的如上述代码所示,我们的
首先,本文的代码位置在 github.com/marcosholga… 中的 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
接口。
# interfaces .implements Ljava/lang/Runnable; 复制代码
这就说明 LeakActivity$2
就是那个持有 LeakActivity
对象引用的匿名内部类的对象。
就像我们前面说的,这个 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
的对象,因此就会导致内存泄漏。
啊,终于翻译完了,可以去睡觉了!!
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- Django优化:如何避免内存泄漏
- [译]Swift:通过示例避免内存泄漏
- 为什么会存在 Goroutines 泄漏,如何避免?
- Android 系统开发_内存泄漏篇 -- "内存泄漏"的前世今生
- 内存泄漏(增长)火焰图
- Goroutine 泄漏的调试
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
信息时代三部曲:经济、社会与文化
[美] 曼纽尔·卡斯特(Manuel Castells) / 夏铸九、王志弘 / 社会科学文献出版社 / 2003 / 33.00
《信息时代三部曲:经济、社会与文化》包括《网络社会的崛起》《认同的力量》《千年终结》,由英国Blackwell Publishers Ltd. 授权出版,据原书1997版和2000版译出。2001年和2006年版《网络社会的崛起》也使用了同一ISBN。一起来看看 《信息时代三部曲:经济、社会与文化》 这本书的介绍吧!