目录
- 前言
- 步骤
- step1 Ams发起请求startProcessLocked
- step2 Zygote收到请求
- step3 handleChildProc — 进入子进程的世界
- step4 RuntimeInit.zygoteInit — 子进程环境准备
- nativeZygoteInit
- applicationInit
- step5 ActivityThread — app的入口
- 总结
前言
我们知道当startActivity的时候，除了创建Activity相关实体，系统会根据需要是否创建进程，此进程就是指的Linux层面的进程实体；后面会说到，其实创建的过程是fork，意为从父进程“copy”出一个新的进程。此过程必定经历启动者、ams、zygote等相互的进程间通信，本文主要梳理ams在此过程的重要环节，涉及虚拟机的继承、Binder线程池、消息循环是怎么建立的等等，而Activity的启动细节则放在其他章节另作探讨。
步骤
step1 Ams发起请求startProcessLocked
ActivityManagerService.java
直接从Ams中向zygote发起请求的入口开始分析，当然真正的开始是Ams收到其他应用的Binder请求，所以应该在onTransact里面才是真正的开始，待会儿会打出trace看。（这儿一个小细节，源码中有很多方法带Locked后缀，说明使用该方法需要加锁，因为其是非线程安全的）。
// Start the process. It will either succeed and return a result containing
// the PID of the new process, or else throw a RuntimeException.
boolean isActivityProcess = (entryPoint == null);
if (entryPoint == null) entryPoint = "android.app.ActivityThread";
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "Start proc: " +
app.processName);
checkTime(startTime, "startProcess: asking zygote to start proc");
Process.ProcessStartResult startResult = Process.start(entryPoint,
app.processName, uid, uid, gids, debugFlags, mountExternal,
app.info.targetSdkVersion, app.info.seinfo, requiredAbi, instructionSet,
app.info.dataDir, entryPointArgs);
checkTime(startTime, "startProcess: returned from zygote!");
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
比较重要的是这一段话，调用Process类的start方法，并指定了入口类为ActivityThread。
system 671 641 2348412 179992 0 0000000000 S Binder:641_1
641-671/system_process W: at android.os.Process.zygoteSendArgsAndGetResult(Process.java:605)
641-671/system_process W: at android.os.Process.startViaZygote(Process.java:738)
641-671/system_process W: at android.os.Process.start(Process.java:521)
641-671/system_process W: at com.android.server.am.ActivityManagerService.startProcessLocked(ActivityManagerService.java:4214)
641-671/system_process W: at com.android.server.am.ActivityManagerService.startProcessLocked(ActivityManagerService.java:4069)
641-671/system_process W: at com.android.server.am.ActivityManagerService.startProcessLocked(ActivityManagerService.java:3909)
641-671/system_process W: at com.android.server.am.ActivityStackSupervisor.startSpecificActivityLocked(ActivityStackSupervisor.java:1441)
641-671/system_process W: at com.android.server.am.ActivityStack.resumeTopActivityInnerLocked(ActivityStack.java:2741)
641-671/system_process W: at com.android.server.am.ActivityStack.resumeTopActivityUncheckedLocked(ActivityStack.java:2213)
641-671/system_process W: at com.android.server.am.ActivityStackSupervisor.resumeFocusedStackTopActivityLocked(ActivityStackSupervisor.java:1859)
641-671/system_process W: at com.android.server.am.ActivityStack.completePauseLocked(ActivityStack.java:1393)
641-671/system_process W: at com.android.server.am.ActivityStack.activityPausedLocked(ActivityStack.java:1237)
641-671/system_process W: at com.android.server.am.ActivityManagerService.activityPaused(ActivityManagerService.java:7393)
641-671/system_process W: at android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:571)
641-671/system_process W: at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:3169)
641-671/system_process W: at android.os.Binder.execTransact(Binder.java:565)
从如上的trace可以直接看出，在收到startActivity的请求后，执行了对当前Activity的pause操作，然后通过Process.java这个类对Zygote进程发起请求。注意，通过对线程号的观察可以看到，这一切都在一次binder线程中操作的。
注意Ams与Zygote之间是通过socket连接的，封装了zygoteState类去做通信相关的任务。从下图fd的占用可以明确地看到，zygote进程是不使用binder的。
device:/proc/341/fd # ls -l
ls -l
total 0
lrwx------ 1 root root 64 2021-03-16 17:49 0 -> /dev/null
lrwx------ 1 root root 64 2021-03-16 17:49 1 -> /dev/null
lr-x------ 1 root root 64 2021-03-16 17:49 10 -> /system/framework/core-oj.jar
lr-x------ 1 root root 64 2021-03-16 17:49 11 -> /system/framework/core-libart.jar
lr-x------ 1 root root 64 2021-03-16 17:49 12 -> /system/framework/conscrypt.jar
lr-x------ 1 root root 64 2021-03-16 17:49 13 -> /system/framework/okhttp.jar
lr-x------ 1 root root 64 2021-03-16 17:49 14 -> /system/framework/core-junit.jar
lr-x------ 1 root root 64 2021-03-16 17:49 15 -> /system/framework/bouncycastle.jar
lr-x------ 1 root root 64 2021-03-16 17:49 16 -> /system/framework/ext.jar
lr-x------ 1 root root 64 2021-03-16 17:49 17 -> /system/framework/framework.jar
lr-x------ 1 root root 64 2021-03-16 17:49 18 -> /system/framework/telephony-common.jar
lr-x------ 1 root root 64 2021-03-16 17:49 19 -> /system/framework/voip-common.jar
lrwx------ 1 root root 64 2021-03-16 17:49 2 -> /dev/null
lr-x------ 1 root root 64 2021-03-16 17:49 20 -> /system/framework/ims-common.jar
lr-x------ 1 root root 64 2021-03-16 17:49 21 -> /system/framework/apache-xml.jar
lr-x------ 1 root root 64 2021-03-16 17:49 22 -> /system/framework/org.apache.http.legacy.boot.jar
lrwx------ 1 root root 64 2021-03-16 17:49 23 -> socket:[9842]
lr-x------ 1 root root 64 2021-03-16 17:49 24 -> /system/framework/framework-res.apk
lr-x------ 1 root root 64 2021-03-16 17:49 25 -> /dev/urandom
l-wx------ 1 root root 64 2021-03-16 17:49 5 -> /sys/kernel/debug/tracing/trace_marker
lrwx------ 1 root root 64 2021-03-16 17:49 6 -> /dev/null
lrwx------ 1 root root 64 2021-03-16 17:49 7 -> /dev/null
lrwx------ 1 root root 64 2021-03-16 17:49 8 -> /dev/null
lrwx------ 1 root root 64 2021-03-16 17:49 9 -> socket:[9289]
Ams的调用栈到上面就截止了，接下来进入到Zygote进程中。
step2 Zygote收到请求
猜想Zygote进程初始化完成后，一定有个无限循环在等待其他进程的请求，直接定位到代码。
private static void runSelectLoop(String abiList) throws MethodAndArgsCaller {
ArrayList<FileDescriptor> fds = new ArrayList<FileDescriptor>();
ArrayList<ZygoteConnection> peers = new ArrayList<ZygoteConnection>();
fds.add(sServerSocket.getFileDescriptor());
peers.add(null);
while (true) {
StructPollfd[] pollFds = new StructPollfd[fds.size()];
for (int i = 0; i < pollFds.length; ++i) {
pollFds[i] = new StructPollfd();
pollFds[i].fd = fds.get(i);
pollFds[i].events = (short) POLLIN;
}
try {
Os.poll(pollFds, -1);
} catch (ErrnoException ex) {
throw new RuntimeException("poll failed", ex);
}
for (int i = pollFds.length - 1; i >= 0; --i) {
if ((pollFds[i].revents & POLLIN) == 0) {
continue;
}
if (i == 0) {
ZygoteConnection newPeer = acceptCommandPeer(abiList);
peers.add(newPeer);
fds.add(newPeer.getFileDesciptor());
} else {
boolean done = peers.get(i).runOnce();
if (done) {
peers.remove(i);
fds.remove(i);
}
}
}
}
}
可以看到，当接收到请求后，调用ZygoteConnection类的runOnce来处理。
boolean runOnce() throws ZygoteInit.MethodAndArgsCaller {
.......省略代码
pid = Zygote.forkAndSpecialize(parsedArgs.uid, parsedArgs.gid, parsedArgs.gids,
parsedArgs.debugFlags, rlimits, parsedArgs.mountExternal, parsedArgs.seInfo,
parsedArgs.niceName, fdsToClose, parsedArgs.instructionSet,
parsedArgs.appDataDir);
......省略代码
try {
/*子进程执行pid＝＝0情况，父进程执行else情况*/
if (pid == 0) {
/*子进程*/
// in child
IoUtils.closeQuietly(serverPipeFd);
serverPipeFd = null;
handleChildProc(parsedArgs, descriptors, childPipeFd, newStderr);
// should never get here, the child is expected to either
// throw ZygoteInit.MethodAndArgsCaller or exec().
return true;
} else {
// in parent...pid of < 0 means failure
IoUtils.closeQuietly(childPipeFd);
childPipeFd = null;
/*Process中的io流监听的pid等信息都是通过下面的代码发出去的*/
return handleParentProc(pid, descriptors, serverPipeFd, parsedArgs);
}
} finally {
IoUtils.closeQuietly(childPipeFd);
IoUtils.closeQuietly(serverPipeFd);
}
}
主要玄机是forkAndSpecialize这个方法，能fork出native的子进程，然后再返回到调用的地方；但是会返回两次，一次是子进程，一次是父进程，这个通过返回值来判断，和linux的fork方法类似；如果是子进程，那么执行handleChildProc，注意下面的注释，意味着不会执行到return的语句，也就是上层的selectloop（因为子进程不用管zygote的接受命令循环了，直接去执行app进程的任务了）；而父进程会调用handleParentProc后返回。
子进程的返回有个小技巧，是通过抛一个异常达到的，那么回到了哪里？我们再看一下ZygoteInit.java的main方法。
public static void main(String argv[]) {
// Mark zygote start. This ensures that thread creation will throw
// an error.
...
try {
Trace.traceBegin(Trace.TRACE_TAG_DALVIK, "ZygoteInit");
RuntimeInit.enableDdms();
// Start profiling the zygote initialization.
SamplingProfilerIntegration.start();
registerZygoteSocket(socketName);
preload();
gcAndFinalize();
// Zygote process unmounts root storage spaces.
Zygote.nativeUnmountStorageOnInit();
...
Log.i(TAG, "Accepting command socket connections");
/*这儿调用的runSelectLoop开启等待循环的*/
runSelectLoop(abiList);
closeServerSocket();
} catch (MethodAndArgsCaller caller) {
caller.run();
} catch (Throwable ex) {
Log.e(TAG, "Zygote died with exception", ex);
closeServerSocket();
throw ex;
}
}
是不是看到了熟悉的身影runSelectLoop，所以是Zygote进入java世界后，先进入main方法做了一些准备工作，然后开启selectLoop进行等待循环，而收到子进程抛出的MethodAndArgsCaller异常后会执行caller.run,这是我们能从调用栈中看到子进程生命的开始，之所以这样做，还可以通过抛异常的方式清空之前的调用栈，去除一些fork、设置等，看起来app的生命更清爽。如下图到onCreate的流程。
3199-3199/com.android.myapplication W: at com.android.myapplication.MainActivity.onCreate(MainActivity.java:42)
3199-3199/com.android.myapplication W: at android.app.Activity.performCreate(Activity.java:6709)
3199-3199/com.android.myapplication W: at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1118)
3199-3199/com.android.myapplication W: at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2624)
3199-3199/com.android.myapplication W: at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2732)
3199-3199/com.android.myapplication W: at android.app.ActivityThread.-wrap12(ActivityThread.java)
3199-3199/com.android.myapplication W: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1483)
3199-3199/com.android.myapplication W: at android.os.Handler.dispatchMessage(Handler.java:102)
3199-3199/com.android.myapplication W: at android.os.Looper.loop(Looper.java:154)
3199-3199/com.android.myapplication W: at android.app.ActivityThread.main(ActivityThread.java:6141)
3199-3199/com.android.myapplication W: at java.lang.reflect.Method.invoke(Native Method)
3199-3199/com.android.myapplication W: at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:912)
3199-3199/com.android.myapplication W: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:802)
哈哈，扯远了，继续看一下刚才子进程调用的handleChildProc到底做了什么事儿。
step3 handleChildProc — 进入子进程的世界
.frameworks/base/core/java/com/android/internal/os/ZygoteConnection.java
按照惯例，先看调用栈。
private void handleChildProc(Arguments parsedArgs,
FileDescriptor[] descriptors, FileDescriptor pipeFd, PrintStream newStderr)
throws ZygoteInit.MethodAndArgsCaller {
closeSocket();
ZygoteInit.closeServerSocket();
if (descriptors != null) {
try {
Os.dup2(descriptors[0], STDIN_FILENO);
Os.dup2(descriptors[1], STDOUT_FILENO);
Os.dup2(descriptors[2], STDERR_FILENO);
for (FileDescriptor fd: descriptors) {
IoUtils.closeQuietly(fd);
}
newStderr = System.err;
} catch (ErrnoException ex) {
Log.e(TAG, "Error reopening stdio", ex);
}
}
......省略代码
if (parsedArgs.runtimeInit) {
if (parsedArgs.invokeWith != null) {
WrapperInit.execApplication(parsedArgs.invokeWith,
parsedArgs.niceName, parsedArgs.targetSdkVersion,
pipeFd, parsedArgs.remainingArgs);
} else {
RuntimeInit.zygoteInit(parsedArgs.targetSdkVersion,
parsedArgs.remainingArgs, null /* classLoader */);
}
} else {
......省略代码
}
}
一开始进来有一些资源回收的工作，比如关闭socket等，因为子进程用不到了，避免占用fd。dup2那三个操作是把原来的标准输入、标准输出和错误输出（fd分别为0、1、2）用参数传来的descriptors代替，实际上传来的就是“/dev/null”，可以随便进入一个app的fd可以看到0、1、2一定是/dev/null。接下来，Ams传来的参数中有“–runtime-init”并且invokeWith的是ActivityThead，然后执行RuntimeInit.zygoteInit这个方法。
step4 RuntimeInit.zygoteInit — 子进程环境准备
先看代码
public static final void zygoteInit(int targetSdkVersion, String[] argv, ClassLoader classLoader)
throws ZygoteInit.MethodAndArgsCaller {
if (DEBUG) Slog.d(TAG, "RuntimeInit: Starting application from zygote");
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "RuntimeInit");
redirectLogStreams();
/*设置时区、log、http代理等一些信息*/
commonInit();
nativeZygoteInit();
applicationInit(targetSdkVersion, argv, classLoader);
}
commonInit是一些通用的初始化，不用去深究，下面重点看一下nativeZygoteInit（比较重要的方法一般都是放在native去干的）和applicationInit。
nativeZygoteInit
通过一系列继承、重写的技巧，总之最后调用到了app_main.cpp中
.frameworks/base/cmds/app_process/app_main.cpp
virtual void onZygoteInit()
{
sp<ProcessState> proc = ProcessState::self();
ALOGV("App process: starting thread pool.\n");
proc->startThreadPool();
}
如果你熟悉native binder进程的写法的话，对这两句话一定不陌生，又看到了熟悉的套路。这两句话在app启动之前帮忙打开了/dev/binder，同时启动了binder线程池。之后app在使用binder时就不用关心binder驱动以及线程池相关的事儿了。
applicationInit
private static void invokeStaticMain(String className, String[] argv, ClassLoader classLoader)
throws ZygoteInit.MethodAndArgsCaller {
Class<?> cl;
try {
cl = Class.forName(className, true, classLoader);
} catch (ClassNotFoundException ex) {
throw new RuntimeException(
"Missing class when invoking static main " + className,
ex);
}
Method m;
try {
m = cl.getMethod("main", new Class[] { String[].class });
} catch (NoSuchMethodException ex) {
throw new RuntimeException(
"Missing static main on " + className, ex);
} catch (SecurityException ex) {
throw new RuntimeException(
"Problem getting static main on " + className, ex);
}
int modifiers = m.getModifiers();
if (! (Modifier.isStatic(modifiers) && Modifier.isPublic(modifiers))) {
throw new RuntimeException(
"Main method is not public and static on " + className);
}
/*
* This throw gets caught in ZygoteInit.main(), which responds
* by invoking the exception's run() method. This arrangement
* clears up all the stack frames that were required in setting
* up the process.
*/
throw new ZygoteInit.MethodAndArgsCaller(m, argv);
}
程序比较简单，主要是通过反射的方式找到ActivityThread的main方法，并且抛出异常把该方法作为参数传递到zygote的main方法中去（前面讲了zygote的main方法除了开启selectLoop还捕获了MethodAndArgsCaller这个异常）。
/**
* Helper exception class which holds a method and arguments and
* can call them. This is used as part of a trampoline to get rid of
* the initial process setup stack frames.
*/
public static class MethodAndArgsCaller extends Exception
implements Runnable {
/** method to call */
private final Method mMethod;
/** argument array */
private final String[] mArgs;
public MethodAndArgsCaller(Method method, String[] args) {
mMethod = method;
mArgs = args;
}
public void run() {
try {
mMethod.invoke(null, new Object[] { mArgs });
} catch (IllegalAccessException ex) {
throw new RuntimeException(ex);
} catch (InvocationTargetException ex) {
Throwable cause = ex.getCause();
if (cause instanceof RuntimeException) {
throw (RuntimeException) cause;
} else if (cause instanceof Error) {
throw (Error) cause;
}
throw new RuntimeException(ex);
}
}
}
MethodAndArgsCaller的run方法很简单，其实就是去执行ActivityThread的main方法。现在我们来捋一下，zygote饶了这么大一圈，就是为了fork出子进程，做一些binder线程池等的准备工作，最后执行ActivityThread的main方法。
通过调用栈来总结一下子进程创建生命的过程
1896-1896/com.android.myapplication W: at com.android.internal.os.RuntimeInit.invokeStaticMain(RuntimeInit.java:237)
1896-1896/com.android.myapplication W: at com.android.internal.os.RuntimeInit.applicationInit(RuntimeInit.java:338)
1896-1896/com.android.myapplication W: at com.android.internal.os.RuntimeInit.zygoteInit(RuntimeInit.java:290)
1896-1896/com.android.myapplication W: at com.android.internal.os.ZygoteConnection.handleChildProc(ZygoteConnection.java:757)
1896-1896/com.android.myapplication W: at com.android.internal.os.ZygoteConnection.runOnce(ZygoteConnection.java:243)
1896-1896/com.android.myapplication W: at com.android.internal.os.ZygoteInit.runSelectLoop(ZygoteInit.java:876)
1896-1896/com.android.myapplication W: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:798)
注意虽然看pid这是子进程的pid号，但是继承了父进程的调用栈，从handleChildProc开始是子进程，之前是父进程zygote。
step5 ActivityThread — app的入口
.frameworks/base/core/java/android/app/ActivityThread.java
这次我们主要看一下ActivityThread的静态main方法，因为整个文件有6000多行，关系到Activity实例的各种生命周期和管理、以及viewroot的创建等等。
public static void main(String[] args) {
...
Looper.prepareMainLooper();
ActivityThread thread = new ActivityThread();
thread.attach(false);
if (sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler();
}
// End of event ActivityThreadMain.
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
主要是调用Looper的静态方法创建消息循环，然后创建ActivityThread实例，最后进入到消息循环中。
总结
通过本文大致理了从Ams开始创建一个app进程的大致流程，如果以执行的进程实体来看，其实主要分三个部分，一个是ams中，一个是zygote父进程中，一个是子进程中。有了这个大致的脉络，再根据调用栈来看，实际还是比较清晰的。ams负责接收binder请求并与zygote联系，zygote父进程收到socket消息后去fork出子进程，子进程负责准备好binder环境和消息循环，然后开始Activity的生命周期。
开心洋葱 , 版权所有丨如未注明 , 均为原创丨未经授权请勿修改 , 转载请注明Android应用程序的进程创建过程！
