微信团队原创分享：Android版微信从300KB到30MB的技术演进

本次即时通讯网(52im.net)分享的是微信从2011年第1个版本发布至今的客户端技术演进过程，对于Android开发者来说，伴随着Android系统的不断更新，APP的升级总是在“被坑”与“填坑”的过程中不断成长，我们一起来看看微信是如何成功进化的。

前言

总结起来，一个典型的Android应用从小到大的成长过程就是一部“踩坑”与“填坑”的历史。互联网的变化速度如此之快，1年的时间里，可以发生翻天覆地的变化。今天在这里，重新和大家回顾微信客户端架构的演进过程，以及其背后的开发团队、流程的变化与思考。

Android版微信客户端从1.0版本安装包的354KB，到今天6.3 版本的34MB，从最开始两三个码农的突击作业，到今天的“集团军”开发力量， 微信的体量在不断增大，开发同学遇到的“成长的烦恼”也越来越多:

*  为什么微信收消息又延迟了?为什么我得每次打开微信才收到消息?
*  为什么我的微信无法安装了?为什么微信启动越来越慢了?
*  为什么我的eclipse突然无法debug微信了!?如何把编译速度提升80%?
*  如何在一个月左右的周期内排入5个迭代?如何并行发布3个以上代码线的客户端版本? * 如何减小因为增加开发人力而带来的资源损耗?

ANDROID系统先天的弊端与产品需求研发过程的矛盾，推动着客户端架构演进史。这架车轮不断向前滚动，不断调整进化的架构，在为微信未来的高速成长保驾护航。我们一起来了解微信ANDROID客户端的架构演进过程。

相关资源

同类文章：
- 《移动端IM实践：Android版微信如何大幅提升交互性能（一）》
- 《Android版微信安装包“减肥”实战记录》
- 《微信团队原创资源混淆工具：让你的APK立减1M》
- 《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
心跳机制：
- 《移动端IM实践：实现Android版微信的智能心跳机制》
讲稿下载：
- 《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》

阶段1：拓荒

微信1.0 for Android的测试版本于2011年1月发布。这是微信Android客户端的第一个版本，软件架构采用早期标准的Android系统应用设计。



第一个版本是两个人用了一个多月的时间开发出来的，其中一个还是刚刚毕业没多久的实习生。这个时期团队一穷二白，资源有限、经验不够，主导思想是，复杂的事情尽量交出去做，保持最精简的客户端代码。得益于Android应用开发简单快速，从结构上看，这个时候其实还没有到需要特别设计的阶段，是最原始、简单的Android应用。

当然，再简单的软件也要考虑基本的设计思路。分层设计思想从这最早的版本开始引入一直到今天。回顾当时的设计，更像是MVP结合事件通知机制。从最上面由Activity组件组成的UI层（VIEW），往下到由NetScene组成的表现层（Presenter），再往下Network负责网络长短连接与数据库的通信与Storage组成的存储层。NetScene是一个网络或者本地任务的基本单元，包括操作网络做数据收发、协议编解码，操作数据库做各种联系人、消息模块的读写。典型的例子如发送一条消息NetSceneSendMsg、做一次收信同步操作NetSceneSync。1.0版本的微信整个UI的activity可能不超过五个。

这个阶段，不需要做什么“减法”，我们的安装包也只有354k。

阶段2：成长

微信的快速增长，从2.0版本开始第一次爆发。从语音版，到附近的人、漂流瓶，再到摇一摇。这个阶段的我们，似乎将全部的时间和精力都放在新功能拓展上。新的Activity、新的NetScene加上新的Storage，在看似成熟的框架里，一个功能就这样完成了。简单、快速、暴力。随之而来的，是一些之前完全没有想到会可能出现的问题，让最开始接触Android开发的我们措手不及。

早期版本因为经验的问题，产品上很多功能不去想也不敢去想，版本开发的时间跨度也比较长。随着开发经验的积累和对产品方向的理解，3.0之后的每一个小版本都处在一到两周的高速迭代过程中。

