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<mPendingServices.size(); i++) {
sr = mPendingServices.get(i);
mPendingServices.remove(i);
i--;
realStartServiceLocked(sr, proc, sr.createdFromFg);
}
}
就是一个循环，去获取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跟应用就能双向交互了。
