重新审视 Kotlin 反射，我觉得可以合理使用

我之前每次跟别人分享 Kotlin 反射的时候，都会让大家小心点儿它，因为它一方面体积大，另一方面性能也差，不仅如此，还有一些小毛病，这些内容在我很久之前的一篇文章详细讨论了：Kotlin 反射你敢用吗？。那么时过境迁，今天的 Kotlin 反射怎么样了？

1. 不支持的 built-in Kotlin types

这个问题我们用当时的版本很容易复现，只需要运行下面的代码即可：

String::class.memberFunctions

但是，它在 1.2.60 已经修复了。也就是说，如果你使用 Kotlin 反射，请立刻马上更新到 1.2.60 以上的版本，这样就不会有 built-in types 的问题。

我们再简单唠叨几句，这个问题其实涉及到的都是 Kotlin 与 Java 存在映射关系的类，例如 String、枚举、Map 等等。

2. 运行性能差

Kotlin 反射耗时确实比 Java 反射耗时长，毕竟一方面没有 Java 虚拟机加成，Kotlin 的反射主要依赖于 @MetaData 注解，可参考：Kotlin 反射与 MetaData 的关系在混淆后浮出水面！ 和 认识下 Kotlin 反射背后的男人：@Metadata，另一方面 Kotlin 反射提供的能力也比 Java 反射多很多（这主要与 Kotlin 本身的语法特性多是相对应的），所以付出多少得到多少，只要它的慢在合理范围内，我们其实也是可以接受的。

2.1 首次运行慢

涉及到注解解析和加载的问题，第一次运行必然慢，我用 1.3.0-rc-146 简单测试了一下：

单位：μs

第一次访问 Kotlin 反射确实要慢很多。

2.2 后续运行约为 Java 反射的 1.5~2 倍

后续运行由于是直接访问内存，因此性能上不会有数量级的差别：

单位：μs

尽管仍然比 Java 反射耗时多一些，但对于使用反射的场景来说，这样通常也是可以接受的。

需要注意的是，过去的版本应该在后续的执行中也不会很慢，只是去年的文章我没有太注意这部分数据。

3. 2.5M的 Jar 包

当时提到了 2.5M 的 jar 包的问题，如果你是在 Server 端使用 Kotlin 反射，相信你也不会 care 这点儿包体积，更何况编译完之后也只有 400K 的样子，这对于 Android 应用来说也不是什么大问题，毕竟 Apk 的瘦身大头应该在资源上，也许你把设计出的某一个序列帧动画用代码实现了就可以省掉好几 MB。

4. 小结

其实之前让我觉得不安的主要是性能问题，显然这样看来倒也还好。而一些未完善的部分也在最近的版本得到了完善，因此 Kotlin 反射库的使用评级由“谨慎使用”上调为“合理使用”。