可以考虑借鉴AutoRegister的思路，把反射相关的实现替换下:)

[xiaolanger]

首先谢谢你的建议。下面我会解释为什么我没有使用

本项目用到反射的地方主要是初始化的地方，其他地方的反射基本就一次，第二次就有缓存了
后者是没啥问题的，就算 bufferknife 也还是有一次反射去寻找实现类的。
可能你觉得性能有问题的地方应该是初始化，加载各个模块的地方了。
这里讲道理确实有些不好，奔着养最好的性能上考虑，这里确实应该利用 gradle 插件去做这件事。但是我一开始没有考虑这样做的原因有以下几点：

1. 模块在我这框架中是可以卸载的，如果利用 gradle 扫描进去的方式，就不能让用户用代码去控制加载了
2. 我的框架我不想牵扯任何的动态修改代码的技术，我的目的是降低框架出现兼容性或者其他问题的可能性，所以我的框架我敢说 100% 兼容。这一点你去看下 Arouter 或者 CC 你就发现他们为什么有些用户出现兼容性或者一些乱七八糟的问题，根本原因就在这，我不想给任何一个用户带去这种问题发生的可能性
3. 其实初始化的时候反射并没有你想的那么糟糕，几毫秒的时间，很多 app 其他的性能问题都比这个糟糕很多。另外如果有些项目确实很看中这个，那你可以考虑放到子线程去初始化，把这个时间埋藏在首屏的启动动画中。很多 app 启动动画都有两三秒

再一次感谢你的反馈，谢谢。期待你的其他反馈！

From gitme iOS

[xiaolanger]

👍多谢回复，只是提供个思路:) 加油~

[robotAndroidCode]

这点我感觉确实可以优化, 因为那块对于追求性能的人就会特别难受. 还是希望有空优化下的, 尽量不要用反射. 我测试出来也有几十毫秒的延迟

[xiaojinzi123]

@robotAndroidCode @xiaolanger

很抱歉, 重新打开这个 issue. 上次你们提了 issue 之后, 我心里一直留了一个疙瘩, 在中间这段时间, 我学习 Android Gradle 插件 + ASM字节码修改. 终于把初始化的时候反射的地方都可选的可以使用 new 对象的方式. 原本我看了你们的 issue 之后, 以为这个优化是要去做的. 但是事实狠狠的打了我的脸. 下面请看我测试的两组数据。

• 测试手机 华为 P20 Pro
• 源码中的 Module 数量：5.
• 每个 Module 又会去初始化其他 5 个模块
• 所以 Component 源码中如何不使用字节码修改的技术.每次启动都会反射 5 + 5 * 5 = 30 次

下面是测试的 20 组数据, 启动完毕就杀死重新启动. 所以测试是准确的!

打印的数据格式是以下两种.

ASM字节码的打印格式：

使用反射的打印格式：

• 使用反射
  • 21, 24, 21, 22, 23, 21, 21, 21, 21, 22, 21, 20, 21, 21, 20, 20, 21, 20, 20, 20
• ASM技术
  • 17, 17, 18, 17, 17, 18, 18, 17, 17, 18, 17, 17, 17, 17, 17, 18, 19, 19, 18, 18

从数据上看到, 速度上确实有所提升! 我也不去算平均值了, 看上去整体性能提升了 2-4 毫秒!

所以从简单分析来看, 我的框架在初始化的时候使用反射的次数确实有些多, 但是从数据的测试上看, 性能没有实质性的突破, 假如从 几十毫秒降低到几毫秒, 那我觉得这件事我做的很有意义, 但是目前看来. 这个优化很失败.

如果你们有自己的测试数据, 欢迎讨论. 我用这段时间验证了这个事情,字节码优化的方式我这边也支持了. 这个 issue 我终于可以安心的关闭了, 谢谢大家