10｜架构改造：5个步骤，高效推动组件化架构重构

黄俊彬

你好，我是黄俊彬。
在过去的很多咨询项目中，我发现一个很有意思的现象——项目的架构设计是一回事，代码落地又是另外一回事，很多架构设计最终都只是落在了 PPT 上。发生这类现象，一方面可能是因为后续架构腐化了，缺少守护；另一方面是实际落地到代码的改造环节，它的复杂度比纸上画图高得多。
所以，我根据以往多个大型遗留系统的改造经验，将重构的改造流程分为了 5 个步骤，帮你安全、高效地进行规模化架构重构落地，并通过自动化手段来守护。
如上图所示，这 5 个步骤分别是设计、守护、解耦、移动和验收。在前面的基础篇和分析设计篇，我们已经详细讲过了设计和守护；而移动和验收相对比较简单，我们只要掌握使用 IDE 进行自动化移动，并按照验收标准验证就可以了。因此，解耦这个步骤才是落地代码改造的核心步骤。
这节课我会按照第 5 节课的架构设计来重构 Sharing 的代码。这个过程里，我会带你掌握 4 种常用的解除依赖的手法，分别是类下沉、依赖接口、事件总线以及路由。
第一步：设计，识别内聚的组件在第 5 节课中我们对组件的类型进行了划分，也对 Sharing 进行了一次全景的组件梳理，把组件分成了业务组件、功能组件和技术组件这三类。
设计这一步其实就是在识别内聚的组件，不过当时我并没有展开说明如何识别这 3 类组件，现在我们就来做个分析。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

本文介绍了组件化架构重构的5个关键步骤，包括设计、守护、解耦、移动和验收。在设计步骤中，作者提出了识别内聚组件的方法，并将其分为业务组件、功能组件和技术组件。在守护步骤中，强调了增加自动化测试以确保重构不破坏原有功能。解耦步骤介绍了四种常用的解除依赖的手法，包括类下沉、依赖接口、事件总线和路由。移动步骤则使用Modularize将整个包移动到独立的模块中去。最后，验收阶段需要满足编译通过、架构守护用例执行通过和验收自动化测试执行通过等条件。整篇文章通过实际案例和操作步骤，为读者提供了实用的架构改造方法，帮助他们安全、高效地进行规模化架构重构落地，并通过自动化手段来守护。文章还提出了思考题，引发读者对反射在项目中使用的优缺点进行思考和讨论。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《大型 Android 系统重构实战》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(4)

最新
精选

叫我怪兽好了
反射在带来解耦便捷的同时也带来了风险，比如耗时、类被移动到其他包、删除，以及后期的维护，为了保证运行时的安全，通常还需要加上一大堆的 try-catch。总的来说，个人感觉收益没有成本高。
作者回复: Hi，风险点总结得很好👍。后续介绍组件化和路由框架会再详细介绍反射的运用。
2023-03-03归属地：上海

2
Paul Shan
我的经验是EventBus最好不要用，因为很容易被滥用，我有一次处理一个遗留代码花了很长时间才搞清楚，原因就是EventBus，当EventBus的事件被分发了五六次之后，事件之间的依赖关系就变得非常复杂，这些事件可能一开始是简单的，被人不断添加之后就变得晦涩难懂，很难维护，这种腐败是渐进的，光从代码审查上不容易察觉，请问老师有什么好办法来避免EventBus被滥用吗
作者回复: 先制定规范，团队内达成一致。另外可以增加代码依赖检查，并且加强code review的检查。
2023-06-11归属地：澳大利亚

1
Geek_a8c1a2
这里我有个问题，如果项目工程巨大，比如PDD、美团、字节这种大厂的App，那么功能组件、技术组件、业务组件必然非常多，看您的配置都是module级别，这样的问题是随着module的增加，module 数量的增加对 IDE 性能（尤其是 Sync 和 Index 耗时）的影响是不容忽视的。也很有可能出现“IDE Sync 直接触发 OOM” 的尴尬局面。不知道您有什么这方面的见解
作者回复: Hi，后续持续交付篇会有二进制的依赖改造，项目工程巨大通常采用分而治之的策略以及二进制依赖的方式。
2023-03-06归属地：新加坡
3
1
peter
请教老师几个问题： 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：只能说类似，但不能说等价。
2023-03-04归属地：北京

1

收起评论