追求更好的用户体验，更多丰富的功能是产品经理们永远不会放弃的事情，尤其是在新功能为微信的新增用户带来了一次次爆发式的增长之后，更是无法控制。功能的试错频率大大加速，机型覆盖量上升后的兼容性问题也逐渐暴露。代码量、内存占用、安装包体积迅速膨胀。而同样处于发展中的Android系统，也给我们埋下了很多坑，需要开发自己来实现、修复和优化。放在今天webview组件不再是什么问题，但在2.3之前的系统里面都会存在严重的内存泄露。内存问题为微信客户端架构的第一次进化埋下了伏笔。

阶段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版本时候做的架构重构，实现了不受功能增长、系统缺陷影响的稳定推送方案。



对比v1.x版本的微信客户端架构图，我们将右下角Network的部分用轻重进程分离的思想，独立到一个单独的进程（:push）中，而上面两个层级依然跑在微信的主进程（:worker）中。而对于有内存泄露问题的webview或者其他不频繁使用的功能，再把其分离到独立的工具进程（:tools）中。通过分离进程，微信第一次重构解决了系统因为微信资源消耗，主动干掉微信服务的困境。分离后的push进程内存占用以及被系统kill回收的几率大幅降低，而对于worker和tools进程，我们不再要求其一定存在，只在用户收到消息，或者进入h5相关功能界面时存在即可。这个版本的架构变更基本达成了我们设定的目标，无论是电量还是平均待机内存消耗上都大幅度下降，从内存上来看下降了70%，电量的话也比竞品和我们前一个版本有好转。

当然任何事物都有两面性。这一次架构的改变存在的问题逐渐在我们后面的开发当中暴露出来。比如进程每一次都要重新加载，里面所有的Cache、图片、界面全部要重新去执行一遍同样的代码，每一次加载内存都需要重新消耗时间。而启动速度变慢，则是最明显，用户最能感知的问题。“地球出现频率高了”是我们在这一时期经常听到的声音。而系统资源的消耗实际上比原来单进程的时候会更多，每一个进程都需要额外多占用一份虚拟机部分的内存。

这些缺点在3.5版本时代是可以接受的。从监测结果上看，启动速度变慢将微信的启动速度延长到了秒级，从原来的300-500毫秒到现在800-1000毫秒的级别。主要的图片缓存失效，则通过异步加载、解码、展示解决。拉长来看，微信的主进程资源会被自动回收，平均内存占用相比之前还是下降的。即便在今天来回顾，依然可以看到，轻重进程拆分的思路是正确的选择。即便系统层面各种各样的bug逐渐减少，但应用的迭代使得功能一定不会减少。为了保证图片、资源类在速度上的体验，内存的消耗也只会更大，是空间换时间的思路。而轻重分离，保证了核心服务在设备资源发生竞争时最大概率存活的同时，不造成对设备过多的资源占用。典型的场景就是用户开启游戏、视频录制通话等大型应用，作为常驻应用，不应该抢占额外的有限资源，需要做到“该放手的时候就放手”。

阶段4：进化

很快，微信的架构演进进入了第三个阶段（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的时候已经有很多功能，而其中一些功能，随着用户群体、产品设计等因素变化，用户使用的频率在改变。之前试错的一些功能，也大量存留在微信版本中。这些不常使用的功能不应该始终占用程序资源，从架构上进行纵向分离，保证主要场景的体验，是这一时期的主要设计思路。



要做的第一步就是解耦。微信这类社交型应用，在用户数据、关系、消息等结构上存在着各种各样复杂的依赖，这些依赖相比工具型的软件来说，调用频率更高，性能要求也更高。想做到完美的拆分不是一件容易的事，但是不完美的拆分却是可以达成的。轻重分离的思想再一次被应用，这一次是在代码模块的使用和组织上。保证主app功能的快速和稳定，将附属的新功能分离在独立的插件工程（p_XX）中，每个插件有独立的UI界面逻辑和资源、存储及网络协议编解码处理逻辑，通过共用统一的基础库接口访问网络服务。

将微信功能解耦为插件，一个插件内仅向下依赖。插件最后编译出来会是一个jar包，其内包括的实际内容是对应的dex。这里需要注意的是，插件并不需要有独立的进程空间，而是根据该插件实际的场景决定其运行的实际进程，绝大多数情况下，插件是和主app功能共享多进程载体的。

