叫我怪兽好了2023-03-03 来自上海反射在带来解耦便捷的同时也带来了风险，比如耗时、类被移动到其他包、删除，以及后期的维护，为了保证运行时的安全，通常还需要加上一大堆的 try-catch。总的来说，个人感觉收益没有成本高。作者回复: Hi，风险点总结得很好👍。后续介绍组件化和路由框架会再详细介绍反射的运用。
2
Geek_a8c1a22023-03-06 来自新加坡这里我有个问题，如果项目工程巨大，比如PDD、美团、字节这种大厂的App，那么功能组件、技术组件、业务组件必然非常多，看您的配置都是module级别，这样的问题是随着module的增加，module 数量的增加对 IDE 性能（尤其是 Sync 和 Index 耗时）的影响是不容忽视的。也很有可能出现“IDE Sync 直接触发 OOM” 的尴尬局面。 不知道您有什么这方面的见解作者回复: Hi，后续持续交付篇会有二进制的依赖改造，项目工程巨大通常采用分而治之的策略以及二进制依赖的方式。
共 3 条评论1
peter2023-03-04 来自北京请教老师几个问题： Q1：依赖接口这种方法难道不适用于功能组件和技术组件？ 文中提到“依赖接口是指将原先直接依赖具体的实现，解耦成依赖稳定的抽象接口。这个解除依赖的手法适用于业务组件之间的依赖”，从这句话看，似乎只用于解耦业务组件之间的依赖，难道不适用于功能组件和技术组件？ Q2：热更新不实用吗？ 我在一个群里咨询，有一些人认为“中小公司不用这个方法，有技术难度，有坑，而且google官方不支持这种做法”，还是要做正常的更新流程。 老师怎么看待这个问题。 Q3：EventBus没有过时吗？ 五年前用的就是EventBus。五年过去了，EventBus还是最好的吗？没有新的此类框架吗？（这几年很少用安卓，不清楚变化） Q4：EventBus类似于消息队列？ 后端微服务架构也要用事件总线，具体实现就是采用消息队列，比如RocketMQ。（所以我一般就认为事件总线就等价于消息队列，不知道这个观点是否对）。 EventBus类似于消息队列吗？（或者说，EventBus是一种简单的消息队列？）作者回复: Hi，peter。 Q1：不是完全不适用，只是在业务组件解耦使用得更多。 Q2：我的理解不是不实用，挺有用的。只是目前官方的方案（https://developer.android.com/guide/playcore/feature-delivery?hl=zh-cn）需要使用Google Play的API，国内用不了。开源的其他框架难以保证后续大版本升级的兼容性，可能有坑。 Q3：没有，但是不是最好得结合项目的情况及使用场景。 Q4：只能说类似，但不能说等价。
1- Paul Shan2023-06-11 来自澳大利亚我的经验是EventBus最好不要用，因为很容易被滥用，我有一次处理一个遗留代码花了很长时间才搞清楚，原因就是EventBus，当EventBus的事件被分发了五六次之后，事件之间的依赖关系就变得非常复杂，这些事件可能一开始是简单的，被人不断添加之后就变得晦涩难懂，很难维护，这种腐败是渐进的，光从代码审查上不容易察觉，请问老师有什么好办法来避免EventBus被滥用吗1