Android Framework系列4-1 应用进程

Android应用进程

首先还是先抛出三个问题：

你知道应用进程是怎么启动的吗？
你是怎么理解Application的
你是怎么理解Context的

由于应用进程相关涉及比较多，分4个章节讲解，本章讲解下应用经常是如何启动的。

应用进程是如何启动的

Linux下进程启动的方式
应用进程启动的原理

Linux下进程启动的方式

进程启动方式主要有如下两种：

if ((pid = fork()) < 0) {
    // error
} else if (pid == 0) {
    // child process
} else {
    // parent process
}

if ((pid = fork()) < 0) {
    // error
} else if (pid == 0) {
    // child process
    execve(path, argv, env);
} else {
    // parent process
}

进程启动都是通过fork函数，这个函数能会返回两次，一个是子进程返回，一个是父进程返回；子进程返回的pid是0，父进程返回的pid就是子进程的pid。

上面两种方式区别就是execve，不带execve代表子进程是共享父进程的资源，带了execve的话，子进程的资源就被参数中的path替换掉了，path是一个二进制程序的路径

应用进程的启动原理

什么时候触发的进程启动？谁发起的？
进程是谁启动的？怎么启动的？

什么时候触发的进程启动
在我们应用程序中，没有主动启动进程的方法，进程启动都是被动启动的，何为被动启动？也即是我们在启动组件的时候，如果这个时候组件所在的进程没有启动，这个时候才会去启动相关进程。

ProcessRecord app =  getProcessRecordLocked(…);
if (app != null && app.thread != null) {   
 // 进程已经启动了，这里可以启动组件了
    return;
}
startProcessLocked(r.processName);

不管是启动Service或者Activity，都会做上面代码的判断。

getProcessRecordLocked 查找组件所在进程，每个进程都对应一个ProcessRecord结构。

没有找到组件所对应的ProcessRecord结构，就会执行startProcessLocked去启动进程。

如果找到了ProcessRecord，且里面的thread不为null，则代表进程已启动。

疑问：app != null可以理解，但是app.thread != null又是什么？？，我们先看下下面这张图：

应用进程启动.png

应用通过getService能拿到AMS的IActivityManager(细节可看系统服务)，这样它就能通过IActivityManager跟AMS发起binder调用。

如果AMS需要通知应用，例如调用应用组件的生命周期怎么办？所以AMS也应该要持有应用的binder句柄(IApplicationThread)。

IApplicationThread其实就是上面代码中的app.thread

应用是如何把自己的句柄IApplicationThread告诉AMS的？
看如下代码，这个是应用程序启动的入口类ActivityThread

// 代码来自Android23中：ActivityThread.java
public static void main(String[] args) {
      ......
      Looper.prepareMainLooper();
      ActivityThread thread = new ActivityThread();
      thread.attach(false);
      Looper.loop();
}

Looper.prepareMainLooper()创建主线程的Loop

new了一个ActivityThread对象(非线程对象)，然后调用它的attach方法

loop循环

再看看thread.attach里面做了啥。

private void attach(boolean system) {
    ......
    final IActivityManager mgr = ActivityManagerNative.getDefault();
    mgr.attachApplication(mAppThread);
}

获取AMS的binder对象 mgr

调用mgr的attachApplication向AMS报告进程启动好了,其中的参数mAppThread就是应用端的binder句柄。

小总结
应用进程怎么样才算启动完成了呢？

AMS向Zygote发起启动应用进程的请求后（ Zygote启动），Zygote启动应用进程后会把进程的pid返回AMS
应用进程启动好后会告诉AMS。

组件启动

以启动Service为例，用户向AMS发送请求，最终会调到bringUpServiceLocked

// 代码来自Android23中：ActivityServices.java
private final String bringUpServiceLocked(ServiceRecord r, int intentFlags，...){
    ProcessRecord app= mAm.getProcessRecordLocked(procName, r.appInfo.uid, false);
    ...
    if (app != null && app.thread != null) {
        realStartServiceLocked(r, app, execInFg);
        return null;
    }
    ...
    if (app == null) {
        app=mAm.startProcessLocked(procName, r.appInfo,...);
    }
    if (!mPendingServices.contains(r)) {
         mPendingServices.add(r);
    }
}

根据进程名称去查看进程对象ProcessRecord

如果查到了，既app != null && app.thread != null (进程已经启动了且已经向AMS报备了)，则直接启动Service

如果app != null则代表进程还未启动，直接启动进程

别的情况代表进程已经启动但还暂未向AMS报备，直接把Service加入到mPendingServices列表。

mPendingServices列表中的Service什么时候启动呢？
当应用进程启动好向AMS报备时，最终会调用attachApplicationLocked去处理mPendingServices

// 代码来自Android23中：ActivityServices.java
if (mPendingServices.size() > 0) {
    ServiceRecord sr = null;
    for (int i=0; i



就是一个循环，去获取ServiceRecord，然后启动。



应用进程启动
上面代码有提过，启动进程是通过AMS中的startProcessLocked。


向Zygote通过Socket发送参数列表
参数列表中有一项是应用进程启动后它会启动的Java类的类名(也就是ActivityThread.java)
等待进程创建结果，会返回创建的进程ID.


Zygote启动 后呢，会进入loop循环，当获取Socket后会执行runOnce函数
// 代码来自Android23中：ZygoteConnection.java
boolean runOnce(){
    String args[] = readArgumentList();
    int pid = Zygote.forkAndSpecialize(...);
    if (pid == 0) {
        handleChildProc(...);
        return true;
    } else {
        return handleParentProc(pid,...);
    }
}



读取Socket发过来的参数列表
根据参数创建进程
如果pid==0代表子进程，则会去执行一个Java类的入口函数(ActivityThread.main())
如果pid !=0 代表父进程，则把pid通过Socket在写回去




总结

在启用组件的时候，如果进程未启动，则先会去启动应用进程。
应用进程启动是由AMS通过Socket通信向Zygote发起。
Zygote fork出应用进程后，回去执行ActivityThread的main函数(类名是通过Socket传过来的)。
应用进程启动后，在ActivityThread.main中会调用attach向AMS报告，让AMS也能拿到应用进程的binder对象，这样AMS跟应用就能双向交互了。