面临的问题？
随着业务部门在移动平台的需求量越来越多，功能需求在单向递增，N个功能模块在同一个进程中去争抢内存，如果使用不当，会带来很多稳定性的问题（卡，慢，崩）。
功能需求增多之后，将会带来以下问题：
1. 最直观看到的便是应用的体积变大，即DEX文件变大，当被映射到内存时，这部分内存很难被卸载回收。
2. 每个应用的内存大小是有限制的，应用并不是无限制的申请内存，系统也设有临界值，如果在运行时申请内存超过临界值，就会触发大名鼎鼎的OOM，则应用闪退。
3. 团队中研发人员的技术能力参差不齐，内存泄漏和抖动很常见，时不时触发Android内存回收的潜规则与GC，直接的现象就是闪退或卡顿。
4. 运行时的异常也在变多，N个模块的逻辑运行在同一个进程，一旦某个逻辑处理不当，将导致整个应用退出或ANR。
以上问题都是不可接受的，如果不能很好的解决，用户体验很差，就会直接影响留存率。
功能需求量增加，不仅仅带来的是“内存问题”，会有很多问题等待读者去解决，比如：安装包体积，系统本身问题(65k方法数)，流量，电量，升级，软件结构，团队协作，测试，非功能需求(灵活性，扩展性等)有很高的要求，等等这些，都需要我们一一克服，过程也是很痛苦。
分析
上面所有内存导致的不稳定问题，都是由“N多个模块去争抢同一个进程的内存”导致的，既然一个进程无法满足要求，是不是多个进程可以解决？
读者如果了解“分布式”的概念，是不是可以从中得到启发，分布式简单说就是当用户并发量较大时，一台服务器无法同时完成多个任务的执行，那么就需要将任务“分离”到不同的服务器来处理，每台服务器完成一个任务，这样，多个任务之间不需要去争抢一台服务器的CPU和内存，这样就可以提高并发。 这种思想也适用于我们当前的问题，既然我们多个模块无法在同一个进程中很好的完成任务，那么我们是不是可以将任务“分解”到不同的进程中，每个任务对应一个进程，每个任务有自己的内存空间呢？ 答案是肯定的。
在设计上，用的最多的几个词“分离”，“分割”，“分解”，“分层”，这也是设计的核心方法模式，小到代码组织结构设计，大到系统架构设计，均适用。
什么是多进程？
我们知道默认情况下，在Android中一个应用对应一个进程，而多进程顾名思义，即一个应用对应多个进程，一个进程对应一个VM实例，进程间并行执行，独享自己的VM heap大小。
为什么要实现多进程？
1. 某个模块的运行时逻辑错误不会导致整个应用退出；
2. 模块独自享有自己的内存空间，降低了由于内存泄漏或抖动等导致的超出内存临界值时闪退与卡慢问题；
3. 常驻或特殊需求的实现；
从以上几点可以看出“多进程化”是解决上面提到的大部分内存问题的很重要的一个手段，可能也是大型应用的必由之路。
对于一个没有采用多进程化的应用，要走这条路也是非常痛苦的，需要历经磨难，持续打磨才能修得正果，但是一旦完成，效果也是很明显的。笔者写这篇文章的目标也是为了帮助这部分读者少走冤路，脱离苦海。
如何拆分进程？
拆分进程笔者的经验是按照“职责驱动设计”的原则进行拆分，职责驱动设计我相信大家应该并不陌生，也不过多介绍，我们通过职责驱动设计模式将我们不同的功能模块分离到不同的进程中。 例如：升级。 这也是移动应用必须具备的功能。 通常升级可分为两个部分逻辑，1.检测新版本。2.下载安装。对于#1的需求，很多应用都需要实时感知到新版本的发布，并同时检测新版本是否与当前环境匹配，如果匹配则下载并提示用户升级。既然要实时感知，所以检测逻辑需要常驻。 那么我们是否有可能将检测逻辑单独抽离出进程或整个升级模块抽离出进程？
何时创建与销毁进程？
假设，我们已经将应用拆分成了5个进程，那么这5个进程何时启动，当应用启动时一起启动？这显然是不对，也达不到降低内存的要求，所以我们一定要“按需”创建。 所谓的按需创建，即当开始触发某个任务时才去创建，任务结束则销毁进程所有内存。 只有这样，我们才能降低内存的占用，应用的常驻内存也会变的更小。 例如：一些应用都有悬浮窗的功能，通常这个功能是独立进程的。 那么何时创建这个进程呢？ 当应用被推到后台，回到Launcher的时候，悬浮窗才会显示，也正是在这个时候，才会去创建悬浮窗的进程。当再次回到我们的应用时悬浮窗消失，同时进程销毁释放内存。
多进程间如何通信？
在Android中已经很好的提供了多进程间通信的支持(Binder)，很简单，使用成本很低，通常情况下，有两种方法来实现：
1. 使用Aidl(帮你封装Binder的使用，整个Parcel的打包与解包由Aidl来完成，你不需关心)；
2. 手动实现基于Binder的Stub/Proxy模式(手动实现对Parcel的打包与解包);
以上两种方式，在Android系统源码中，也基本都有使用到，各有优缺点，我们不一一介绍，本文的重点也不在此，对于上面这两种方法，笔者都有尝试过，最早公司的进程间通信框架(DroidIPC)的实现就使用#2来完成，仅仅为了抛开aidl，实现对parcel的打包与解包流程可编辑。但是降低了研发效率。第二个版本之后我们就采用#1来代替#2(IPCServiceManager)，通过Gradle Plugin来辅助研发配置，从而大大提高了研发效率。
多进程框架如何选择？
随着进程数的增加，进程间互相提供服务支持的情况也越来越多，见下图：
服务进程间互相bind依赖，有很高的耦合，这种也是很糟糕的，而且代码可维护性很差，增加了出错的概率，也会影响开发效率。
如果引入中间框架来管理服务：
从上图能清楚的看出，进程间的依赖改善了很多，而且可维护性很强。
向大家推荐几款开源框架，请参考
此框架由笔者维护，下图是IPCServiceManager整体结构，详细使用请进入github，Demo点击这里
读者可以通过此框架来完成进程间的内存数据共享等需求；
框架由饿了么提供，详细使用请进入github，进入支持EventBus版本
写到这里，不知道读者是不是已经对多进程有了一些了解。实现多进程并不复杂，而且Android支持也比较好，成本低。时间和精力可能主要是拆分上，如果读者在拆分和实现的过程中有任何问题，我们可以一起讨论。
