拓荒微信1.0 for Android的测试版本于2011年1月发布。这是微信Android客户端的第一个版本，软件架构采用早期标准的Android系统应用设计。
【图1】
第一个版本是两个人用了一个多月的时间开发出来的，其中一个还是刚刚毕业没多久的实习生。这个时期团队一穷二白，资源有限、经验不够，主导思想是，复杂的事情尽量交出去做，保持最精简的客户端代码。得益于Android应用开发简单快速，从结构上看，这个时候其实还没有到需要特别设计的阶段，是最原始、简单的Android应用。
当然，再简单的软件也要考虑基本的设计思路。分层设计思想从这最早的版本开始引入一直到今天。回顾当时的设计，更像是MVP结合事件通知机制。从最上面由Activity组件组成的UI层（VIEW），往下到由NetScene组成的表现层（Presenter），再往下Network负责网络长短连接与数据库的通信与Storage组成的存储层。NetScene是一个网络或者本地任务的基本单元，包括操作网络做数据收发、协议编解码，操作数据库做各种联系人、消息模块的读写。典型的例子如发送一条消息NetSceneSendMsg、做一次收信同步操作NetSceneSync。1.0版本的微信整个UI的activity可能不超过五个。
这个阶段，不需要做什么“减法”，我们的安装包也只有354k。
成长微信的快速增长，从2.0版本开始第一次爆发。从语音版，到附近的人、漂流瓶，再到摇一摇。这个阶段的我们，似乎将全部的时间和精力都放在新功能拓展上。新的Activity、新的NetScene加上新的Storage，在看似成熟的框架里，一个功能就这样完成了。简单、快速、暴力。随之而来的，是一些之前完全没有想到会可能出现的问题，让最开始接触Android开发的我们措手不及。
早期版本因为经验的问题，产品上很多功能不去想也不敢去想，版本开发的时间跨度也比较长。随着开发经验的积累和对产品方向的理解，3.0之后的每一个小版本都处在一到两周的高速迭代过程中。
追求更好的用户体验，更多丰富的功能是产品经理们永远不会放弃的事情，尤其是在新功能为微信的新增用户带来了一次次爆发式的增长之后，更是无法控制。功能的试错频率大大加速，机型覆盖量上升后的兼容性问题也逐渐暴露。代码量、内存占用、安装包体积迅速膨胀。而同样处于发展中的Android系统，也给我们埋下了很多坑，需要开发自己来实现、修复和优化。放在今天webview组件不再是什么问题，但在2.3之前的系统里面都会存在严重的内存泄露。内存问题为微信客户端架构的第一次进化埋下了伏笔。
变革在微信1.0时代的时候，我们的关注点更偏向功能，随着用户增长，性能和稳定性问题逐渐浮上水面。2.0版本后，用户反馈中微信消息推送不及时的比例在上升，作为一款目标替代短信的即时通讯应用，无法及时收取别人发来的消息，这一点是非常致命的。
Android 1.5、1.6、2.1在当时是主要的版本，那个时候是没有今天的GCM的，甚至连C2DM也是2.2系统之后才会有的。而谷歌服务在国内被屏蔽，在相当长一段时间内，无论是C2DM还是GCM都无法正常进行推送。没有像APNS一样稳定的推送通道可供Android平台的应用使用，怎么办？自己实现。
国内网络的特殊性，使得我们再实现微信推送机制时，需要维持准确的心跳周期。如果一段时间没有活动，运营商便会将长连接断开以回收资源，这时服务器发消息给客户端就接收不到了。进一步研究发现，运营商网络的时间限制各个地区不同，有的地区有两分钟，有的地区有半个小时，这种情况是不可接受的。我们的解决方案是缩短心跳间隔，在网络运营商把客户端到接入点之间的连接断开之前，我再发送一次心跳，主动维持住这个长连接的活性。这个我们称之为长连接的保活。关于长连接的保活策略，微信也做过多次优化，这里另文介绍，不再赘述。
还记得前面说微信的膨胀吗？代码、内存、apk大小都在膨胀，这其中，内存对消息收发的影响很关键。Android运行时的择优置换机制，会选取占用资源最多的程序结束掉，除了微信自己功能膨胀导致内存占用加大之外，前面说的不省心的webview，还会给我们在内存问题上挖坑。而结果就是在用户手机运行APP比较多的时候，微信会被系统杀掉回收资源，消息收取不及时的问题就出来了。
如何解决？方法其实不少，微信选择的，是轻重分离的思路。通过在微信3.5版本时候做的架构重构，实现了不受功能增长、系统缺陷影响的稳定推送方案。
【图2】
对比v1.x版本的微信客户端架构图，我们将右下角Network的部分用轻重进程分离的思想，独立到一个单独的进程（:push）中，而上面两个层级依然跑在微信的主进程（:worker）中。而对于有内存泄露问题的webview或者其他不频繁使用的功能，再把其分离到独立的工具进程（:tools）中。通过分离进程，微信第一次重构解决了系统因为微信资源消耗，主动干掉微信服务的困境。分离后的push进程内存占用以及被系统kill回收的几率大幅降低，而对于worker和tools进程，我们不再要求其一定存在，只在用户收到消息，或者进入h5相关功能界面时存在即可。这个版本的架构变更基本达成了我们设定的目标，无论是电量还是平均待机内存消耗上都大幅度下降，从内存上来看下降了70%，电量的话也比竞品和我们前一个版本有好转。
当然任何事物都有两面性。这一次架构的改变存在的问题逐渐在我们后面的开发当中暴露出来。比如进程每一次都要重新加载，里面所有的Cache、图片、界面全部要重新去执行一遍同样的代码，每一次加载内存都需要重新消耗时间。而启动速度变慢，则是最明显，用户最能感知的问题。“地球出现频率高了”是我们在这一时期经常听到的声音。而系统资源的消耗实际上比原来单进程的时候会更多，每一个进程都需要额外多占用一份虚拟机部分的内存。
这些缺点在3.5版本时代是可以接受的。从监测结果上看，启动速度变慢将微信的启动速度延长到了秒级，从原来的300-500毫秒到现在800-1000毫秒的级别。主要的图片缓存失效，则通过异步加载、解码、展示解决。拉长来看，微信的主进程资源会被自动回收，平均内存占用相比之前还是下降的。即便在今天来回顾，依然可以看到，轻重进程拆分的思路是正确的选择。即便系统层面各种各样的bug逐渐减少，但应用的迭代使得功能一定不会减少。为了保证图片、资源类在速度上的体验，内存的消耗也只会更大，是空间换时间的思路。而轻重分离，保证了核心服务在设备资源发生竞争时最大概率存活的同时，不造成对设备过多的资源占用。典型的场景就是用户开启游戏、视频录制通话等大型应用，作为常驻应用，不应该抢占额外的有限资源，需要做到“该放手的时候就放手”。
进化很快，微信的架构演进进入了第三个阶段（v3.x）。微信4.5版本的开发过程中，出现了无法安装在一部分Android 2.3以下系统的机器上，当时2.3的市占率还在50%以上。试想一下，市场上一半用户的手机不能安装使用微信，这对我们是一个致命打击。放在今天看，2.3早已被淘汰，但在当时，我们不可能停下来等待，无论从开发和产品来说都是不可接受的。技术分析的直接原因就是，微信的发展速度太快，触发到Android虚拟机机制的设计缺陷。
两个问题，一是单dex 65535方法数限制，二是线性内存分配器（LinearAlloc）限制。今天的Android开发者看到这两个限制都不会陌生。前者是因为Android的早期设计中，对dex文件中方法id用16位整型标记，单个dex文件中的方法数无法超过65535，eclipse环境中生成不了未做过proguard的debug apk。后者则是dalvik虚拟机用来加载类的堆内存大小被硬编码了，2.3以下是5M，2.3以上是8M，微信无法安装的原因就是因为这个堆内存被耗尽导致dexopt失败。
今天来看，Google已经给出了一些可靠的解决方案，辅以更加先进的gradle + Android Studio，开发者们可能根本不会再遇到这两个经典问题，。官方的MultiDex分dex机制解决了方法数限制的问题，其中main dex最小化原则，结合dalvik LinearAlloc heap size调整（修改到了16M），使得dexopt的失败几率大幅下降。而art的出现彻底不再存在LinearAlloc这样的限制。回过来再看，那个时代里微信是如何通过软件架构调整解决这些问题的。
微信在高速发展过程当中，到5.0的时候已经有很多功能，而其中一些功能，随着用户群体、产品设计等因素变化，用户使用的频率在改变。之前试错的一些功能，也大量存留在微信版本中。这些不常使用的功能不应该始终占用程序资源，从架构上进行纵向分离，保证主要场景的体验，是这一时期的主要设计思路。
【图3】
要做的第一步就是解耦。微信这类社交型应用，在用户数据、关系、消息等结构上存在着各种各样复杂的依赖，这些依赖相比工具型的软件来说，调用频率更高，性能要求也更高。想做到完美的拆分不是一件容易的事，但是不完美的拆分却是可以达成的。轻重分离的思想再一次被应用，这一次是在代码模块的使用和组织上。保证主app功能的快速和稳定，将附属的新功能分离在独立的插件工程（p_XX）中，每个插件有独立的UI界面逻辑和资源、存储及网络协议编解码处理逻辑，通过共用统一的基础库接口访问网络服务。
将微信功能解耦为插件，一个插件内仅向下依赖。插件最后编译出来会是一个jar包，其内包括的实际内容是对应的dex。这里需要注意的是，插件并不需要有独立的进程空间，而是根据该插件实际的场景决定其运行的实际进程，绝大多数情况下，插件是和主app功能共享多进程载