微信Android模块化架构重构实践资源-CSDN文库

43 浏览量 2021-02-25 15:04:23 上传评论 1 收藏 492KB PDF 举报

资源推荐

资源详情

资源评论

微信微信Android模块化架构重构实践模块化架构重构实践

微信Android架构历史

微信Android诞生之初，用的是常见的分层结构设计。这种架构简单、清晰并一直沿袭至今。这是微信架构的v1.x时代。

图1-架构演进

到了微信架构的v2.x时代，随着业务的快速发展，消息通知不及时和Android 2.3版本之前webview内存泄露问题开始突显。由

于代码、内存、apk大小都在增长，对系统资源的占用越来越多，导致微信进程容易被系统回收。因此微信开始转向多进程架

构，独立的通信进程保持长连接的稳定性，独立的webview进程也阻隔了内存泄露导致的问题。

时间继续推进，我们也遇到了65535问题和LinearAlloc问题。这时的微信已经具备了许多功能像朋友圈、摇一摇、附近的人等

等，分离核心功能和其他业务模块变得越发重要。为此，微信开启了第三次架构改造(v3.x)。我们对各种产品功能进行解耦并

拆分到相互独立的p_xxx工程中，这是微信第一次进行模块化架构的重构。经过几个月的努力，微信拆出了几十个p工程，它

们都通过基础组件访问网络、存储等服务，互相独立并行。新的p工程架构支撑了微信更快速的业务发展，配合多分支开发模

式的改进，能够支持团队多分支多team的并行开发。

图2 - 架构图

为何再次重构微信

原本好好的架构出了什么问题？

从上个架构之后的两年多时间里，微信Android基本没有大的架构改动。配合gradle的编译，以及git的多分支并行开发，微信

的模块工程数量不断增多，支撑了游戏、支付等大功能，可以说这段时间里原有架构起到了很好的作用。

然而随着代码继续膨胀，一些问题开始突显出来。首先出问题的是基础工程libnetscene和libplugin。基础工程一直处于不断膨

胀的状态，同时主工程也在不断变大。同时基础工程存在中心化问题，许多业务Storage类被附着在一个核心类上面，久而久

之这个类已经没法看了。此外当初为了平滑切换到gradle避免结构变化太大以及太多module，我们将所有工程都对接到一个

module上。缺少了编译上的隔离，模块间的代码边界出现一些劣化。虽然紧接着开发了工具来限制模块间的错误依赖，但这

段时间里的影响已经产生。在上面各种问题之下，许多模块已经称不上“独立”了。所以当我们重新审视代码架构时，以前良好

模块化的架构设计已经逐渐变了样。

图3 - 架构逐渐的变化

“君有疾在腠理，不治将恐深”，在我们还在犹豫到底要不要重构的时候，硬件同学向我们提出了需求。希望将微信Android代

码移植到类似微信相册这样产品中。这样就可以快速跟进微信业务最新的支撑组件、协议、安全性、后台服务等能力，而且代

码要尽可能精简，可以选择和定制模块，可以移植模块来实现原型尝试。但就之前的情况来说，微信一时难以满足。这下定

了，还得重构。

于是我们回过头仔细看之前的设计，找找问题究竟是怎么来的。

问题出在哪

先寻找代码膨胀的原因。

翻开基础工程的代码，我们看到除了符合设计初衷的存储、网络等支持组件外，还有相当多的业务相关代码。这些代码是膨胀

的来源。但代码怎么来的，非要放这？一切不合理皆有背后的逻辑。在之前的架构中，我们大量适用Event事件总线作为模块

间通信的方式，也基本是唯一的方式。使用Event作为通信的媒介，自然要有定义它的地方，好让模块之间都能知道Event结

构是怎样的。这时候基础工程好像就成了存放Event的唯一选择——Event定义被放在基础工程中；接着，遇到某个模块A想使

用模块B的数据结构类，怎么办？把类下沉到基础工程；遇到模块A想用模块B的某个接口返回个数据，Event好像不太适合？

那就把代码下沉到基础工程吧……

就这样越来越多的代码很“自然的”被下沉到基础工程中。

我们再看看主工程，它膨胀的原因不一样。分析一下基本能确定的是，首先作为主干业务一直还有需求在开发，膨胀在所难

免，缺少适当的内部重构但暂时不是问题的核心。另一部分原因，则是因为模块的生命周期设计好像已经不满足使用需要。之

前的模块生命周期是从“Account初始化”到“Account已注销”，所以可以看出在这时机之外肯定还有逻辑。放在以前这不是个大

问题，刚启动还不等“Account初始化”就要执行的逻辑哪有那么多。而现在不一样，再简单的逻辑堆积起来也会变复杂。此

时，在模块生命周期外的逻辑基本上只能放主工程。

此外的问题，模块边界破坏、基础工程中心化，都是代码持续劣化的帮凶。

总之在模块化上我们忽视了一些重要的问题，必须重塑。

重塑模块化

重塑模块化，我们分解为三个目标：

1.改变通信方式

2.重新设计模块

3.约束代码边界

改变通信方式

前面讲过，我们使用Event总线作为模块间通信的媒介，这种设计很常见。然而当回顾整体代码时能发现，Event并非所有通

信需要的最佳形式。它的特点适合一对多的广播场景，依赖关系弱。一旦遇到需要一组业务接口时，用Event写起来那是十分

痛苦的。也正因如此，这种情况下大家都跳过了Event的使用，直接将代码下沉到了基础工程，共享代码，进而导致基础工程

的不断膨胀。

所以选个合适的通信方式很有必要，我们希望兼顾考虑开发的便利性和协议的约束性。

Event不合适。协议通信如何？

我们理解的协议通信，是指跨平台/序列化的通信方式，类似终端和服务器间的通信或restful这种。现在这种形式在终端内很常

见了。协议通信具备一种很强力解耦能力，但也有不可忽视的代价。无论什么形式的通信，所有的协议定义需要让通讯两方都

能获知。通常为了方便会在某个公共区域存放所有协议的定义，这情况和Event引发的问题有点像。另外，协议如果变化了，

两端怎么同步就变得有点复杂，至少要配合一些框架来实现。在一个应用内，这样会不会有点复杂？用起来好像也不那么方

剩余11页未读，继续阅读

内容反馈

weixin_38527978

粉丝: 5
资源: 900

最新资源

资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！点击此处反馈

feedback-tip