参考
Android多进程的数据库访问问题
Android中多进程的应用
Android IM 开发小结
关于 Android 进程保活，你所需要知道的一切
【Android多进程】在Android开发中，我们可能会使用单独的进程来做一些事情，比如推送服务，心跳服务等，这些不需要主应用启动，只需要一个独立的进程即可。这时候我们一般都会采用启动一个后台Service，这个Service运行在一个独立的进程中，比如在Androidmainfest.xml中配置Service的android:process=”:push”指定该Service运行在:push进程中。
一般情况下这样做是没有任何问题的，但是如果你在你的Application的onCreate方法里有对数据库的操作，或者该Service里有对数据库的操作，就会有可能会有两个进程同时操作一个数据库的情况，一个是你的主应用的进程，进程名为你的包名例如org.flysnow;
一个是你的Service所在的进程，进程名为你的包名+”:push”,即org.flysnow:push。这两个进程可能在同一时间访问同一个数据，同一个配置文件等。这就可能造成资源的竞争访问，造成的问题就不可预料了，比如数据库损坏，数据丢失等。
多进程其实和多线程一样，并发访问的时候产生的问题很难预料，在多线程的时候我们有锁等机制控制资源的访问，但是在多进程中比较难，虽然有文件锁、排队等机制，但是在Android里很难实现，毕竟在Android里一个进程就是一个VM虚拟机，底层的东西控制不了，Java层又没有办法控制，所以在多进程中一定不要有并发增删改文件的操作。
解决问题的核心就是不并发访问同一个文件，多线程时就使用Lock机制；多进程的时候就避免进行数据库的访问，比如只做一些心跳、激活、消息抓取等操作，涉及到把消息存储到数据库，访问配置文件等操作还是调用主进程进程操作。还一个要注意的就是Application的oncreate方法里要避免多进程访问同一文件，因为没一个进程初始化都会执行该方法，可以在一些进程初始化的时候不需要文件操作的时候不要进行文件操作，比如在onCreate里获取当前的进程，不等于包名的就不进行文件的访问操作，获取进程可以使用android.os.Process.myUid()方法。
好处：
1、分担主进程的内存压力。我们的应用越做越大，内存越来越多，将一些独立的组件放到不同的进程，它就不占用主进程的内存空间了。比如在启动一个不可见的轻量级私有进程，在后台收发消息，或者做一些耗时的事情，或者开机启动这个进程等。
2、防止主进程被杀守护进程，守护进程和主进程之间相互监视，有一方被杀就重新启动它。
坏处：
1、多占了系统的内存空间，很容易沾满而导致卡顿，同时也消耗用户的电量。同时在启动单独进程时，进程的创建会影响继承Application的实例，onCreate()会再次执行一遍。
2、不同进程之间内存不能共享，最大的弊端是他们之间通信麻烦，不能将公用数据放在Application中，堆栈信息、文件操作也是独立的，如果他们之间传递的数据不大并且是可序列化的，可以考虑通过Bundle传递， 如果数据量较大，则需要通过AIDL或者文件操作来实现。
