kotlin SAM 优化，不注意就会踩坑！
关键字：kotlin，SAM，优化，坑，object，singleton，LiveData，Android Archicture Components (AAC)
前言
kotlin 给我们广大的 android 和 java 使用者带来了便利的语法糖，提供了很多好用的、可以大大提高开发效率的函数封装。但是，封装的过程中，有一些细节，如果不注意就会踩坑，甚至引起程序的崩溃！本文会先带大家看看，kotln 对于 SAM 的优化，之后会带大家看一个由此引发的非常隐晦的崩溃。
什么是 SAM
SAM 的全称是：Single Abstract Method interfaces。也就是说，一个接口里面只有一个方法。我们平时开发最常用的 SAM 应该就是 Runnable 了吧！
平时我们的做法是：
new Runnable() {
@Override
public void run() {
System.out.println("inside runnable");
}
};
使用了 SAM 优化之后的写法是这样的：
val runnable = Runnable { println("This runs in a runnable") }
val executor = ThreadPoolExecutor()
// Java signature: void execute(Runnable command)
executor.execute { println("This runs in a thread pool") }
SAM 的坑
说了这么多，看起来 SAM 就是给我们封装了一层语法糖，让我们少写了一点代码，这看起来是一个有利无害的东西，怎么就有坑了呢？原来，kotlin 对 SAM 的优化不仅停留在语法层面，还涉及编译期。kotlin 如果检测，这个 SAM 本身没有引用外部类的变量，那么 kotlin 就会把 SAM 替换成一个 object，也就是 singleton，单例。如果检测到这个 SAM 有对外部类的引用，那么就会老老实实的把这个 SAM 使用类似 java 中匿名内部类的方式来实现。
举个例子，比如我有这么一个 java interface：
public interface SimpleInterface {
String getResult(String prefix);
}
然后我在kotlin 里面这么调用：
class TestSam {
fun test_Singleton() {
TestSam().target_JavaInterface(SimpleInterface { "|| called" })
}
fun test_newObject() {
TestSam().target_JavaInterface(SimpleInterface { "${this::class.java.simpleName} || called" })
}
fun target_JavaInterface(simpleInterface: SimpleInterface) {
println("inside target_JavaInterface: ${simpleInterface.getResult("123")}")
}
}
然后我们将其编译为字节码，再用 java 的反编译工具打开，就会发现，生成的等价 java 代码是：
public final class TestSam {
public final void test_Singleton() {
(new TestSam()).target((SimpleInterface)null.INSTANCE);
}
public final void test_newObject() {
(new TestSam()).target((SimpleInterface)(new SimpleInterface() {
@NotNull
public final String getResult(String it) {
return TestSam.this.getClass().getSimpleName() + " || called";
}
}));
}
public final void target(@NotNull SimpleInterface simpleInterface) {
Intrinsics.checkParameterIsNotNull(simpleInterface, "simpleInterface");
String var2 = "inside test1: " + simpleInterface.getResult("123");
boolean var3 = false;
System.out.println(var2);
}
}
观察上面的结果，我们发现：第一个 test_Singleton 方法中，调用的是一个 INSTANCE，这就是说明，kotlin 会在编译后，把对这个 SAM 的调用，替换成对一个 singleton 的调用；而观察 test_newObject 方法，我们可以发现，就是普通的使用了 java 中的匿名内部类来做相关的操作。原因就是，我们在 test_newObject 中引用了这段代码：this::class.java.simpleName ，kotlin 编译的时候识别出这段代码有对外部类的引用，所以必须用保守的匿名内部类的方式来实现相关的逻辑。
SAM 优化的好处
好处很简单，就是会减少对象的创建。一般情况下，减少对象的创建都可以视为对 java 代码的一种优化手段。
具体的坑在哪？
前面说到，SAM 有的时候会用 singleton 的方式来实现，有的时候会用匿名内部类的方式来实现。那么我们实战的时候，就很可能因为会不小心在必须使用匿名内部类，也就是必须创建一个新的对象的场景下，因为没有注意，没有引用外部类的变量，进而导致编译出来的代码其实是一个 singleton 的实现，进而抛出异常，引起崩溃。
最常见的可能就是 android 里面跟生命周期相关的代码，比如下面对 LiveData 使用的一个示例：
getLiveDate().observe(this, Observer {
when (it ?: 0) {
0 -> {}
1 -> {}
}
})
如果这段代码写在 Activity a 的 onCreate 中，然后在 Activity b 中有一个按钮，点击之后就会启动 Activity a，然后用户狂点两次，如果不做点击事件防抖处理的话，就会创建两个 Activity a，先不说这个情况是否需要通过产品逻辑来规避，单说这个 case，在运行的时候会奔溃，因为我们试图把一个 singleton 设置给不同的 LiveData。java.lang.IllegalArgumentException: Cannot add the same observer with different lifecycles
解决方法
如果产生了类似上文的问题，我们应该怎么解决呢？
一种方法就是不用 SAM，只用 kotlin 的 object 表达式，这样能保证 kotlin 的 SAM 代码肯定能被编译成匿名内部类的实现方式。这种方式的好处是，会规避因为开发人员不小心或者对这个知识点没有了解，而写出不符合预期的代码。坏处就是，可能得忍受 kotlin 的黄色提醒：因为kotlin 会建议我们把这段代码改成 SAM 的形式。。。另一种方法，就是在 SAM 中引用外部类的变量，比如打一个 log 之类的。好处是比较简单。但是坏处是，难以通过代码的书写，把这里的相关知识传递给后续的开发人员，可能会导致后续的持续开发过程中，把这个 log 给删除，然后进而导致生成了 singleton 的代码。
