第27章 ART与Kotlin

课程目录第27章 ART与Kotlin

第27章 ART与Kotlin：协程、内联与空安全

说实话，Kotlin 在 Android 上能火起来，ART 功不可没。很多人觉得 Kotlin 就是个语法糖，但深入 ART 层面你会发现，它和 Java 的差异远比想象中大。今天我们就聊聊 Kotlin 的三个核心特性——协程、内联函数、空安全——在 ART 里到底是怎么玩的。

27.1 Kotlin 协程在 ART 中的实现

协程这东西，说白了就是用户态线程。但 ART 本身并不认识协程，它只认识线程。那 Kotlin 是怎么让协程跑起来的？

我刚开始研究协程实现时，第一反应是「这肯定用了字节码增强」。后来翻了源码才发现，Kotlin 协程的核心机制其实很简单——状态机 + Continuation 传递。

27.1.1 挂起函数的本质

一个 suspend 函数编译后，会多出一个 Continuation 参数。这个参数就是协程恢复执行的入口。看个例子：

// Kotlin 源码
suspend fun fetchData(): String {
    val result = doNetworkCall()  // 挂起点
    return process(result)
}

// 编译后（简化版）
public final Object fetchData(Continuation<? super String> continuation) {
    // 状态机实现
    switch (continuation.label) {
        case 0:
            continuation.label = 1;
            if (doNetworkCall(continuation) == COROUTINE_SUSPENDED) {
                return COROUTINE_SUSPENDED;
            }
            break;
        case 1:
            // 恢复执行
            break;
    }
    return process(result);
}

这里有个关键点：COROUTINE_SUSPENDED 是一个特殊标记。ART 看到这个返回值时，就知道当前线程可以去做别的事了。等网络请求完成，协程调度器会把 Continuation 交给某个线程继续执行。

核心理解：协程挂起不是线程阻塞。线程在协程挂起期间可以执行其他协程，这才是协程高效的根本原因。

27.1.2 ART 层面的优化

ART 对协程做了哪些优化？我印象最深的是内联缓存（Inline Cache）。

协程的 Continuation 本质上是个接口，每次调用都要走虚方法分派。ART 的 JIT 编译器会识别出热点协程，把 Continuation 的调用点直接内联成具体实现。我在项目中测过，优化后协程切换开销能降低 30% 以上。

另外，ART 的 GC 对协程对象也有特殊处理。协程的局部变量生命周期往往很短，ART 的并发标记清理（CMS）能快速回收这些短期对象，减少 STW 时间。

避坑指南：我曾经在项目中遇到协程泄漏问题——协程持有 Activity 引用导致内存泄漏。排查后发现是 Continuation 链没正确取消。记住：viewModelScope 和 lifecycleScope 会自动处理，但自定义 Scope 一定要手动取消。

27.2 内联函数与优化

Kotlin 的 inline 关键字，很多人觉得就是「把函数体复制到调用处」。这话没错，但 ART 层面的优化远不止这么简单。

27.2.1 内联的编译时行为

Kotlin 编译器处理内联函数时，会把函数体直接插入调用点。这带来的好处很明显：

消除函数调用开销（栈帧创建、参数传递）
允许 lambda 表达式内联（非内联函数中的 lambda 会生成匿名类）
支持 reified 类型参数（运行时保留泛型信息）

看个 reified 的例子：

inline fun <reified T> isInstance(value: Any): Boolean {
    return value is T  // 编译后直接变成 instanceof 指令
}

// 使用
val result = isInstance<String>("hello")
// 编译后等价于：val result = "hello" instanceof String

这里有个细节：reified 之所以能工作，是因为内联后类型参数变成了具体类型。ART 在执行 instanceof 指令时，会直接检查对象的 Klass 指针，非常高效。

27.2.2 ART 的二次内联

Kotlin 编译器做完内联后，ART 的 JIT 还会再做一次内联。为什么？

因为 Kotlin 的内联是编译时行为，它只处理了 Kotlin 代码层面的调用。但 ART 的 JIT 能看到更底层的信息——比如某个虚方法调用点，90% 的情况下都指向同一个实现类。JIT 会把这个调用点直接替换成目标方法的代码，这叫「守护内联」（Guarded Inlining）。

我遇到过一种情况：Kotlin 内联了一个很大的函数，导致调用点代码膨胀。ART 的 JIT 发现这个热点方法太大了，反而放弃了二次内联。嗯，这里要注意——内联不是越大越好，适度内联才能让 ART 发挥最佳性能。

注意：过度使用 inline 会导致代码体积膨胀。ART 的 dex2oat 在编译成机器码时，膨胀的代码会占用更多内存。我建议只在以下场景使用内联：

高阶函数（参数包含 lambda）
需要 reified 类型参数
性能敏感的短小函数

27.3 空安全与类型擦除

Kotlin 的空安全，说白了就是编译器帮你插了一堆 null 检查。但 ART 层面是怎么处理的？

27.3.1 空安全的字节码实现

Kotlin 的可空类型 String? 和不可空类型 String，在字节码层面其实没有区别。编译器只是在调用处插入了 ifnull 检查。看个例子：

// Kotlin
fun printLength(s: String) {
    println(s.length)
}

// 编译后（简化）
public final void printLength(String s) {
    if (s == null) {
        throw new NullPointerException("s must not be null");
    }
    System.out.println(s.length());
}

这里有个性能问题：每个不可空参数都会生成 null 检查。ART 的 JIT 会做逃逸分析，如果它能证明某个参数一定不为 null，就会把检查优化掉。我在项目中用 @NotNull 注解配合 ART 的优化，确实看到了一些性能提升。

27.3.2 类型擦除的真相

Kotlin 的泛型在运行时也会被擦除，和 Java 一样。但 inline + reified 可以绕过这个限制。

为什么？因为内联后，泛型参数变成了具体类型。ART 在执行时看到的是 ArrayList<String> 的字节码，但实际上运行时只有 ArrayList，类型信息已经丢了。

我踩过一个坑：用 is 检查泛型类型：

fun <T> checkType(value: Any) {
    if (value is T) {  // 编译错误：Cannot check for instance of erased type
        // ...
    }
}

// 正确做法：使用 reified
inline fun <reified T> checkType(value: Any) {
    if (value is T) {  // 编译通过
        // ...
    }
}

非内联函数中，T 在运行时就是 Object，所以 value is T 没有意义。内联后 T 变成了具体类型，ART 就能执行 instanceof 检查了。

27.4 知识体系总览

下面这张图总结了 Kotlin 三个特性在 ART 中的实现路径：

27.5 总结与建议

聊了这么多，其实就一句话：Kotlin 的特性在 ART 层面都有对应的优化策略。理解这些底层实现，能帮你写出更高效的代码。

我个人习惯在性能敏感的场景下，优先使用内联函数 + reified 泛型。协程方面，尽量使用官方 Scope，避免手动管理 Continuation。空安全虽然方便，但不要过度依赖——有时候显式的 null 检查反而更清晰。

最后分享一个经验：如果你发现某个 Kotlin 特性在 ART 上表现不佳，不妨看看字节码。用 javap -c 反编译一下，很多问题就一目了然了。

📚 课程目录