Kotlin中SAM转换 关于Kotlin中SAM转换的那些事

前言

随着 Kotlin 1.4 正式发布，关于 SAM 转换的一些问题就可以盖棺定论了。因为这里要讲的都是些旧的东西，所以这是一篇灌水文。

Kotlin对SAM转换的支持情况

在 1.4 发布之前，经常有新人在群里提出关于 SAM 转换的问题。

为了说明这个问题，要分成几个情况来讨论。

我们需要区分这个接口是Java接口还是Kotlin接口：

// 这是Java
interface JavaSome {
 void some(); 
}

// 这是Kotlin
interface KotlinSome {
 fun some()
}

以及区分在Java还是Kotlin里使用该接口：

// 这是Java, ISome是一个接口
void useSome(ISome some) {}

// 这是Kotlin, ISome是一个接口
fun useSome(some: ISome) {}

两两相乘，我们就需要对4种情况进行讨论。当然，useSome 函数都是在 Kotlin 里调用。

1、Java接口，Java使用

// Java
void useSome(JavaSome some) {}

// Kotlin
useSome {} // OK

这种情况下的 SAM 转换，是自古以来 Kotlin 就支持的。

2、Java接口，Kotlin使用

// Kotlin
fun useSome(some: JavaSome) {}

useSome {} // 能否编译成功跟Kotlin版本和编译器参数有关

Kotlin 1.2 以及更旧版本不支持这种情况下的SAM转换。

Kotlin 1.3 版本，Kotlin 官方团队发现他们写的那堆类型推断算法是一座“屎山”，于是重新写了套新的类型推断算法，作为默认关闭的实验性特性加入了 1.3 版本。新的类型推断算法支持这种情况下的SAM转换，不过需要手动传入编译器参数来开启这个功能。

Kotlin 1.4 版本，由于新的类型推断算法已经默认开启，所以这种情况下可以进行SAM转换。

3、Kotlin接口，Kotlin使用

// Kotlin
fun useSome(some: KotlinSome) {}

useSome {} // 编译错误！

这就是广为人知、为人诟病的垃圾 Kotlin 不支持 SAM 转换的情况。

在 Kotlin 1.4 版本，你需要在接口前加上关键字 fun，让它成为一个 fun interface 才能享受到 SAM 转换。

// Kotlin
fun interface KotlinSome {
 fun some()
}

fun useSome(some: KotlinSome) {}

useSome {} // OK

当然 1.3 版本就别想了，老老实实升级吧。

4、Kotlin接口，Java使用

// Java
void useSome(KotlinSome some) {}

// Kotlin
useSome {} // 需要是 fun interface

非常少见。

和上面的第三种情况一样，这需要 Kotlin 1.4 版本的 fun interface 才能进行 SAM 转换。

5、带有suspend函数的Kotlin接口

四天王有五个人不是常识么

fun interface Some {
 suspend fun some()
}

fun useSome(some: KotlinSome) {}

useSome {} // 嘻嘻

在 Kotlin 1.4 的测试版（里程碑版、RC版），可以编译成功，但是运行起来会炸。原因在于 Kotlin 官方团队并没有写好针对这种情况的代码生成（codegen）。于是在 Kotlin 1.4 正式版，他们就 ban 掉了这样的代码，不允许 fun interface 拥有抽象 suspend 函数。

6、一些旧版本的bug

最经典的是那个安卓的LiveData的某个函数：

val liveData = MutableLiveData<Int>()
liveData.observe({ lifecycleOwner.lifecycle }, Observer { invokeMyMethod(it) })
// 第二个参数无法进行SAM转换

详见KT-14984。

新的类型推断算法修正了这个bug。

SAM Constructor

在 1.3 以及更早的版本，针对上面所说的第二种情况，可以这样使用：

// Kotlin
fun useSome(some: JavaSome) {}

useSome(JavaSome {})

想必各位过来人都知道这样的写法。

这里 JavaSome {}，lambda 表达式前面的那个 JavaSome 就是所谓的 SAM 构造器（SAM constructor），或者说是 SAM 适配器（SAM adapter）。

在现在 1.4 版本里，SAM constructor 已经没什么用了，主要用途是“凭空捏出”一个 SAM 接口的实例：

val ktSome = KotlinSome {} // 需要是 fun interface
val javaSome = JavaSome {}

// 错误用法
// val ktSome: KotlinSome = {}
// val javaSome: JavaSome = {}

SAM constructor 可以理解为编译器为 SAM 接口生成了一个如下所示的辅助函数，但是实际上这个函数并不存在。

// 这是Java
interface JavaSome {
 void some(); 
}

// 实际上并不存在的辅助函数
inline fun JavaSome(block: () -> Unit): JavaSome {
 return 编译器的魔法
}

然后就有一些鲜为人知的用法，比如说这样：

// Kotlin
val lambda: () -> Unit = { println("test") }
val kepa: JavaSome = JavaSome(lambda) // 嘻嘻
kepa.some() // 输出 test

上面这段代码确实是可以跑的。

甚至是这样：

val lambda: () -> Unit = { println("test") }
val some: KFunction1<() -> Unit, JavaSome> = ::JavaSome // 嘻嘻
val kepa: JavaSome = some.invoke(lambda)
kepa.some()

这段代码 IDEA 不会提示错误，但是会编译失败。

表面上看确实有这个辅助函数，所以这样的代码可以通过 Kotlin 编译器前端的检查。但是实际上编译器的后端并没有办法针对这样的情况进行代码生成，彻底懵逼了，boom！

你学到了什么

• 一些无用的历史知识
• 关于 SAM constructor 的冷知识
  

本文完。

总结