[译]Kotlin是如何帮助你避免内存泄漏的?

本文对比分析了Java和Kotlin在处理内存泄漏方面的差异,通过具体示例代码展示了如何Kotlin的lambda表达式避免了内存泄漏的问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

首先,本文的代码位置在github.com/marcosholga…中的kotlin-mem-leak分支上。

令人困惑的现象

我是通过创建一个会导致内存泄漏的Activity,然后观察其使用JavaKotlin编写时的表现来进行测试的。 其中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写的LeakActivityKotlin写的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的对象,因此就会导致内存泄漏。

啊,终于翻译完了,可以去睡觉了!!

原文地址

How Kotlin helps you avoid memory leaks

转载于:https://juejin.im/post/5c83fe916fb9a049f23d9296

<think>嗯,用户问的是如何将Kotlin中的callback转换为bundle。用户之前提供了一个BRVAH适配器的代码片段,其中包含回调接口ItemSelectedCallBack,现在想要把这种回调机制改为通过Bundle传递数据。用户可能正在重构某个功能模块,想要把Fragment/Activity之间的通信方式从回调改成Intent/Bundle传递。从引用内容看,用户对RecyclerView、数据传递(引用[3]的Bundle示例)和异步处理(引用[2]的Retrofit)都有实践基础。关键问题在于Bundle本身不能直接存储函数对象(Kotlin/Java函数不是可序列化的)。需要设计替代方案。回忆下Bundle支持的数据类型:基本类型、String、Parcelable对象等。解决方案可以分三步走:首先定义包含回调函数核心数据的可序列化对象(例如要传递的参数),然后在目标端根据这些数据重建回调逻辑。用户引用[3]里的Bundle.putInt("id")等操作就是很好的参照。特别要注意的是,如果回调涉及UI操作(比如显示提示框),那么传递Bundle后还需要确保目标Activity能正确处理异步结果。可能需要结合LiveData或EventBus等方案做后续通知。</think> 在 Kotlin 中将回调函数转换为可通过 `Bundle` 传递的数据结构,本质上是解决**回调函数无法直接序列化**的问题。以下是几种实用方案: --- ### ✅ 方案一:使用可序列化对象封装回调逻辑 通过实现 `Parcelable` 或 `Serializable` 接口的对象存储回调所需的数据,在接收端重建逻辑: ```kotlin // 1. 定义可序列化的回调容器 @Parcelize data class CallbackData( val type: String, // 标识回调类型 val targetId: Int, // 关联的目标ID val extra: String? = null // 附加参数 ) : Parcelable // 2. 发送端:将回调数据存入Bundle val callbackData = CallbackData("SHOW_GUIDE", itemId) val bundle = Bundle().apply { putParcelable("CALLBACK_KEY", callbackData) } intent.putExtras(bundle) // 3. 接收端:解析并执行逻辑 val data = intent.getParcelableExtra<CallbackData>("CALLBACK_KEY") when (data?.type) { "SHOW_GUIDE" -> showGuidePopup(data.targetId, data.extra) // 其他类型处理... } ``` --- ### ✅ 方案二:利用全局事件总线(推荐解耦场景) 使用 `LiveData` 或 `EventBus` 分离回调逻辑与界面跳转: ```kotlin // 1. 定义全局事件对象 object GlobalEvents { val showGuideEvent = MutableLiveData<Pair<Int, String?>>() } // 2. 发送端:触发事件而非传递Bundle GlobalEvents.showGuideEvent.value = Pair(itemId, "Extra info") // 3. 接收端(Activity/Fragment)观察事件 GlobalEvents.showGuideEvent.observe(this) { (id, extra) -> showGuidePopup(id, extra) } ``` --- ### ✅ 方案三:接口代理模式(复杂回调场景) 通过静态代理实现回调接口的序列化: ```kotlin // 1. 定义可序列化的代理接口 interface CallbackProxy : Serializable { fun execute(context: Context) } // 2. 实现具体代理类 class GuideCallbackProxy(private val targetId: Int) : CallbackProxy { override fun execute(context: Context) { (context as? Activity)?.showGuide(targetId) } } // 3. 传递代理对象 val bundle = Bundle().apply { putSerializable("CALLBACK_PROXY", GuideCallbackProxy(itemId)) } ``` --- ### 📌 关键注意事项 1. **避免直接传递函数** Kotlin 函数对象(如 lambda)不可序列化,强行传递会导致 `NotSerializableException` 2. **内存泄漏防护** 方案二/三中需注意生命周期管理: ```kotlin // 在Activity中正确解除观察 override fun onDestroy() { GlobalEvents.showGuideEvent.removeObservers(this) super.onDestroy() } ``` 3. **跨进程限制** 若需跨进程通信,优先选择 `Parcelable`(效率高于 `Serializable`)[^1] --- ### 🌟 建议场景 | 方案 | 适用场景 | 优点 | |-------------|-----------------------------------|--------------------------| | 序列化对象 | 简单数据传递,如跳转参数 | 轻量级,官方支持 | | 事件总线 | 组件间解耦,多接收方 | 彻底解耦,灵活订阅 | | 接口代理 | 复杂回调逻辑,需上下文重建 | 逻辑封装完整 | > 示例参考:用户引用的Bundle使用方案[^3]与回调封装模式[^1]均为可行实践,但需按实际场景调整实现层级。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值