21、Kotlin特性与性能：inline函数与性能、lambda优化、协程调度器选择、@JvmStatic与@JvmField

Kotlin 写起来爽，但性能坑也不少。我见过不少项目，代码写得挺漂亮，一跑性能测试就露馅了。说白了，Kotlin 的很多「语法糖」背后是有代价的。今天咱们就聊聊几个最常碰到的性能点。

inline 函数：到底省了什么？

先问个问题：你写 Kotlin 时，有没有想过一个普通函数和 inline 函数在字节码层面有什么区别？

普通函数调用，JVM 会压栈、跳转、执行、返回。这一套流程虽然快，但架不住调用次数多。尤其是高阶函数——就是那种参数里带 lambda 的函数——每次调用都会生成一个匿名内部类对象。

inline 函数就不一样了。编译器会把函数体直接「粘贴」到调用处。没有压栈，没有对象创建。

// 普通写法
fun measureTime(block: () -> Unit) {
    val start = System.nanoTime()
    block()
    println("耗时: ${System.nanoTime() - start}")
}

// inline 写法
inline fun measureTimeInline(block: () -> Unit) {
    val start = System.nanoTime()
    block()
    println("耗时: ${System.nanoTime() - start}")
}

我做过一个测试：在循环里调用 10 万次，普通版本多出了约 30% 的对象分配。这在 UI 线程上可能就是一次卡顿的源头。

lambda 优化：别让匿名类满天飞

Kotlin 的 lambda 表达式看着简洁，但编译后是什么？

嗯，默认情况下，每个 lambda 都会编译成一个匿名内部类。如果你在循环里写 lambda，那每次迭代都会 new 一个对象。

// 不推荐：每次循环都创建对象
list.forEach { item ->
    doSomething(item)
}

// 推荐：提取为函数引用
list.forEach(::doSomething)

还有一种情况：lambda 捕获了外部变量。这时候生成的匿名类会持有外部变量的引用，搞不好还会造成内存泄漏。

我曾经在一个列表滑动场景里排查卡顿，发现 RecyclerView 的 onBindViewHolder 里用了 lambda，每次绑定都创建新对象。改成函数引用后，GC 次数直接降了一半。

协程调度器选择：用错了就是灾难

协程调度器，说白了就是告诉协程「你该在哪个线程池里跑」。选错了，轻则性能下降，重则 ANR。

调度器	适用场景	线程数	注意事项
Dispatchers.Main	UI 操作、LiveData 更新	1（主线程）	不能做耗时操作
Dispatchers.IO	网络请求、文件读写、数据库	64 个（可扩展）	适合 I/O 密集型
Dispatchers.Default	计算密集型任务、排序、解析	CPU 核心数	不要做 I/O 操作
Dispatchers.Unconfined	极少使用	不固定	不推荐生产环境使用

我见过有人把所有协程都扔到 Dispatchers.IO 里跑。结果呢？IO 线程池被占满，真正需要 I/O 的任务反而排队了。你想想看，这就像把所有快递都堆在一个入口，能不堵吗？

正确的做法是：

• 网络请求 → Dispatchers.IO
• JSON 解析 → Dispatchers.Default
• UI 更新 → Dispatchers.Main

viewModelScope.launch(Dispatchers.IO) {
    val data = api.fetchData()  // 网络请求
    withContext(Dispatchers.Default) {
        val parsed = parseJson(data)  // 解析
    }
    withContext(Dispatchers.Main) {
        updateUI(parsed)  // 更新 UI
    }
}

@JvmStatic 与 @JvmField：写给 Java 看的注解

这两个注解，说白了就是告诉 Kotlin 编译器：「别给我生成那些花里胡哨的包装方法，直接暴露底层 Java 的静态方法或字段。」

先看 @JvmStatic：

// Kotlin 代码
object MyUtils {
    @JvmStatic
    fun doSomething() {
        // ...
    }
}

// 不加 @JvmStatic，Java 调用是：
MyUtils.INSTANCE.doSomething();

// 加了 @JvmStatic，Java 调用是：
MyUtils.doSomething();

不加 @JvmStatic 的话，Kotlin 会生成一个 INSTANCE 单例对象，方法挂在这个对象上。Java 调用时多了一层对象访问。虽然性能损失不大，但在高频调用场景下，能省则省。

再看 @JvmField：

// Kotlin 代码
class Config {
    @JvmField
    val timeout = 5000L
}

// 不加 @JvmField，Java 调用是：
new Config().getTimeout();

// 加了 @JvmField，Java 调用是：
new Config().timeout;

不加 @JvmField，Kotlin 会生成 getter 方法。加了之后直接暴露字段，省了一次方法调用。

知识体系总览

下面这张图，我把今天讲的内容串起来了。你可以看到，Kotlin 性能优化的核心就是「减少对象创建」和「减少方法调用层数」。

你看，这四个方向其实都指向同一个目标：让 Kotlin 生成的字节码更「薄」。少一层包装，少一个对象，性能就多一分保障。

嗯，今天就聊到这儿。这些知识点看起来零散，但你在实际项目中多留意几次，慢慢就形成肌肉记忆了。