Android应用程序的进程创建过程

目录

• 前言
• 步骤
  • 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的生命周期。