v3.x架构的改造工作量对当时的我们来说很大，从最开始4.3版本发现dex limit和LinearAlloc limit到5.0版本成型做第一次的验证，我们花了8个月时间，解耦出来的工程项目有60个以上。4.5版本将附近的人分离出去是作为一次试验，为5.0这一大版本填完了坑。5.0版本是微信历史上非常重要的一环，从这个版本开始引入了游戏、支付和更加完善的公众账号体系。

这种设计思路不是微信首创，现在回顾也并不复杂。如果你的产品历史功能不多，迭代不是很快，可以全部人停下来1到2个月集中一次重构搞定。但对于微信来说，但这一版的架构变更，更像是在给天上飞着的飞机换发动机，由一支10来个人组成的团队完成。互联网的快速、敏捷给处在“创业”阶段的我们新的挑战。如何做到呢？要保证不给处于高度需求压力下的开发人员增加架构变动的额外负担，首先要做的就是不要让他们重复修改代码，无缝迁移到新的架构。

一、创建必要的工具和规范。微信在4.3发现问题之前，一直坚持着非常好的开发效率优化思想，代码自动生成起到了很大的帮助。团队内部使用的自研的代码生成工具autogen，通过简单的xml定义，即可生成所需要的存储、协议编解码、事件机制代码。这使得我们具备了比较轻松解耦的前提。

二、新的架构要求开发者在做新功能时，使用独立插件子工程，好的工程模板可以事半功倍。早期传承下来的分层设计，也使得开发人员在前后两种开发模式下的学习成本降到最低。对应的编译和开发调试工具。

三、对于历史实现的功能特性，尽量通过反射等一些技巧，来保证不需要大规模重写代码，“先抗住，再优化”。不要一开始就追求完美，先活下来。直到5.1、5.2版本，我们才基本上全部完成这一次程序架构调整。

四、人。架构调整是必须要做的事，但是作为发起者，也不能只从理论角度去强硬推动。减少开发者的工作量，而不是增加，站在开发者的角度想问题，往往会得到非常积极的响应。

不同的客户端架构时期，背后的团队和开发模式也会有所不同。对比三个版本的客户端架构，v1.x和v2.x的时候比较适合小型团队、没有特别复杂或者反复需求的客户端进行快速开发。单trunk主线开发即可满足。每次发布后，拉出来一个对应的release branch，如果发现有bug或者小优化需要修改，直接在这个release branch上修改、测试、发布上线。这一时期release branch通常保持在两个以内，当前版本和前一版本。当前版本是为了线上问题的快速发布，而前版本则是为了修复一些厂商渠道预装的问题。





v3.x就比较适合中到大型团队，解耦之后，可以支持多个团队的并行开发，也可以满足多个版本的同时开发和发布。微信的产品经理和客户端开发人员的比例大概是1.5+，也就是说产品经理会比开发人员多50%以上。开发人员会面对产品各式各样的需求需要实现，很多需求处于原型或者是设计阶段，而有些即便开发完成，也需要和老大体验修改。这种不稳定状态的需求，往往是今天说最终确定，但2个小时后就可能要修改，甚至临上线前都可能说这个功能被砍掉，不要发布了。不稳定的需求会带来不稳定的代码实现，质量也没法控制。通过多迭代多版本多分支并行开发，只有所有人体验过最终确认没问题可以上线，才会合入发布版本上线。

这个过程像什么？像开源项目的开发。

阶段5：开放

进入到2015年后，微信在软件架构上逐渐趋于平稳。在v3.x原有插件加载基础上，研究了更多行业内Android应用的技术架构。结合官方MultiDex的实现，增加动态热补丁功能，通过终端的运营系统，实现了微信客户端补丁版本更新48小时90%+覆盖率。编译系统也从buck+修改为微信自研的builder构建，支持LinearAlloc和methods/fields count的实时计算，以及融合了MultiDex与微信插件模式的dex自动分包。在v2.x架构轻重分离的多进程思路基础上，进一步优化实现了push的在收信条件下的“lightpush”运行模式。在仅消耗push进程低内存的条件下，实时收取新消息通知，避免对进行中的游戏进行资源抢占的同时，又可以及时收取消息。

未来

