前言
随着 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() 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 的冷知识
本文完。
总结
到此这篇关于关于Kotlin中SAM转换的文章就介绍到这了,更多相关Kotlin中SAM转换内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！