微信Android客户端架构演进之路-简单总结
刚看了微信架构的演进之路的文章，文章链接如下：
http://www.infoq.com/cn/articles/wechat-android-app-architecture
现在做下简单的总结，方便日后自己可查看。
开发初期的架构：
采用MVP+消息通知机制，复杂的事情尽量交出去做，保持最精简的客户端代码。结构清晰，开发起来，快速，简单，暴力。但后期需求暴增，内代码量、内存占用、安装包体积迅速膨胀，问题很多。
另外，消息推送问题：在长连接的问题上，缩短心跳机制，保持住长连接。优化问题另外谈。
改进。重要思想：轻重分离！
进程上的轻重分离
在内存占用过多的问题上，采用轻重进程拆分的思路：维持主进程，将辅助的非常用的功能迁移到生命周期短暂的进程（如推送进程，工具进程）。进程的分离解决了系统因为微信资源消耗，主动干掉微信服务的困境。问题是：进程每一次都要重新加载，里面所有的Cache、图片、界面全部要重新去执行一遍同样的代码。但权衡下来，还是利大于弊。
此外，还有两个问题：一是单dex 65535方法数限制，二是线性内存分配器（LinearAlloc）限制。
解决方案：
谷歌方案：官方的MultiDex分dex机制解决了方法数限制的问题，其中main dex最小化原则，结合dalvik LinearAlloc heap size调整（修改到了16M），使得dexopt的失败几率大幅下降。而art的出现彻底不再存在LinearAlloc这样的限制。
功能上的轻重分离
解耦思想：功能插件化。将附属的新功能分离在独立的插件工程（p_XX）中，保证主app功能的快速和稳定，每个插件有独立的UI界面逻辑和资源、存储及网络协议编解码处理逻辑，通过共用统一的基础库接口访问网络服务。而且保证插件之间不依赖，插件只会向下依赖，从架构上，纵向分离功能模块。
加快开发速度的方法：创建必要的工具和规范：利用代码字段生成的手段，减少重复，模式化的代码开发工作。
做新功能时，使用独立插件子工程，好的工程模板可以事半功倍。
开源软件的开发模式：使用git做版本控制，采用gradle + Android Studio的分布式构建思想，采用多个分支并行开发。公共组件通过maven在不同的开发团队*享并随时使用。