微信Android客户端架构演进之路_apk 轻重分离-CSDN博客

Android手Q无障碍优化工作，对Android无障碍系统原理及开发技术有深入了解。

微信架构在“插件化/应用沙盒”上面下功夫，可以参考如atlas、small、DroidPlugin、DynamicApk等等方案
微信Android架构历史- https://mp.weixin.qq.com/s?__biz=MzAwNDY1ODY2OQ==&mid=2649286672&idx=1&sn=4d9db00c496fcafd1d3e01d69af083f9
微信客户端架构的演进过程，以及其背后的开发团队、流程的变化与思考- http://www.infoq.com/cn/articles/wechat-android-app-architecture?utm_campaign=righ
微信Android架构历史- https://mp.weixin.qq.com/s/6Q818XA5FaHd7jJMFBG60w

微信的移动端数据库组件WCDB和移动端IM网络层跨平台组件库Mars都已开源。
微信团队原创Android资源混淆工具：AndResGuard。

> 微信客户端的性能优化，主要分为网络、UI、内存、存储等四大模块：
网络方面：在 IPList 选择策略、复合连接、连接耗时和稳定性、收发包耗时和稳定性、协议包压缩精简等诸多方面均作了长期的优化措施；针对安卓的后台长连接这一项，研发团队就在心跳策略、Push 及时性等方面做了很多工作。（参照 Mars 开源项目了解更多）。
UI 方面：除了经典 TableView 和 ListView 优化外，团队在图片 / 视频编解码、Bitmap 磁盘映射、视频渲染 Open GL 等领域也花了不少功夫。
内存方面：微信团队构建了实用的内存泄漏工具以及前台 OOM 检测工具，在开发过程中即可快速发现内存访问不当的代码实现；针对联系人、头像和图片等模块做了统一的资源池，制定了符合微信特点的缓存和淘汰策略。
存储方面：团队研发了高易用接口的 WCDB 组件，统一了微信内的 DB 线程模型和事务机制；根据微信客户端的消息、联系人、朋友圈和收藏等模块做了针对性的 DB 分离和数据表拆分；通过修改 SQLite 源码，大幅度降低了 SQLITE_BUSY 的发生次数；通过配置 DB 文件和 WAL 文件的 mmap 模式，对 DB 的 IO 性能也有不少的提升。关于这方面的内容，欢迎大家参考 WCDB 开源项目。

> 微信版本迭代

V 1.0的时候，分层设计思想从这最早的版本开始引入一直到今天。回顾当时的设计，更像是MVP结合事件通知机制。从最上面由Activity组件组成的UI层（VIEW），往下到由NetScene组成的表现层（Presenter），再往下Network负责网络长短连接与数据库的通信与Storage组成的存储层。NetScene是一个网络或者本地任务的基本单元，包括操作网络做数据收发、协议编解码，操作数据库做各种联系人、消息模块的读写。典型的例子如发送一条消息NetSceneSendMsg、做一次收信同步操作NetSceneSync。1.0版本的微信整个UI的activity可能不超过五个。
微信的膨胀吗？代码、内存、apk大小都在膨胀，这其中，内存对消息收发的影响很关键。Android运行时的择优置换机制，会选取占用资源最多的程序结束掉，除了微信自己功能膨胀导致内存占用加大之外，前面说的不省心的webview，还会给我们在内存问题上挖坑。

V 2.0~3.5的时候，比如进程每一次都要重新加载，里面所有的Cache、图片、界面全部要重新去执行一遍同样的代码，每一次加载内存都需要重新消耗时间。而启动速度变慢，则是最明显，用户最能感知的问题。
Network的部分用轻重进程分离的思想，独立到一个单独的进程（:push）中，而上面两个层级依然跑在微信的主进程（:worker）中。而对于有内存泄露问题的webview或者其他不频繁使用的功能，再把其分离到独立的工具进程（:tools）中。通过分离进程，微信第一次重构解决了系统因为微信资源消耗，主动干掉微信服务的困境。分离后的push进程内存占用以及被系统kill回收的几率大幅降低，而对于worker和tools进程，我们不再要求其一定存在，只在用户收到消息，或者进入h5相关功能界面时存在即可。这个版本的架构变更基本达成了我们设定的目标，无论是电量还是平均待机内存消耗上都大幅度下降，从内存上来看下降了70%，电量的话也比竞品和我们前一个版本有好转。
Android虚拟机机制的设计缺陷：一是单dex 65535方法数限制，二是线性内存分配器（LinearAlloc）限制。因为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这样的限制

V 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版本是微信历史上非常重要的一环，从这个版本开始引入了游戏、支付和更加完善的公众账号体系。

-- 要保证不给处于高度需求压力下的开发人员增加架构变动的额外负担，首先要做的就是不要让他们重复修改代码，无缝迁移到新的架构。
一、创建必要的工具和规范。微信在4.3发现问题之前，一直坚持着非常好的开发效率优化思想，代码自动生成起到了很大的帮助。团队内部使用的自研的代码生成工具autogen，通过简单的xml定义，即可生成所需要的存储、协议编解码、事件机制代码。这使得我们具备了比较轻松解耦的前提。
二、新的架构要求开发者在做新功能时，使用独立插件子工程，好的工程模板可以事半功倍。早期传承下来的分层设计，也使得开发人员在前后两种开发模式下的学习成本降到最低。对应的编译和开发调试工具。
三、对于历史实现的功能特性，尽量通过反射等一些技巧，来保证不需要大规模重写代码，“先抗住，再优化”。不要一开始就追求完美，先活下来。直到5.1、5.2版本，我们才基本上全部完成这一次程序架构调整。
四、人。架构调整是必须要做的事，但是作为发起者，也不能只从理论角度去强硬推动。减少开发者的工作量，而不是增加，站在开发者的角度想问题，往往会得到非常积极的响应。
进入到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在不同的开发团队中共享并随时使用。