更重要的是，我们开始将目光转移到开源的开发模式上。v3.x的并行开发模式，在svn下已不再适应。2015年上半年开始微信Android客户端团队开始转向git，充分发挥git在多团队并行开发下的优势。内部也放弃了沿用许久的ant + eclipse，全面转向gradle + Android Studio的分布式构建思想。通过内部开源，微信内的公共组件已经可以通过maven在不同的开发团队中共享并随时使用。或许某一天，我们也可以在github上看到”WeChat Mobile Dev”的身影。

全站即时通讯技术资料分类

[1] 网络编程基础资料：
《TCP/IP详解 - 第11章·UDP：用户数据报协议》
《TCP/IP详解 - 第17章·TCP：传输控制协议》
《TCP/IP详解 - 第18章·TCP连接的建立与终止》
《TCP/IP详解 - 第21章·TCP的超时与重传》
《理论经典：TCP协议的3次握手与4次挥手过程详解》
《理论联系实际：Wireshark抓包分析TCP 3次握手、4次挥手过程》
《计算机网络通讯协议关系图（中文珍藏版）》
《NAT详解：基本原理、穿越技术(P2P打洞)、端口老化等》
《UDP中一个包的大小最大能多大？》
《Java新一代网络编程模型AIO原理及Linux系统AIO介绍》
《NIO框架入门(三)：iOS与MINA2、Netty4的跨平台UDP双向通信实战》
《NIO框架入门(四)：Android与MINA2、Netty4的跨平台UDP双向通信实战》
>> 更多同类文章 ……

[2] 有关IM/推送的通信格式、协议的选择：
《为什么QQ用的是UDP协议而不是TCP协议？》
《移动端即时通讯协议选择：UDP还是TCP？》
《如何选择即时通讯应用的数据传输格式》
《强列建议将Protobuf作为你的即时通讯应用数据传输格式》
《移动端IM开发需要面对的技术问题（含通信协议选择）》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《理论联系实际：一套典型的IM通信协议设计详解》
《58到家实时消息系统的协议设计等技术实践分享》
>> 更多同类文章 ……

[3] 有关IM/推送的心跳保活处理：
《Android进程保活详解：一篇文章解决你的所有疑问》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《为何基于TCP协议的移动端IM仍然需要心跳保活机制？》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
>> 更多同类文章 ……

[4] 有关WEB端即时通讯开发：
《新手入门贴：史上最全Web端即时通讯技术原理详解》
《Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》
《SSE技术详解：一种全新的HTML5服务器推送事件技术》
《Comet技术详解：基于HTTP长连接的Web端实时通信技术》
《WebSocket详解（一）：初步认识WebSocket技术》
《socket.io实现消息推送的一点实践及思路》
>> 更多同类文章 ……

[5] 有关IM架构设计：
《浅谈IM系统的架构设计》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《一套原创分布式即时通讯(IM)系统理论架构方案》
《从零到卓越：京东客服即时通讯系统的技术架构演进历程》
《蘑菇街即时通讯/IM服务器开发之架构选择》
《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《17年的实践：腾讯海量产品的技术方法论》
>> 更多同类文章 ……

[6] 有关IM安全的文章：
《即时通讯安全篇（一）：正确地理解和使用Android端加密算法》
《即时通讯安全篇（二）：探讨组合加密算法在IM中的应用》
《即时通讯安全篇（三）：常用加解密算法与通讯安全讲解》
《即时通讯安全篇（四）：实例分析Android中密钥硬编码的风险》
《传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》
《理论联系实际：一套典型的IM通信协议设计详解（含安全层设计）》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享》
>> 更多同类文章 ……

[7] 有关实时音视频开发：
《即时通讯音视频开发（一）：视频编解码之理论概述》
《即时通讯音视频开发（二）：视频编解码之数字视频介绍》
《即时通讯音视频开发（三）：视频编解码之编码基础》
《即时通讯音视频开发（四）：视频编解码之预测技术介绍》
《即时通讯音视频开发（五）：认识主流视频编码技术H.264》
《即时通讯音视频开发（六）：如何开始音频编解码技术的学习》
《即时通讯音视频开发（七）：音频基础及编码原理入门》
《即时通讯音视频开发（八）：常见的实时语音通讯编码标准》
《即时通讯音视频开发（九）：实时语音通讯的回音及回音消除概述》
《即时通讯音视频开发（十）：实时语音通讯的回音消除技术详解》
《即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解》
《即时通讯音视频开发（十二）：多人实时音视频聊天架构探讨》
《即时通讯音视频开发（十三）：实时视频编码H.264的特点与优势》
《即时通讯音视频开发（十四）：实时音视频数据传输协议介绍》
《即时通讯音视频开发（十五）：聊聊P2P与实时音视频的应用情况》
《即时通讯音视频开发（十六）：移动端实时音视频开发的几个建议》
《即时通讯音视频开发（十七）：视频编码H.264、V8的前世今生》
《简述开源实时音视频技术WebRTC的优缺点》
《良心分享：WebRTC 零基础开发者教程（中文）》
>> 更多同类文章 ……

