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

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

1. 不支持的 built-in Kotlin types

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

 
   
  1. 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


构造对象 访问属性 修改属性 调用方法
Java 反射 2888.1 347.9 70.8 78.8
Kotlin 反射 1440742.1 61179.5 3496.7 199.3

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

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

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

单位:μs


构造对象 访问属性 修改属性 调用方法
Java 反射 15.5 16.8 11.0 26.3
Kotlin 反射 20.2 38.6 48.4 33.5

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

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

3. 2.5M的 Jar 包

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

4. 小结

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


转载请注明出处:微信公众号 Kotlin

重新审视 Kotlin 反射,我觉得可以合理使用_第1张图片

广告时间

如果你有一定的 Android 基础,恰好还想要深入学习Kotlin,建议留意下我的 Kotlin 新课 “基于 GitHub App 业务深度讲解 Kotlin1.2高级特性与框架设计”。

上线之后,大家普遍反映有难度,有深度,如果哪位朋友想要吊打 Kotlin,不妨来看看哦!

https://coding.imooc.com/class/232.html

重新审视 Kotlin 反射,我觉得可以合理使用_第2张图片


你可能感兴趣的:(重新审视 Kotlin 反射,我觉得可以合理使用)