Android 多进程开发教程
前言
正常情况下，一个apk启动后只会运行在一个进程中，其进程名为AndroidManifest.xml文件中指定的应用包名，所有的基本组件都会在这个进程中运行。但是如果需要将某些组件（如Service、Activity等）运行在单独的进程中，就需要用到android:process属性了。我们可以为android的基础组件指定process属性来指定它们运行在指定进程中。android使用多进程重构项目架构，可以分担主进程压力以免因资源消耗过大被crash掉，另外多进程相互监听唤醒，可以使应用程序长期驻守后台接受即时消息和通知，防止应用被系统回收。下面就总结一下多进程开发的经验及优化。
一、多进程概念
一般情况下，一个应用程序就是一个进程，这个进程名称就是应用程序包名。我们知道进程是系统分配资源和调度的基本单位，所以每个进程都有自己独立的资源和内存空间，别的进程是不能任意访问其他进程的内存和资源的。
二、多进程机制
四大组件在AndroidManifest文件中注册的时候，有个属性android:process这里可以指定组件的所处的进程。
对process属性的设置有两种形式：
第一种形式：如android:process=":remote"，以冒号开头，冒号后面的字符串原则上是可以随意指定的。如果我们的包名为“com.example.processtest”，则实际的进程名为“com.example.processtest:remote”。这种设置形式表示该进程为当前应用的私有进程，其他应用的组件不可以和它跑在同一个进程中。
第二种形式：如android:process="com.example.processtest.remote"，以小写字母开头，表示运行在一个以这个名字命名的全局进程中，其他应用通过设置相同的ShareUID可以和它跑在同一个进程。
下面通过一个例子来进行一下验证。我们定义两个类：ProcessTestActivity和ProcessTestService，然后在AndroidManifest.xml文件中增加这两个类，并为我们的Service指定一个process属性，代码如下：
运行代码，通过DDMS进行观察
我们可以看到两个进程，名字分别是“com.example.processtest”和“com.example.processtest:remote”，进程ID分别为2722和2739。
ProcessTestService运行在一个单独的私有进程中，如果想让ProcessTestService运行在一个全局进程中，那么只需修改android:process="com.example.processtest.remote"即可。Android为每一个应用程序分配了一个独立的虚拟机，或者说为每个进程都分配了一个独立的虚拟机，不同的虚拟机在内存分配上 有不同的地址空间，这就会导致在不同的虚拟机中访问同一类的对象会产生多份副本。在一个进程中修改某个值只会影响当前进程，对其他进程不会造成任何影响。
三、多进程优点
一般来说，Android应用多进程有三个好处：
1）我们知道Android系统对每个应用进程的内存占用是有限制的，而且占用内存越大的进程，通常被系统杀死的可能性越大。让一个组件运行在单独的进程中，可以减少主进程所占用的内存，降低被系统杀死的概率.
2）如果子进程因为某种原因崩溃了，不会直接导致主程序的崩溃，可以降低我们程序的崩溃率。
3）即使主进程退出了，我们的子进程仍然可以继续工作，假设子进程是推送服务，在主进程退出的情况下，仍然能够保证用户可以收到推送消息。
四、多进程缺点
我们已经开启了应用内多进程，那么，开启多进程是不是只是我们看到的这么简单呢？其实这里面会有一些陷阱，稍微不注意就会陷入其中。我们首先要明确的一点是进程间的内存空间时不可见的。
从而，开启多进程后，我们需要面临这样几个问题：
1）Application的多次重建。运行在同一个进程中的组件是属于同一个虚拟机和同一个Application的，运行在不同进程中的组件是属于两个不同的虚拟机和Application的。
2）静态成员和单例模式完全失效。
3）文件共享问题。比如SharedPreferences 的可靠性下降。
4）断点调试问题。
1、Application的多次重建
我们先通过一个简单的例子来看一下第一种情况。
Manifest文件如上面提到的，定义了两个类：ProcessTestActivity和ProcessTestService,我们只是在Activity的onCreate方法中直接启动了该Service，同时，我们自定义了自己的Application类。代码如下：
public class MyApplication extends Application {
public static final String TAG = "viclee";
@Override
public void onCreate() {
super.onCreate();
int pid = android.os.Process.myPid();
Log.d(TAG, "MyApplication onCreate");
Log.d(TAG, "MyApplication pid is " + pid);
}
}
public class ProcessTestActivity extends Activity {
public final static String TAG = "viclee";
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_process_test);
Log.i(TAG, "ProcessTestActivity onCreate");
this.startService(new Intent(this, ProcessTestService.class));
}
}
public class ProcessTestService extends Service {
public static final String TAG = "viclee";
@Override
public void onCreate() {
Log.i(TAG, "ProcessTestService onCreate");
}
@Override
public IBinder onBind(Intent arg0) {
return null;
}
}
执行上面这段代码，查看打印信息：
我们发现MyApplication的onCreate方法调用了两次，分别是在启动ProcessTestActivity和ProcessTestService的时候，而且我们发现打印出来的pid也不相同。由于通常会在Application的onCreate方法中做一些全局的初始化操作，它被初始化多次是完全没有必要的。出现这种情况，是由于即使是通过指定process属性启动新进程的情况下，系统也会新建一个独立的虚拟机，自然需要重新初始化一遍Application。那么怎么来解决这个问题呢？
我们可以通过在自定义的Application中通过进程名来区分当前是哪个进程，然后单独进行相应的逻辑处理。
public class MyApplication extends Application {
public static final String TAG = "viclee";
@Override
public void onCreate() {
super.onCreate();
int pid = android.os.Process.myPid();
Log.d(TAG, "MyApplication onCreate");
Log.d(TAG, "MyApplication pid is " + pid);
ActivityManager am = (ActivityManager) getSystemService(Context.ACTIVITY_SERVICE);
List runningApps = am.getRunningAppProcesses();
if (runningApps != null && !runningApps.isEmpty()) {
for (ActivityManager.RunningAppProcessInfo procInfo : runningApps) {
if (procInfo.pid == pid) {
if (procInfo.processName.equals("com.example.processtest")) {
Log.d(TAG, "process name is " + procInfo.processName);
} else if (procInfo.processName.equals("com.example.processtest:remote")) {
Log.d(TAG, "process name is " + procInfo.processName);
}
}
}
}
}
}
运行之后，查看Log信息：
图中可以看出，不同的进程执行了不同的代码逻辑，可以通过这种方式来区分不同的进程需要完成的初始化工作。
2、静态变量和单例模式完全失效
下面我们来看第二个问题，将之前定义的Activity和Service的代码进行简单的修改，代码如下：
public class ProcessTestActivity extends Activity {
public final static String TAG = "viclee";
public static boolean processFlag = false;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_process_test);
processFlag = true;
Log.i(TAG, "ProcessTestActivity onCreate");
this.startService(new Intent(this, ProcessTestService.class));
}
}
public class ProcessTestService extends Service {
public static final String TAG = "viclee";
@Override
public void onCreate() {
Log.i(TAG, "ProcessTestService onCreate");
Log.i(TAG, "ProcessTestActivity.processFlag is " + ProcessTestActivity.processFlag);
}
@Override
public IBinder onBind(Intent arg0) {
return null;
}
}
重新执行代码，打印Log：
针对静态变量失效的问题，我们可以使用Intent或者aidl等进程通讯方式传递内容。
3、文件共享问题
第三个问题是文件共享问题。多进程情况下会出现两个进程在同一时刻访问同一个数据库文件的情况。这就可能造成资源的竞争访问，导致诸如数据库损坏、数据丢失等。在多线程的情况下我们有锁机制控制资源的共享，但是在多进程中比较难，虽然有文件锁、排队等机制，但是在Android里很难实现。解决办法就是多进程的时候不并发访问同一个文件，比如子进程涉及到操作数据库，就可以考虑调用主进程进行数据库的操作。
4、断点调试问题
最后是断点调试的问题。调试就是跟踪程序运行过程中的堆栈信息，由于每个进程都有自己独立的内存空间和各自的堆栈，无法实现在不同的进程间调试。不过可以通过下面的方式实现：调试时去掉AndroidManifest.xml中android:process标签，这样保证调试状态下是在同一进程中，堆栈信息是连贯的。待调试完成后，再将标签复原。
五、多进程使用场景
类似音乐类、跑步健身类、手机管家类等长时间需要在后台运行的应用。这些应用的特点就是，当用户切到别的应用，或者关掉手机屏幕的时候，应用本身的核心模块还在正常运行，提供服务。如果因为手机内存过低，或者是进程重要性降低，导致应用被杀掉，后台服务停止，对于这些应用来说，就是灭顶之灾。合理利用多进程，将核心后台服务模块和其他UI模块进行分离，保证应用能更稳定的提供服务，从而提升用户体验。
举个例子：
现在要做一款音乐播放器，现在有以下几种方案：
A. 在Activity中直接播放音乐。
B. 启动后台Service，播放音乐。
C. 启动前台Service，播放音乐。
D. 在新的进程中，启动后台Service，播放音乐。
E. 在新的进程中，启动前台Service，播放音乐。
A. 在Activity中直接播放音乐。
在A中，我们的播放器是直接在activity中启动的。首先这么做肯定是不对的，我们需要在后台播放音乐，所以当activity退出后就播不了了，之所以给出这个例子是为了控制变量作对比。
然后我们来看下A的使用场景。
音乐播放器无非是打开app，选歌，播放，退到桌面，切其他应用。我们选取了三个场景，打开、按home切换其他应用、按back退回桌面。让我们看一下A的相对应的oom_adj、oom_score、oom_score_adj的值。（下面三张图依次对应为【打开状态】、【按了Home键被切换状态】、【按了Back键被退出状态】）
上图为打开状态下oom_adj、oom_score、oom_score_adj的值
上图为按了Home键状态下oom_adj、oom_score、oom_score_adj的值
上图为按了Back键状态下oom_adj、oom_score、oom_score_adj的值
当我们应用在前台的时候，无论adj还是score还是score_adj，他们的值都非常的小，基本不会被LMK所杀掉，但是当我们按了Home之后，进程的adj就会急剧增大，变为7，相应的score和score_adj也会增大。在上篇文章中我们得知，adj=7即为被切换的进程，两个进程来回切换，上一个进程就会被设为7。当我们按Back键的时候，adj就会被设为9，也就是缓存进程，优先级比较低，有很大的几率被杀掉。
B. 启动后台Service，播放音乐。
B是直接启动一个后台service并且播放音乐，这个处理看起来比A好了很多，那么实际上，B的各个场景的优先级和A又有什么不同呢？让我们来看下B的对应的打开、切换、退出相应的adj、score、score_adj的值。（下面三张图依次对应为【打开状态】、【按了Home键被切换状态】、【按了Back键被退出状态】）
上图为打开状态下oom_adj、oom_score、oom_score_adj的值
上图为按了Home键状态下oom_adj、oom_score、oom_score_adj的值
上图为按了Back键状态下oom_adj、oom_score、oom_score_adj的值
B的情况其实是与A类似的，三种状态的adj、score_adj的值都是一样的，只有score有一点出入，其实分析源码得知，LMK杀进程的时候，score的左右其实并不大，所以我们暂时忽略它。所以，与A相比，他们的adj和score_adj的值都相同，如果遇到内存不足的情况下，这两个应用谁占得内存更大，谁就会被杀掉。不过鉴于A实在activity中播放音乐，所以B还是比A略好的方案。
C. 启动前台Service，播放音乐。
C的话是启动一个前台Service来播放音乐。让我们来看一下对应的值。（下面三张图依次对应为【打开状态】、【按了Home键被切换状态】、【按了Back键被退出状态】）
上图为打开状态下oom_adj、oom_score、oom_score_adj的值
上图为按了Home键状态下oom_adj、oom_score、oom_score_adj的值
上图为按了Back键状态下oom_adj、oom_score、oom_score_adj的值
在前台的时候，和AB是一样的，adj都是0，当切到后台，或者back结束时，C对应的adj就是2，也就是可感知进程。adj=2可以说是很高优先级了，非root手机，非系统应用已经没有办法将其杀掉了。adj<5的应用不会被杀掉。
总的来说，C方案比B优秀，拥有前台Service的C更不容易被系统或者其他应用所杀掉了，进程的优先级一下子提高到了2，相对于B来说更稳定，用户体验更好。不过有一点不足是必须启动一个前台service。不过现在大部分的音乐类软件都会提供一个前台service，也就不是什么缺点了。其实也是有灰色方法可以启动一个不显示通知的前台service，这里就不过多介绍了。
那么还有可改进的余地吗？
答案当然是肯定的。
D. 在新的进程中，启动后台Service，播放音乐。
终于我们的主角，多进程登场了。
D把应用进行了拆分，把用于播放音乐的service放到了新的进程内，让我们看一下对应的值。（下面三张图依次对应为【打开状态】、【按了Home键被切换状态】、【按了Back键被退出状态】）
上图为打开状态下oom_adj、oom_score、oom_score_adj的值
上图为按了Home键状态下oom_adj、oom_score、oom_score_adj的值
上图为按了Back键状态下oom_adj、oom_score、oom_score_adj的值
上面三张图对应的是D应用主进程的ADJ相关值，我们可以看出来，跟A类似，adj都是0，7，9。由于少了service部分，内存使用变少，最后计算出的oom_score_adj也更低了，意味着主进程部分也更不容易被杀死。
下面我们看下拆分出的service的相关值
上图为后台Service的oom_adj、oom_score、oom_score_adj的值
因为是service进程，所以不受打开，关闭，切换所影响，这里就放了一张图。
我们可以看到，service的adj值一直是5，也就是活跃的服务进程，相比于B来说，优先级高了不少。不过对于C来说，其实这个方案反倒不如C的adj=2的前台进程更稳定。但是D可以自主释放主进程，使D实际所占用的内存很小，从而不容易被杀掉。那么到底C和D谁是更优秀的设计？我个人认为，在ABCDE这5个设计中，D是最具智慧的设计，具体是为什么？先卖个关子，等我们说完了E，再作总结。
E. 在新的进程中，启动前台Service，播放音乐。
E也是使用了多进程，并且在新进程中，使用了前台service，先来看下对应的值。（下面三张图依次对应为【打开状态】、【按了Home键被切换状态】、【按了Back键被退出状态】）
上图为打开状态下oom_adj、oom_score、oom_score_adj的值
上图为按了Home键状态下oom_adj、oom_score、oom_score_adj的值
上图为按了Back键状态下oom_adj、oom_score、oom_score_adj的值
这个不多解释，和ABD基本差不多，都是0，7，9。我们看下拆分出来的进程的值。上图为后台Service的oom_adj、oom_score、oom_score_adj的值
我们可以看到，这个进程的值是2，像C方案，非常小，非常稳定，而且，我们还可以在系统进入后台后，手动杀掉主进程，使整个应用的内存消耗降到最低，内存低，优先级又高，E获得了今天的最稳定的方案奖。
小结
ABCDE，5种方案都已经分析完了。显然，E是最稳定的方案，不过，我刚才说过，我个人最倾向于D方案，并且认为D是最智慧的方案，这是为什么呢？
其实我们可以做个比喻，把整个Android系统比喻成一个旅游景点，Low Memory Killer就是景点的门卫兼保安，然后我们每个进程的ADJ相当于手里的门票，有的人是VIP门票，有的人是普通门票。景点平常没人的时候还好，谁拿票都能进，当人逐渐拥挤的时候，保安就开始根据票的等级，往外轰人。E方案就是一个拿着普通票的妈妈，带着一个VIP的孩子去参观，D方案就是一个拿着普通票的妈妈，带着一个拿着中等票的孩子参观。当内存不够的时候，保安会先把两个妈妈轰出去，孩子们在里面看，再不够了，就会把D孩子给轰出去。这么看来，显然E的效果更好一些，不过由于Android系统对于VIP票的发放没有节制，大家都可以领VIP票，那也就是相当于没有VIP票了。所以如果E方案是一种精明，那么D才是真正的智慧。将调度权还给系统，做好自己，维护好整个Android生态。
多模块应用
多进程还有一种非常有用的场景，就是多模块应用。比如我做的应用大而全，里面肯定会有很多模块，假如有地图模块、大图浏览、自定义WebView等等（这些都是吃内存大户），还会有一些诸如下载服务，监控服务等等，一个成熟的应用一定是多模块化的。
首先多进程开发能为应用解决了OOM问题，Android对内存的限制是针对于进程的，这个阈值可以是48M、24M、16M等，视机型而定，所以，当我们需要加载大图之类的操作，可以在新的进程中去执行，避免主进程OOM。
多进程不光解决OOM问题，还能更有效、合理的利用内存。我们可以在适当的时候生成新的进程，在不需要的时候及时杀掉，合理分配，提升用户体验。减少系统被杀掉的风险。
多进程还能带来一个好处就是，单一进程崩溃并不影响整体应用的使用。例如我在图片浏览进程打开了一个过大的图片，java heap 申请内存失败，但是不影响我主进程的使用，而且，还能通过监控进程，将这个错误上报给系统，告知他在什么机型、环境下、产生了什么样的Bug，提升用户体验。
再一个好处就是，当我们的应用开发越来越大，模块越来越多，团队规模也越来越大，协作开发也是个很麻烦的事情。项目解耦，模块化，是这阶段的目标。通过模块解耦，开辟新的进程，独立的JVM，来达到数据解耦目的。模块之间互不干预，团队并行开发，责任分工也明确。至于模块化开发与多进程的结合，后续会写一篇专门的文章来研究这个问题。