Android多进程总结一:生成多进程(android:process属性)

前言

正常情况下，一个apk启动后只会运行在一个进程中，其进程名为apk的包名，所有的组件都会在这个进程中运行，以下为DDMS的进程截屏：

com.biyou.multiprocess为进程名，也是apk的包名，

但是如果需要将某些组件（如Service，Activity等）运行在单独的进程中，就需要用到android:process属性了。我们可以给android的组件设置android:process属性来使其运行在指定的进程中。

AndroidMantifest.xml中的activity、service、receiver和provider均支持android:process属性
设置该属性可以使每个组件均在各自的进程中运行，或者使一些组件共享一个进程
AndroidMantifest.xml中的application元素也支持android:process属性，可以修改应用程序的默认进程名（默认值为包名）

为何要使用多进程

1.分散内存的占用

我们知道Android系统对每个应用进程的内存占用是有限制的，而且占用内存越大的进程，通常被系统杀死的可能性越大。让一个组件运行在单独的进程中，可以减少主进程所占用的内存，避免OOM问题，降低被系统杀死的概率，

2.实现多模块

比如我做的应用大而全，里面肯定会有很多模块，假如有地图模块、大图浏览、自定义WebView等等（这些都是吃内存大户），还会有一些诸如下载服务，监控服务等等，一个成熟的应用一定是多模块化的。

当我们的应用开发越来越大，模块越来越多，团队规模也越来越大，协作开发也是个很麻烦的事情。项目解耦，模块化，是这阶段的目标。通过模块解耦，开辟新的进程，独立的JVM，来达到数据解耦目的。模块之间互不干预，团队并行开发，责任分工也明确。

3.子进程奔溃，主进程可以继续工作

如果子进程因为某种原因崩溃了，不会直接导致主程序的崩溃，可以降低我们程序的崩溃率。

4.主进程退出，子进程可以继续工作

即使主进程退出了，我们的子进程仍然可以继续工作，假设子进程是推送服务，在主进程退出的情况下，仍然能够保证用户可以收到推送消息。

5.实现守护进程

如果主线程中的服务要从开机起持续运行，若由于内存等原因被系统kill掉，守护进程可以重新启动主线程的服务。

通过JNI利用C/C++，调用fork()方法来生成子进程，一般开发者会利用这种方法来做一些daemon（守护进程）进程，来实现防杀保活等效果。

另外：

还能通过监控进程，将这个错误上报给系统，告知他在什么机型、环境下、产生了什么样的Bug，提升用户体验。

实现

1 . 如果android:process的值以冒号开头的话，那么该进程就是私有进程，如下：

配置：

   ……

进程：

2 . 以小写字母开头(如com.secondProcess)，那么就是公有进程，android:process值一定要有个点号：

不能以数字开头,并且要符合命名规范，必须要有.否则将会出现这种错误： Invalid process name simon in package com.wind.check: must have at least one ‘.’
配置：

   ……

进程：

3 . 私有进程和公有进程的区别：
android:process=":remote"，以冒号开头，冒号后面的字符串原则上是可以随意指定的。如果我们的包名为“com.biyou.multiprocess”，则实际的进程名
为“com.biyou.multiprocess:remote”。这种设置形式表示该进程为当前应用的私有进程，其他应用的组件不可以和它跑在同一个进程中。
全局进程
进程名称不以“:”开头的进程都可以叫全局进程，如android:process="com.secondProcess"，以小写字母开头，表示运行在一个以这个名字命名的全局进程中，其他应用通过设置相同的ShareUID可以和它跑在同一个进程。

ps:ShareUID :
ShareUserId，在Android里面每个app都有一个唯一的linux user ID，则这样权限就被设置成该应用程序的文件只对该用户可见，只对该应用程序自身可见，而我们可以使他们对其他的应用程序可见，这会使我们用到SharedUserId，也就是让两个apk使用相同的userID，这样它们就可以看到对方的文件。为了节省资源，具有相同ID的apk也可以在相同的linux进程中进行(注意，并不是一定要在一个进程里面运行)，共享一个虚拟机。
ShareUserId的作用，数据共享、调用其他程序资源。

进程生命周期与优先级

Android 系统将尽量长时间地保持应用进程，但为了新建进程或运行更重要的进程，最终需要移除旧进程来回收内存。为了确定保留或终止哪些进程，系统会根据进程中正在运行的组件以及这些组件的状态，将每个进程放入“重要性层次结构”中。必要时，系统会首先消除重要性最低的进程，然后是重要性略逊的进程，依此类推，以回收系统资源。

重要性层次结构一共有 5 级。以下列表按照重要程度列出了各类进程（第一个进程最重要，将是最后一个被终止的进程）：

1.前台进程：（foreground process）

用户当前操作所必需的进程。如果一个进程满足以下任一条件，即视为前台进程：
托管用户正在交互的 Activity（已调用 Activity 的 onResume() 方法）
托管某个 Service，后者绑定到用户正在交互的 Activity
托管正在“前台”运行的 Service（服务已调用 startForeground()）
托管正执行一个生命周期回调的 Service（onCreate()、onStart() 或 onDestroy()）
托管正执行其 onReceive() 方法的 BroadcastReceiver
通常，在任意给定时间前台进程都为数不多。只有在内存不足以支持它们同时继续运行这一万不得已的情况下，系统才会终止它们。此时，设备往往已达到内存分页状态，因此需要终止一些前台进程来确保用户界面正常响应。

