微信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初始化”就要执行的逻辑哪有那么多。而现在不一样，再简单的逻辑堆积起来也会变复杂。此时，在模块生命周期外的逻辑基本上只能放主工程。
此外的问题，模块边界破坏、基础工程中心化，都是代码持续劣化的帮凶。
总之在模块化上我们忽视了一些重要的问题，必须重塑。
重塑模块化
重塑模块化，我们分解为三个目标：
改变通信方式
前面讲过，我们使用Event总线作为模块间通信的媒介，这种设计很常见。然而当回顾整体代码时能发现，Event并非所有通信需要的最佳形式。它的特点适合一对多的广播场景，依赖关系弱。一旦遇到需要一组业务接口时，用Event写起来那是十分痛苦的。也正因如此，这种情况下大家都跳过了Event的使用，直接将代码下沉到了基础工程，共享代码，进而导致基础工程的不断膨胀。
所以选个合适的通信方式很有必要，我们希望兼顾考虑开发的便利性和协议的约束性。
Event不合适。协议通信如何？
我们理解的协议通信，是指跨平台/序列化的通信方式，类似终端和服务器间的通信或restful这种。现在这种形式在终端内很常见了。协议通信具备一种很强力解耦能力，但也有不可忽视的代价。无论什么形式的通信，所有的协议定义需要让通讯两方都能获知。通常为了方便会在某个公共区域存放所有协议的定义，这情况和Event引发的问题有点像。另外，协议如果变化了，两端怎么同步就变得有点复杂，至少要配合一些框架来实现。在一个应用内，这样会不会有点复杂？用起来好像也不那么方便？更何况它究竟解决多少问题呢。
所以我们想要简单点。经过权衡，我们决定用模块提供“SDK”的方式作为它与其他模块进行通信的手段。
通常“SDK”提供的是什么，是接口 + 数据结构。这种方式好处明显：实现简单也能解决问题，IDE容易补全、调用接口方便，不用配合工具，协议变化直接反映在编译上，维护接口也简单了。
其实想想，用协议的方式在终端内作为通信手段，开发效率低，也容易出错。因此可能会诞生各种框架和工具来提升这里损失的效率。到头来，是不是大家都实现了一套类似RPC这样的封装。其实本地的通信，能用接口就挺好，不能用的时候，再用协议封装也来得及。
确定了方案，实现起来就很简单。我们的注册方式和接口访问都很简单。用接口注册，再用接口访问，不暴露实现细节。如下图。
图4 - 注册接口
图5 - 访问接口
接下来，怎么暴露接口更方便？
模块暴露“SDK”的方式无非就是新建个“SDK”工程，剥离接口和数据结构到该工程里面，然后让其他模块引用编译。但这样有点麻烦，能不能再方便点？
当然有办法。我们实现了另一种接口暴露的形式——“.api化”。
使用方式和思路都很简单。对于java文件，将工程里想要暴露出去的接口类后缀名从“.java”改成“.api”，就可以了。
而且并不只是java文件，其他文件如果也想暴露，在文件名后增加".api”，也一样可以。
图6 - “.api化”
当然，要让工程支持这样的方式，gradle文件肯定会有一点改变。
settings.gradle
build.gradle
图 7 - settings.gradle & build.gradle
就这样，可以说暴露接口变得非常容易，不用担心实现类也被人引用到。而它的实现原理也相当简单：自动生成一个“SDK”工程，拷贝.api后缀文件到工程中就行了，后面其他工程依赖编译的只是这个生成的工程。简单好用。
还有个细节，如果想编辑.api后缀的java文件，为了能让Android Studio继续高亮该怎么办？可以在File Type中把.api作为java文件类型。
图8 - 设置File Types
重新设计模块
要把模块重新设计，还要做好几件事。首先，消灭代码经常下沉的“三不管区域”——基础工程。这意味着原来的模块要把之前下沉的代码重新认领回去。
图9 - 分层结构改造
为了巩固替代基础工程的mmkernel层，不被滥用为新的代码堆放处，顺便还要解决中心化问题。就必须强化它的职责和设计。
mmkernel结构可以很通用的定义为CoreAccount/CoreNetwork/CoreStorage三个部分，分别提供了核心账号状态（初始化、注销）、网络状态回调（链接建立）、存储状态生命周期（db创建、销毁、用户存储路径切换、sdcard挂起）。
图10
再然后是生命周期问题，我们需要重新设计正确的生命周期。
之前讲过，我们的模块生命周期大体上只有“Account初始化”和“Account注销”两个阶段。这已经不够用了。
所以扩大模块的生命周期，就给了模块实现各种代码需要的时机，才能避免大家往主工程塞代码。
图11
实现新的生命周期是一个正确的选择，同时产生了解决另一个问题的机会——复杂的启动流程。
要知道主工程的代码一部分原因是启动流程堆积造成的，逻辑多了代码自然多。随之而来的问题就是代码多了，逻辑也就跟着复杂起来。微信的初始化逻辑是顺序排列在一起并从上到下执行，某种情况下还会异步启动。当程序启动流程比较复杂时，这样的代码会产生“隐性依赖”的问题。“隐性依赖”顾名思义就是：原本并应该存在依赖的代码，随着版本的迭代逐渐产生了依赖，而且还不明显。这样的情况会让情况恶化，大家只敢往里面堆代码，但却不敢“乱动”。
所以重新设计的模块应该要彻底避免这些问题。
我们重新定义了模块的生命周期，将模块的生命周期延长到应用启动和退出。而后，每个模块都可以定义一个Plugin类，作为模块的“支柱”或“起点”。作为解决初始化问题的手段，它具备几个主要阶段：dependency()、configure()、execute()
图12 - plugin初始化的几个阶段
dependency()阶段，用于设置需要依赖的其他Plugin，当然提供那个Plugin的别名接口类就可以了。
图13 - 设置dependency
依赖阶段我们会生成整个模块的依赖树。这与编译时的依赖不同。通常的依赖关系是分为两种的，一种是类型依赖也就是编译期依赖，需要被依赖模块提供具体类型才能编译通过；另一种依赖则是运行期的逻辑依赖或数据一致性依赖，当一个模块用这种方式依赖另一个模块，就意味着，前者的执行要依赖后者执行已完成，通常是为了数据准备妥当或保证所需服务已被注册。
显性的运行期依赖把之前启动逻辑的“隐性依赖”完全暴露在阳光之下，改启动逻辑不用提心吊胆。
图14 - 依赖关系树状图
configure()阶段，该阶段是根据之前的依赖树遍历执行。通常用于初始化一些数据配置、注册IService服务、向前面依赖的模块注册一些回调等等。
此外这个阶段还有额外的作用是插入BootTask，用于后面execute()阶段的执行。
图15 - configure阶段
execute()阶段，为了改变启动流程不清楚的情况，强调启动逻辑之间的依赖关系，我们现在将每个要执行的启动步骤封装为BootTask。前面的configure阶段时，我们可以将BootTask插入到通过dependency()得到的依赖树。每个Plugin同时也是一个BootTask，也因此拥有execute()接口。最终得到了包含所有BootTask的启动树，将遍历执行所有节点执行execute()。
图16 - BootTask
独立使用BootTask的方式并不十分常见，通常Plugin本身的execute已经够用。不过在一些通用型组件初始化尝试会需要用到，如某些给某个全局使用的预加载资源提前初始化的逻辑。
为何设计configure()和execute()，这可以理解为“收集任务”和“执行任务”的两个阶段。另外这样的抽象还可以实现从外部调度execute的执行线程，将启动逻辑和启动异步代码分开。顺便解决了，原来异步启动代码混乱不堪的情况。
约束代码边界
从之前的经验看，要想约束好代码的边界不被破坏，编译上的隔离是唯一法宝。
除了工程和工程之间的分割，在工程的内部如果也能实现约束代码就更好了，算是将问题扼杀在摇篮里。之前通常的做法是以module工程为单位的相互分离，但在工程内部并不限制代码相互引用。所以为了规范代码，常能看到用包名作为约定，区分内部功能职责，靠约定维持解耦。随着时间推移，很快就能发现包名约定作为约束太弱了，在快速迭代的代码上很难一直维持下去。不管怎么样解决，总要通过一些手段审查代码引用的对不对。感觉有点防不胜防。为此，我们实现了一种简单易用、粒度更细的工程组织结构——pins工程结构
图17 - pins工程示例图
使用pins工程结构，我们考虑的是要能对接兼容以前结构下那么多伪工程，又能在开始设计某个业务模块时，能用极小粒度的代码解耦，限制错误引用，以防后患。
pins工程能在module之内再次构建完整的多子工程结构，通过project.properties来指定编译依赖关系。通过依赖关系在编译时找到所有的资源和源码路径。而对边界的约束需要配合code-check工具在编译期进行检查，杜绝依赖关系之外的代码引用。
图18 - code-check
这样的工程组织形式的两个明显好处：
粒度极小，一个pin工程也许只有一个源文件，只要它能表达一个独立职责。对于任何一个模块，从内部约束自己的功能结构，是对整体代码边界约束的极大补充。以前面插的结构为例，一个gallery业务可能提供了几种不同的产品功能，以及支撑能力。那么将其相互独立的代码进行区分，避免混杂，就会显得十分必要。清晰的结构，意味着后期维护成本的降低和开发效率的提高，留下了灵活性。
pins工程某种程度上能减少一些粒度太小的module工程，也一定程度的缓解太多module工程时的gradle编译性能问题。
至此，我们基本完成了重塑模块化的设计目标，解决掉很多之前没有考虑的问题。算是模块化的加强版。另外设计是一方面，拆分解耦原来代码以及迁移还是另一回事，这个过程也是十分艰难和枯燥这里就不细讲了。接下来想办法看看重构的效果。
看看效果
重新设计的模块化加上代码的重构。我们终于能满足之前硬件同学的需要。同时一并解决许多拖欠的问题。
在编译上，整体编译速度会因为module增多而下降一些。但拆分module之后，却能显著加快单工程增量编译的速度。和之前相比，一行代码的增量编译耗时能减少60%。
除了满足需求外，架构设计的效果并不好量化，不过我们尝试用一个demo来说明。
WeChat nano
基于前面介绍过的轻量的微信内核mmkernel层，再配合一个不包含界面的基础聊天模块和Auth模块，可以在短时间里开发出一个及精简版本的微信——WeChat nano。
图19 - WeChat nano
模拟这个console的界面是单独开发的，时间的大头都花在这上面。
它的效果不错：
大概就是这样。
取舍和选择
对于架构重构，我们也曾放眼行业内已经发布过的各种方案，希望从中找到一些解决思路。
我们参考了很多业界开放和发表的架构设计。总的来说，目前Android端App整体架设计上，除了聚焦在“大前端”之外，基本上都在“插件化/应用沙盒”上面下功夫。可以参考如atlas、small、DroidPlugin、DynamicApk等等方案，不难发现让模块最终具备动态性是它们最核心的能力。
“大前端”是个热门的方向。我们结合自身情况，考虑到迁移已有代码不是一件容易事，让团队彻底切换编程工具短期不现实。这种“远水解不了近渴”的感觉，也只能暂且作罢。
我们把目光投向了“插件化/应用沙盒”。沙盒的好处是它具备很强的隔离性，有些方案可以彻底隔离代码和资源，边界限制性极强，效果很好。此外，多数方案也都具备动态更新能力、补丁能力，动态性基本成为标配。所以这时我们在考虑需不需要走上这样的路。
一切从自身情况出发。在微信的角度看，我们最关心的问题是如何能约束住代码边界，如何防止架构劣化，如何提高开发效率。这样的情况下，重新审视了具备动态性的插件化和沙盒方案。先从动态性上考虑，回看业内的使用经验，目前的动态性通常有两个主要的用途：1）作为热补丁使用；2）业务并行发布需求强烈，例如运营需求，作为快速发布的手段。对于第二点，就目前的微信团队来说是较少遇到的弱需求。相较之下，工具类和电商类应用常有符合的使用场景。而对于第一点，我们则期望在实现模块化上，目标相对纯粹一些，专心解决代码自身问题，之后再通过tinker在开发阶段之外实现热补丁上的动态性需要。
再来看隔离性。需要说明的是，这里的隔离型主要来自于沙盒架构效果。对于非独立插件化工程（需要编译依赖其他插件）除了动态性，它的作用和普通module在代码隔离上没有区别，不做讨论。
我们心里很期盼代码与代码之间那种干净清爽的分割效果，但事与愿违。
图20 - 模块依赖示意图
从上面这张模块依赖示意图看到，微信业务模块之间数据关系相当复杂，模块间相互访问数据、共享某些功能的行为如此普遍。而实际情况比示意图更麻烦。
面对微信业务数据相互间频繁的调用，沙盒隔离容易导致代码复用困难和相互调用麻烦，想在微信上实现，目前困难极大。重构难度不谈，单是隔离的收益就很有可能无法弥补开发效率上的损失。
从开发模式上看也是一样。微信Android团队目前每个迭代大概三四十人参与，内部沟通成本不算高到不可接受。通常开发同学可能要同时开发和修改几个模块并保证他们相互模块独立，同时又可能有频繁的模块间通信。这种时候，模块调用方不方便显得很重要。
此外还需要考虑的问题，从几个成熟方案中都能看到hook Android框架、修改aapt、替换或包装android gradle plugin、代理组件等等设计。这些方案的复杂度和兼容性代价，不能忽视。使用和维护它们需要仔细权衡。
所以思前想后我们仍选择了重走最开始的模块化之路。一切问题的根本还是在那个说的很多年的代码边界、解耦和内聚上。只要有了清晰独立的代码模块，才有将来其他变化的可能性。
代码之外，架构之内
模块负责人制度
有这样一句话，“不被监管的权利一定会发生腐败” 。如果放到软件开发的行当来说，就是“不被监管的代码也一定会发生劣化”。所以代码应该要接受“监管”。
为了能长期有效的保持代码质量，我们开始执行新的代码审查机制——模块负责人制度。
代码审查的好处毋庸置疑。在这之前，微信由于业务发展快速，同学们经常会变换需求的开发方向。面对着业务模块数量比人多的情况，开发同学经常一个人需要开发多个模块。也因此许多模块被无数人维护过，基础的支撑工程更是如此。这种类似游击战的方式，开发效率很高，支撑了微信快速的研发节奏，但也导致了“无主代码”特别多。大家缺少对代码的“归属感”，也降低了改进优化模块的欲望。
另外在这之前，代码审查是由leader对申请回流主干的Merge Request进行review，这导致效率较低且容易遗漏问题。合理的代码审查更应该是全员性质的。
模块负责人制度尝试改变这些现状。通过大家认领模块，对模块的代码和设计负责，对模块对外提供的接口服务负责，对其他人修改自己模块的行为进行监督。这些情况明显提高开发同学的代码所有感，改变大家修改优化和修改代码的动机。
推动模块负责人制度，渐进式的推动了大范围的代码审查，这样的方式很适合像微信这样没有从一开始执行全员性质Code Review的项目。目前模块负责人机制运转顺利，代码审查率和模块认领率都在提高。
重构与开发者心态的关系
在一个长期没有改进的框架下，开发者的习惯可能会逐步变成跟随式、保守式的开发。这大概可以被描述成“只要别人这样做，我也这样做，哪怕这么样的设计不好，但也不会错”。随着心态逐渐普遍，另一种情形出现：经常能听到有同学吐槽一些代码，却更少看到代码在被改进。这说明一些沉积的问题不是没有被大家发现，只是没有人愿意去修改。这种情况下代码和框架会随着时间变得越来越差，有些问题逐渐变成“陈年旧病”。 面对这个问题首先要说，这不是开发者合格与否的问题，实际上有想法的开发人员有很多，但想将每个想法转换成代码并让大家接受，并不是一件很容易的事。尤其在一个大框架下，尝试改变的代价很大。如果他的主要任务不在改进某些模块上，那么很多想法最后都无法变成现实。这也是为什么保守和跟随的习惯会逐渐变的普遍。
保守的气氛需要被打破。当开启一次重构之后，你会发现团队中会有很多积极的声音响应，他们会把积压的想法和意见抛出来。一次问题的解决，可能会为另一个问题的解决带来机会，其他开发同学的一些想法也许就能更容易落地。所以不定期的推动一些模块的重构，将一些对代码的不满释放出来，是一种不错的激活。
此外在重构之后，还要考虑引导开发的代码组织方式切换，多用模板、正确的代码实例等，让他们可以放心参考。
模块划分经验谈
维持代码边界
代码的边界就像一堵墙，架构的劣化都是从这堵墙的瓦解开始的。从以往的经验来看，编译上的隔离是最好的约束手段，单纯的约定或准则并不能永远的保持下去。 所以在任何情况下都尽可能不要放开编译上的约束。接着，将接口和实现分离，其他工程只依赖接口而不依赖实现，这样的边界效果更好。当然破坏无处不在，例如遇到某个紧急需求要某模块新增若干接口，就可能出现跳过接口直接依赖实现工程进行开发的情况。这时可以考虑通过代码的审查进行监督，也可以通过开发简单的编译脚本，检查是否有不当依赖产生。
划定模块边界的细节问题
当对代码进行解耦时，即便大体上的模块职责划分已经清晰，但因为模块间的各种业务关系，细节上仍会遇到纠缠不清的情况。事实上，因为需求及功能的不同，并没有哪一种模块划分的规则是完全适用于每个应用的。随着业务的发展和变化，模块边界出现不合适的情况完全符合预期。
那么如何让模块划分更让大家觉得合理，或者说当遇到一个两难选择时，按照什么样的方式大家会更好理解？我们建议的方法其实也很简单：试着对代码“讲一个符合逻辑的故事”，哪个故事讲得通，你就可以将之作为拆分的选择。因为代码解耦从来不是问题，纠结的只是解耦行为能不能让人理解。例如一些模块间通信用的数据结构究竟属于那个模块的问题就可以用这种方式仲裁。在纠结的时候，能自圆其说的方案往往就足够了。我们要尽力避免的，应该是随意拼凑和单纯为了类型解耦而解耦的情况。
模块的一般组织方式
设计一个模块，我们有一个一般性的组织方式，可以将模块分成三个工程：implementation工程、api工程、library工程。
implementation工程提供逻辑的实现。api工程提供对外的接口和数据结构。library工程，则提供该模块的一些工具类。
从另一个角度看，implementation工程实际上是和应用的状态、生命周期相关的，它的执行依赖于各种应用状态。而library工程则不关心这些状态。因此也可以看做library提供某种功能，implementation则是如何运用这种功能。例如，我们实现一个表情模块，library工程提供表情的资源、表情的渲染和播放能力，api工程提供了使用表情的服务接口，implementation工程则提供了api的实现，及何时开始加载表情资源、缓存管理、以及其他表情功能例如商店等等。
当然，这是一个指导性的建议，很多时候library工程和api工程之间没有明显边界也很正常。但强烈建议至少要有implementation工程和api工程。
分析依赖关系的工具
解耦代码时，快速分析代码的依赖关系能很好的提升工作效率。Android Studio提供了一个不错的工具。
图21 - Analyze dependency工具
文件、资源以及工程，都可以进行依赖分析。有了分析结果，接下来一步一步把代码分离就简单多了。
最后
重构整体架构不是一件容易事，通常也不太可能让整个团队停下来只做重构。所以一直以来微信的重构都是随着版本迭代进行“拆分”-> “灰度” -> “回流”的循环节奏。
“设计系统的组织，其产生的设计和架构等价于组织间的沟通结构”。对于微信几年间走过的路程，时至今日团队内的沟通形式还可以做到较多的直接沟通。这些情况决定了微信如今的技术选择。所以在方案选择上我们就更愿意寻求相对简单合适的方式解决问题——用纯粹的模块化保持后续架构的灵活性和健壮性，重新强调依赖、强调应用状态和生命周期、强化代码的边界。
除了代码上的设计，代码之外我们也做了些努力。我们认同代码审查的意义，也开始推行模块负责人的审查机制。此外我们还打算强化文档的使用，当然这个还在规划中。
最后希望我们分享的一点经验能对大家有些价值，欢迎留言交流 :)
