首次调用Kotlin ArraysKt.contains方法耗时过高问题如何排查

你遇到的首次in操作耗时过高的问题与Kotlin标准库懒初始化无关，本质是JVM/ART虚拟机冷启动阶段的类加载与字节码初始化开销，属于基准测试未做预热导致的测量误差，可按以下步骤排查验证：

• 第一步：复现预热后耗时恢复的现象 #

  修改测试代码，提前做多次操作预热后再测速：

  import kotlin.system.measureTimeMillis
  
  fun main() {
    // 预热：提前执行1000次目标操作，触发类加载与JIT编译
    repeat(1000) {
        3 in arrayOf(4)
    }
    
    val timeInMillis = measureTimeMillis {
        repeat(1000) { // 多次调用统计平均耗时更准确
            3 in arrayOf(4)
        }
    }
    println("单操作平均耗时 ${timeInMillis / 1000.0} ms")
  }
  

  运行后可看到单操作平均耗时会降到0.001ms以下，符合该操作的预期性能。

• 第二步：通过类加载日志定位开销来源 #

  桌面JVM运行时添加启动参数-XX:+TraceClassLoading，Android运行时可以通过adb logcat过滤类加载日志，首次执行3 in arrayOf(4)时会触发kotlin.collections.ArraysKt类的加载、验证、初始化全流程，你测量到的几十ms开销完全来自该流程。
  你注释中提到的「提前调用setOf/arrayOf后耗时降为0」也验证了该结论：提前调用集合相关API时已经完成了ArraysKt类的加载，后续执行in操作不需要再走类加载流程，自然耗时接近0。

• 第三步：用专业基准测试工具确认 #

  采用JMH（Java Microbenchmark Harness）框架做标准性能测试，配置预热阶段后测试，单元素数组的contains操作耗时会稳定在几十纳秒级别，完全符合预期。

额外说明：Android设备上冷启动类加载耗时更高是ART虚拟机的正常特性，类加载过程需要做字节码验证、dex文件解析等操作，开销本身高于桌面JVM。

内容的提问来源于stack exchange，提问作者gauge