目录

一次暂时失败的框架探索

一次暂时失败的框架探索

事件起因

由于 kapt 的大量耗时, 事实上我们在 Debug 时会尽量避免使用 kapt, 甚至直接禁用 kapt, 这时我们的解决方案往往是: debug 提供一套反射方案, release 提供一套 kapt 方案, 我想做的事情, 就是需要这两个解决方案提供一套通用的api, 然后使用它.

我的方案

我当时想法就是:

  • debug 阶段使用动态代理
  • release 阶段使用 kapt

但是事实上, 在运行时去扫描所有类并查看其有没有添加什么注解, 是困难的, 是非常耗时的, 远比 kapt 找到指定的注解进行处理复杂得多.

总结

动态代理通过反射可以避免编译隔离的问题, 但是扫描注解需要繁琐的遍历.

kapt 无法解决编译隔离, 生成代码可以不按照动态代理那样只能传入接口, 可以生成任意代码.

ASM 操作字节码的灵活性相当之高, 可以轻松修改一部分字节码, 一样是影响了编译速度, 只是没那么严重.


三种方式各有自己优势所在, 统一形态实现成本相对于带来的收益, 不值得, 完全不如每个库去单独实现

希望有优秀的同学可以有更好的思路.