[8] IM开发综合文章：
《移动端IM开发需要面对的技术问题》
《开发IM是自己设计协议用字节流好还是字符流好？》
《请问有人知道语音留言聊天的主流实现方式吗？》
《IM系统中如何保证消息的可靠投递（即QoS机制）》
《谈谈移动端 IM 开发中登录请求的优化》
《完全自已开发的IM该如何设计“失败重试”机制？》
《微信对网络影响的技术试验及分析（论文全文）》
《即时通讯系统的原理、技术和应用（技术论文）》
《开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀》
>> 更多同类文章 ……

[9] 开源移动端IM技术框架资料：
《开源移动端IM技术框架MobileIMSDK：快速入门》
《开源移动端IM技术框架MobileIMSDK：常见问题解答》
《开源移动端IM技术框架MobileIMSDK：压力测试报告》
《开源移动端IM技术框架MobileIMSDK：Android版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：Java版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：iOS版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：Android客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：Java客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：iOS客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：Server端开发指南》
>> 更多同类文章 ……

[10] 有关推送技术的文章：
《iOS的推送服务APNs详解：设计思路、技术原理及缺陷等》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《扫盲贴：认识MQTT通信协议》
《一个基于MQTT通信协议的完整Android推送Demo》
《求教android消息推送：GCM、XMPP、MQTT三种方案的优劣》
《移动端实时消息推送技术浅析》
《扫盲贴：浅谈iOS和Android后台实时消息推送的原理和区别》
《绝对干货：基于Netty实现海量接入的推送服务技术要点》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《为何微信、QQ这样的IM工具不使用GCM服务推送消息？》
>> 更多同类文章 ……

[11] 更多即时通讯技术好文分类：
http://www.52im.net/forum.php?mod=collection&op=all

附录：有关QQ、微信的文章汇总

[1] 有关QQ、微信的技术文章：
《微信后台团队：微信后台异步消息队列的优化升级实践分享》
《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《微信Mars：微信内部正在使用的网络层封装库，即将开源》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《开源libco库：单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案》
《微信朋友圈海量技术之道PPT [附件下载]》
《微信对网络影响的技术试验及分析（论文全文）》
《一份微信后台技术架构的总结性笔记》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《快速裂变：见证微信强大后台架构从0到1的演进历程（二）》
《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
《全面总结iOS版微信升级iOS9遇到的各种“坑”》
《微信团队原创资源混淆工具：让你的APK立减1M》
《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
《Android版微信安装包“减肥”实战记录》
《iOS版微信安装包“减肥”实战记录》
《移动端IM实践：iOS版微信界面卡顿监测方案》
《微信“红包照片”背后的技术难题》
《移动端IM实践：iOS版微信小视频功能技术方案实录》
《移动端IM实践：Android版微信如何大幅提升交互性能（一）》
《移动端IM实践：Android版微信如何大幅提升交互性能（二）》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《移动端IM实践：iOS版微信的多设备字体适配方案探讨》
>> 更多同类文章 ……

[2] 有关QQ、微信的技术故事：
《技术往事：创业初期的腾讯——16年前的冬天，谁动了马化腾的代码》
《技术往事：史上最全QQ图标变迁过程，追寻IM巨人的演进历史》
《开发往事：深度讲述2010到2015，微信一路风雨的背后》
《开发往事：微信千年不变的那张闪屏图片的由来》
《开发往事：记录微信3.0版背后的故事（距微信1.0发布9个月时）》
《一个微信实习生自述：我眼中的微信开发团队》
>> 更多同类文章 ……

（原文链接：http://www.infoq.com/cn/articles/wechat-android-app-architecture）