2.可见进程

没有任何前台组件、但仍会影响用户在屏幕上所见内容的进程。如果一个进程满足以下任一条件，即视为可见进程：
托管不在前台、但仍对用户可见的 Activity（已调用其 onPause() 方法）。例如，如果前台 Activity 启动了一个对话框，允许在其后显示上一 Activity，则有可能会发生这种情况。
托管绑定到可见（或前台）Activity 的 Service。
可见进程被视为是极其重要的进程，除非为了维持所有前台进程同时运行而必须终止，否则系统不会终止这些进程。

3.服务进程
正在运行已使用 startService() 方法启动的服务且不属于上述两个更高类别进程的进程。尽管服务进程与用户所见内容没有直接关联，但是它们通常在执行一些用户关心的操作（例如，在后台播放音乐或从网络下载数据）。因此，除非内存不足以维持所有前台进程和可见进程同时运行，否则系统会让服务进程保持运行状态。

4.后台进程
包含目前对用户不可见的 Activity 的进程（已调用 Activity 的 onStop() 方法）。这些进程对用户体验没有直接影响，系统可能随时终止它们，以回收内存供前台进程、可见进程或服务进程使用。通常会有很多后台进程在运行，因此它们会保存在 LRU （最近最少使用）列表中，以确保包含用户最近查看的 Activity 的进程最后一个被终止。如果某个 Activity 正确实现了生命周期方法，并保存了其当前状态，则终止其进程不会对用户体验产生明显影响，因为当用户导航回该 Activity 时，Activity 会恢复其所有可见状态。有关保存和恢复状态的信息，请参阅 Activity文档。

5.空进程
不含任何活动应用组件的进程。保留这种进程的的唯一目的是用作缓存，以缩短下次在其中运行组件所需的启动时间。为使总体系统资源在进程缓存和底层内核缓存之间保持平衡，系统往往会终止这些进程。
根据进程中当前活动组件的重要程度，Android 会将进程评定为它可能达到的最高级别。例如，如果某进程托管着服务和可见 Activity，则会将此进程评定为可见进程，而不是服务进程。

此外，一个进程的级别可能会因其他进程对它的依赖而有所提高，即服务于另一进程的进程其级别永远不会低于其所服务的进程。例如，如果进程 A 中的内容提供程序为进程 B 中的客户端提供服务，或者如果进程 A 中的服务绑定到进程 B 中的组件，则进程 A 始终被视为至少与进程 B 同样重要。

由于运行服务的进程其级别高于托管后台 Activity 的进程，因此启动长时间运行操作的 Activity 最好为该操作启动服务，而不是简单地创建工作线程，当操作有可能比 Activity 更加持久时尤要如此。例如，正在将图片上传到网站的 Activity 应该启动服务来执行上传，这样一来，即使用户退出 Activity，仍可在后台继续执行上传操作。使用服务可以保证，无论 Activity 发生什么情况，该操作至少具备“服务进程”优先级。同理，广播接收器也应使用服务，而不是简单地将耗时冗长的操作放入线程中。

注意的地方

有一点一定要记住：进程间的内存空间是不可见的。从而，开启多进程后，我们需要面临这样几个问题：

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。那么怎么来解决这个问题呢？
下面给出解决方案：

思路：判断是否为主进程，只有主进程的时候才执行下面的操作

String processName = this.getProcessName();//判断进程名，保证只有主进程运行if (!TextUtils.isEmpty(processName) &&processName.equals(this.getPackageName())) {    //在这里进行主进程初始化逻辑操作                              Log.i(">>>>>>","oncreate");}

获取进程名的方法，这个方法是效率最好的：

 public static String getProcessName() {        try {            File file = new File("/proc/" + android.os.Process.myPid() + "/" + "cmdline");            BufferedReader mBufferedReader = new BufferedReader(new FileReader(file));            String processName = mBufferedReader.readLine().trim();            mBufferedReader.close();            return processName;        } catch (Exception e) {            e.printStackTrace();            return null;        }    }

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 ：

从上面的代码和执行结果看，我们在Activity中定义了一个标志processFlag并在onCreate中修改了它的值为true，然后启动Service，但是在Service中读到这个值却为false。按照正常的逻辑，静态变量是可以在应用的所有地方共享的，但是设置了process属性后，产生了两个隔离的内存空间，一个内存空间里值的修改并不会影响到另外一个内存空间。

3. 文件共享问题。

多进程情况下会出现两个进程在同一时刻访问同一个数据库文件的情况。这就可能造成资源的竞争访问，导致诸如数据库损坏、数据丢失等。在多线程的情况下我们有锁机制控制资源的共享，但是在多进程中比较难，虽然有文件锁、排队等机制，但是在Android里很难实现。解决办法就是多进程的时候不并发访问同一个文件，比如子进程涉及到操作数据库，就可以考虑调用主进程进行数据库的操作。

参考：
1. 这可能是最全的Android:Process （进程）讲解了
2. Android应用内多进程分析和研究

前言