- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
PAGE \* MERGEFORMAT 27
微信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 初始化”就要执行的逻辑哪有那么多。而现在不一样,再简单的逻辑堆积起来也会变复杂。此时,在模块生命周期外的逻辑基本上只能放主工程。
此外的问题,模块边界破坏、基础工程中心化,都是代码持续劣化的帮凶。
总之在模块化上我们忽视了一些重要的问题,必须重塑。
? ?重塑模块化 ?
重
文档评论(0)