Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
xiaolanger opened this issue Oct 8, 2019 · 3 comments

Comments

@xiaolanger
Copy link

@xiaolanger xiaolanger commented Oct 8, 2019

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

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

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

再一次感谢你的反馈,谢谢。期待你的其他反馈!

:octocat: From gitme iOS

@xiaolanger

This comment has been minimized.

Copy link
Author

@xiaolanger xiaolanger commented Oct 8, 2019

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

@xiaolanger xiaolanger closed this Oct 8, 2019
@robotAndroidCode

This comment has been minimized.

Copy link

@robotAndroidCode robotAndroidCode commented Oct 12, 2019

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

@xiaojinzi123 xiaojinzi123 reopened this Oct 29, 2019
@xiaojinzi123

This comment has been minimized.

Copy link
Owner

@xiaojinzi123 xiaojinzi123 commented Oct 29, 2019

@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 毫秒!

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

如果你们有自己的测试数据, 欢迎讨论. 我用这段时间验证了这个事情, 那我本来打算后续上的 Gradle 插件 + ASM字节码 也不会上了, 完全没有上的必要了. 这个 issue 我终于可以安心的关闭了, 谢谢大家

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.