相关文章：

Android进阶宝典 — 史上最详细Android体系发动全流程剖析

在上一篇文章中，我详细介绍了Android体系的发动流程，当Zygote进程创立之后，就会经过体系fork能力创立system_server进程，这个时分就会进入App进程时间，那么首要咱们先看下，体系fork函数是怎么创立进程的。

1 体系fork进程剖析

咱们知道，Zygote进程创立的第一个进程便是system_server进程，这个进程的首要作用便是办理服务，例如咱们常见的AMS、WMS、PMS等，一起为App进程供给服务支持。

1.1 fork函数剖析

这儿咱们拿forkSystemServer办法对应的JNI函数进行剖析，在上一节中已经剖析了会调用ForkCommon函数进行进程创立，咱们看在这个办法中，调用了fork函数。

static pid_t ForkCommon(JNIEnv* env, bool is_system_server,
                        const std::vector<int>& fds_to_close,
                        const std::vector<int>& fds_to_ignore) {
  SetSignalHandlers();
  // Curry a failure function.
  auto fail_fn = std::bind(ZygoteFailure, env, is_system_server ? "system_server" : "zygote",
                           nullptr, _1);
  // Temporarily block SIGCHLD during forks. The SIGCHLD handler might
  // log, which would result in the logging FDs we close being reopened.
  // This would cause failures because the FDs are not whitelisted.
  //
  // Note that the zygote process is single threaded at this point.
  BlockSignal(SIGCHLD, fail_fn);
  // Close any logging related FDs before we start evaluating the list of
  // file descriptors.
  __android_log_close();
  stats_log_close();
  // If this is the first fork for this zygote, create the open FD table.  If
  // it isn't, we just need to check whether the list of open files has changed
  // (and it shouldn't in the normal case).
  if (gOpenFdTable == nullptr) {
    gOpenFdTable = FileDescriptorTable::Create(fds_to_ignore, fail_fn);
  } else {
    gOpenFdTable->Restat(fds_to_ignore, fail_fn);
  }
  android_fdsan_error_level fdsan_error_level = android_fdsan_get_error_level();
  //调用fork函数，创立进程
  pid_t pid = fork();
  if (pid == 0) {
    // The child process.
    PreApplicationInit();
    // Clean up any descriptors which must be closed immediately
    DetachDescriptors(env, fds_to_close, fail_fn);
    // Invalidate the entries in the USAP table.
    ClearUsapTable();
    // Re-open all remaining open file descriptors so that they aren't shared
    // with the zygote across a fork.
    gOpenFdTable->ReopenOrDetach(fail_fn);
    // Turn fdsan back on.
    android_fdsan_set_error_level(fdsan_error_level);
  } else {
    ALOGD("Forked child process %d", pid);
  }
  // We blocked SIGCHLD prior to a fork, we unblock it here.
  UnblockSignal(SIGCHLD, fail_fn);
  return pid;
}

fork函数终究回来了一个pid，在这儿会对pid判别，这儿同伴们需求留意，虽然fork只会履行一次，可是在回来值上会有两次回来，这是什么原因呢？

由于咱们在fork进程的时分，咱们会在父进程中履行fork函数，一起会将父进程的信息全部复制一份，包含仓库信息，也便是代码会在子进程中再次履行一次，所以从现象上来看，在forkSystemServer办法履行时，会有两次回来，一次是从父进程回来，一次从子进程中回来，那么怎么判别是在哪个进程呢？

在ForkCommon函数中给了咱们答案，当pid = 0时，由于在子进程中没有创立进程，因而回来0；而在父进程中则是会回来创立的子进程pid；假如回来一个负值，那么阐明创立进程失利了。

ZygoteInit # forkSystemServer
/* For child process */
if (pid == 0) {
    if (hasSecondZygote(abiList)) {
        waitForSecondaryZygote(socketName);
    }
    zygoteServer.closeServerSocket();
    return handleSystemServerProcess(parsedArgs);
}

因而，在ZygoteInit调用forkSystemServer之后，会判别其回来值，假如pid = 0，那么就阐明创立进程成功了，并且是子进程，那么就会履行handleSystemServerProcess办法，此刻运行在system_server进程。

1.2 system_server进程发动流程

private static Runnable handleSystemServerProcess(ZygoteArguments parsedArgs) {
    //......
    if (parsedArgs.mInvokeWith != null) {
        String[] args = parsedArgs.mRemainingArgs;
        // If we have a non-null system server class path, we'll have to duplicate the
        // existing arguments and append the classpath to it. ART will handle the classpath
        // correctly when we exec a new process.
        if (systemServerClasspath != null) {
            String[] amendedArgs = new String[args.length + 2];
            amendedArgs[0] = "-cp";
            amendedArgs[1] = systemServerClasspath;
            System.arraycopy(args, 0, amendedArgs, 2, args.length);
            args = amendedArgs;
        }
        WrapperInit.execApplication(parsedArgs.mInvokeWith,
                parsedArgs.mNiceName, parsedArgs.mTargetSdkVersion,
                VMRuntime.getCurrentInstructionSet(), null, args);
        throw new IllegalStateException("Unexpected return from WrapperInit.execApplication");
    } else {
        ClassLoader cl = getOrCreateSystemServerClassLoader();
        if (cl != null) {
            Thread.currentThread().setContextClassLoader(cl);
        }
        /*
         * Pass the remaining arguments to SystemServer.
         */
        return ZygoteInit.zygoteInit(parsedArgs.mTargetSdkVersion,
                parsedArgs.mDisabledCompatChanges,
                parsedArgs.mRemainingArgs, cl);
    }
    /* should never reach here */
}

详细调用链会履行ZygoteInit的zygoteInit办法，在这个办法中，又会履行RuntimeInit的applicationInit办法。

public static Runnable zygoteInit(int targetSdkVersion, long[] disabledCompatChanges,
        String[] argv, ClassLoader classLoader) {
    if (RuntimeInit.DEBUG) {
        Slog.d(RuntimeInit.TAG, "RuntimeInit: Starting application from zygote");
    }
    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "ZygoteInit");
    RuntimeInit.redirectLogStreams();
    RuntimeInit.commonInit();
    ZygoteInit.nativeZygoteInit();
    return RuntimeInit.applicationInit(targetSdkVersion, disabledCompatChanges, argv,
            classLoader);
}

在看applicationInit办法之前，首要先看一下ZygoteInit中的nativeZygoteInit，这个办法比较重要，咱们跟进看一下。

private static native void nativeZygoteInit();

这是一个native办法，咱们看下C++的代码

int register_com_android_internal_os_ZygoteInit_nativeZygoteInit(JNIEnv* env)
{
    const JNINativeMethod methods[] = {
        { "nativeZygoteInit", "()V",
            (void*) com_android_internal_os_ZygoteInit_nativeZygoteInit },
    };
    return jniRegisterNativeMethods(env, "com/android/internal/os/ZygoteInit",
        methods, NELEM(methods));
}

static void com_android_internal_os_ZygoteInit_nativeZygoteInit(JNIEnv* env, jobject clazz)
{
    gCurRuntime->onZygoteInit();
}s

终究履行的是AndroidRuntime的onZygoteInit函数。

virtual void onZygoteInit()
{
    sp<ProcessState> proc = ProcessState::self();
    ALOGV("App process: starting thread pool.\n");
    proc->startThreadPool();
}

假如有了解Binder源码的同伴，这儿其实便是会创立Binder驱动并发动Binder线程池，所以这儿就有一个面试题，Binder驱动是什么时分发动的？其实便是在fork进程成功之后，处理进程发动的时分完结的，详细函数便是在ZygoteInit的nativeZygoteInit办法。

protected static Runnable applicationInit(int targetSdkVersion, long[] disabledCompatChanges,
        String[] argv, ClassLoader classLoader) {
    // If the application calls System.exit(), terminate the process
    // immediately without running any shutdown hooks.  It is not possible to
    // shutdown an Android application gracefully.  Among other things, the
    // Android runtime shutdown hooks close the Binder driver, which can cause
    // leftover running threads to crash before the process actually exits.
    nativeSetExitWithoutCleanup(true);
    VMRuntime.getRuntime().setTargetSdkVersion(targetSdkVersion);
    VMRuntime.getRuntime().setDisabledCompatChanges(disabledCompatChanges);
    final Arguments args = new Arguments(argv);
    // The end of of the RuntimeInit event (see #zygoteInit).
    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
    // Remaining arguments are passed to the start class's static main
    return findStaticMain(args.startClass, args.startArgs, classLoader);
}

这个办法终究履行findStaticMain办法，这个办法的其实很简略，便是经过反射的办法去查找对应的className的main办法，像咱们现在是发动system_server进程，所以查找的便是system_server的main办法，终究去履行对应的main办法，这样system_server进程就已经发动了。

public static void main(String[] args) {
    new SystemServer().run();
}

咱们能够看到，SystemServer的main办法，便是创立一个SystemServer目标并履行其run办法。

1.2.1 SystemServer run办法剖析

private void run() {
    TimingsTraceAndSlog t = new TimingsTraceAndSlog();
    try {
        //发动服务之前的初始化操作
        t.traceBegin("InitBeforeStartServices");
        // ......
        // Ensure binder calls into the system always run at foreground priority.
        BinderInternal.disableBackgroundScheduling(true);
        // Increase the number of binder threads in system_server
        BinderInternal.setMaxThreads(sMaxBinderThreads);
        // Prepare the main looper thread (this thread).
        android.os.Process.setThreadPriority(
                android.os.Process.THREAD_PRIORITY_FOREGROUND);
        android.os.Process.setCanSelfBackground(false);
        Looper.prepareMainLooper();
        Looper.getMainLooper().setSlowLogThresholdMs(
                SLOW_DISPATCH_THRESHOLD_MS, SLOW_DELIVERY_THRESHOLD_MS);
        // Initialize native services.
        System.loadLibrary("android_servers");
        // Allow heap / perf profiling.
        initZygoteChildHeapProfiling();
        // Debug builds - spawn a thread to monitor for fd leaks.
        if (Build.IS_DEBUGGABLE) {
            spawnFdLeakCheckThread();
        }
        // Check whether we failed to shut down last time we tried.
        // This call may not return.
        performPendingShutdown();
        // Initialize the system context.
        createSystemContext();
        // ......
        // Create the system service manager.
        mSystemServiceManager = new SystemServiceManager(mSystemContext);
        mSystemServiceManager.setStartInfo(mRuntimeRestart,
                mRuntimeStartElapsedTime, mRuntimeStartUptime);
        mDumper.addDumpable(mSystemServiceManager);
        // ......
    } finally {
        t.traceEnd();  // InitBeforeStartServices
    }
    // Start services.
    try {
        t.traceBegin("StartServices");
        startBootstrapServices(t);
        startCoreServices(t);
        startOtherServices(t);
    } catch (Throwable ex) {
        Slog.e("System", "******************************************");
        Slog.e("System", "************ Failure starting system services", ex);
        throw ex;
    } finally {
        t.traceEnd(); // StartServices
    }
    //......
    // Loop forever.
    Looper.loop();
    throw new RuntimeException("Main thread loop unexpectedly exited");
}

在system_server的run办法中

• 咱们看到有创立Looper目标，由于作为一个进程，首要不会履行完结之后马上完毕，包含前面在剖析idle、init、zygote进程时，都是创立死循环处理音讯，所以system_server也是如此。

• 再往下看，咱们看到履行了createSystemContext办法，看注释是创立了体系的上下文。

private void createSystemContext() {
    ActivityThread activityThread = ActivityThread.systemMain();
    mSystemContext = activityThread.getSystemContext();
    mSystemContext.setTheme(DEFAULT_SYSTEM_THEME);
    final Context systemUiContext = activityThread.getSystemUiContext();
    systemUiContext.setTheme(DEFAULT_SYSTEM_THEME);
}

• 创立体系的ServiceManager，用来办理体系服务，也便是后续的三个比较重要的办法，都需求运用SystemServiceManager来发动服务。

private void startBootstrapServices(@NonNull TimingsTraceAndSlog t) {
    t.traceBegin("startBootstrapServices");
    // ......
    // Activity manager runs the show.
    t.traceBegin("StartActivityManager");
    // TODO: Might need to move after migration to WM.
    ActivityTaskManagerService atm = mSystemServiceManager.startService(
            ActivityTaskManagerService.Lifecycle.class).getService();
    mActivityManagerService = ActivityManagerService.Lifecycle.startService(
            mSystemServiceManager, atm);
    mActivityManagerService.setSystemServiceManager(mSystemServiceManager);
    mActivityManagerService.setInstaller(installer);
    mWindowManagerGlobalLock = atm.getGlobalLock();
    t.traceEnd();
    // ......
}

这儿我就拿发动AMS来做介绍，其实与startBootstrapServices同级的三个办法内部都是经过SystemServiceManager来发动服务，所以咱们看一下SystemServiceManager的startService办法详细实现：

public void startService(@NonNull final SystemService service) {
    // Register it.
    mServices.add(service);
    // Start it.
    long time = SystemClock.elapsedRealtime();
    try {
        service.onStart();
    } catch (RuntimeException ex) {
        throw new RuntimeException("Failed to start service " + service.getClass().getName()
                + ": onStart threw an exception", ex);
    }
    warnIfTooLong(SystemClock.elapsedRealtime() - time, service, "onStart");
}

其实一切startService终究都会调用这个办法，传值为SystemService目标，其实无论是AMS、WMS仍是其他的体系服务，都是承继SystemService，因而在SystemServiceManager中有一个mServices List来收集这些体系服务，终究发动便是调用SystemService的onStart办法。

/**
 * Called when the system service should publish a binder service using
 * {@link #publishBinderService(String, IBinder).}
 */
public abstract void onStart();

咱们看下SystemService关于onStart办法的定义，当调用这个办法的时分，会调用publishBinderService将其注册binder service中。

protected final void publishBinderService(String name, IBinder service,
        boolean allowIsolated, int dumpPriority) {
    ServiceManager.addService(name, service, allowIsolated, dumpPriority);
}

假如了解Binder进程间通讯的同伴，咱们通常喜爱叫ServiceManager为大管家，是由于ServiceManager归于Binder中用于办理各类服务的目标，尤其是触及到跨进程通讯。

所以这儿有几个目标，咱们需求分清楚一些：

• SystemServer：Zygote fork出来的一个进程，首要用来办理各类服务；
• SystemService：一切体系服务的父类，例如AMS、WMS、PKMS等都是这个大类的子类；
• SystemServiceManager：归于SystemServer进程，在SystemServer进程发动时创立，SystemServer真实用于办理服务的类，其间startService办法用于发动服务；
• ServiceManager：体系服务大管家，用于跨进程通讯，例如app进程想要与AMS通讯，那么就需求经过ServerManager来完结进程间通讯。

如此一来，SystemServer进程也就发动完结了。

2 AMS责任剖析

前面关于SystemServer的发动流程剖析中，咱们知道会发动AMS服务，其实在Android10之前，AMS是会办理Activity、Service、广播、Provider四大组件的发动，可是由于责任太多，在Android10之后，专门运用ActivityTaskManagerService（ATMS）来办理Activity的发动。

2.1 App发动流程剖析

假如有做过Launcher的同伴，应该理解当咱们点击一个APP ICON的时分，就会发动一个app，这时APP的发动办法有许多，例如经过包名发动、经过scheme发动，那么从点击ICON到APP展现主页，这个进程是怎么完结的呢？这儿AMS就起到作用了。

由于当咱们发动一个app的时分，无论是经过包名仍是scheme，都是发动的Activity；例如咱们经过包名发动，那么就会发动在Manifest清单文件中，标注android.intent.category.LAUNCHER的Activity；

<activity
    android:name=".MainActivity"
    android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

假如是经过scheme发动，那么也是发动标注这个scheme的Activity，所以当app发动的时分，也是发动Activity，所以终究咱们仍是持续剖析Activity的发动流程，可是关于app进程是怎么创立的，咱们首要需求了解其间的原理。

2.1.1 app进程创立

经过前面的剖析，咱们知道app发动其实也是Activity的发动，所以必定触及到ATMS的责任，所以当发动一个app（Activity）的时分，system_server进程首要会判别当时要发动的这个进程是否存在，假如不存在，那么就需求告诉Zygote进程去fork app进程。

所以这儿就触及到了system_server进程与Zygote进程间通讯，咱们知道当Zygote进程初始化的时分，创立了ZygoteServer目标，也便是socket，所以system_server经过socket发送音讯告诉Zygote去fork app进程。

ATMS # startProcessAsync

void startProcessAsync(ActivityRecord activity, boolean knownToBeDead, boolean isTop,
        String hostingType) {
    try {
        if (Trace.isTagEnabled(TRACE_TAG_WINDOW_MANAGER)) {
            Trace.traceBegin(TRACE_TAG_WINDOW_MANAGER, "dispatchingStartProcess:"
                    + activity.processName);
        }
        // Post message to start process to avoid possible deadlock of calling into AMS with the
        // ATMS lock held.
        final Message m = PooledLambda.obtainMessage(ActivityManagerInternal::startProcess,
                mAmInternal, activity.processName, activity.info.applicationInfo, knownToBeDead,
                isTop, hostingType, activity.intent.getComponent());
        mH.sendMessage(m);
    } finally {
        Trace.traceEnd(TRACE_TAG_WINDOW_MANAGER);
    }
}

在这个办法中，咱们看到是调用ActivityManagerInternal # startProcess办法，这个便是真实去发动app进程的办法，咱们跟进看一下，详细怎么发送socket音讯的。

AMS # LocalService #startProcess

@Override
public void startProcess(String processName, ApplicationInfo info, boolean knownToBeDead,
        boolean isTop, String hostingType, ComponentName hostingName) {
    try {
        if (Trace.isTagEnabled(Trace.TRACE_TAG_ACTIVITY_MANAGER)) {
            Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "startProcess:"
                    + processName);
        }
        synchronized (ActivityManagerService.this) {
            // If the process is known as top app, set a hint so when the process is
            // started, the top priority can be applied immediately to avoid cpu being
            // preempted by other processes before attaching the process of top app.
            startProcessLocked(processName, info, knownToBeDead, 0 /* intentFlags */,
                    new HostingRecord(hostingType, hostingName, isTop),
                    ZYGOTE_POLICY_FLAG_LATENCY_SENSITIVE, false /* allowWhileBooting */,
                    false /* isolated */);
        }
    } finally {
        Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
    }
}

final ProcessRecord startProcessLocked(String processName,
        ApplicationInfo info, boolean knownToBeDead, int intentFlags,
        HostingRecord hostingRecord, int zygotePolicyFlags, boolean allowWhileBooting,
        boolean isolated) {
    return mProcessList.startProcessLocked(processName, info, knownToBeDead, intentFlags,
            hostingRecord, zygotePolicyFlags, allowWhileBooting, isolated, 0 /* isolatedUid */,
            null /* ABI override */, null /* entryPoint */,
            null /* entryPointArgs */, null /* crashHandler */);
}

这儿咱们发现有两个比较重要的目标：ProcessRecord和mProcessList；

• 其间ProcessRecord，顾名思义便是进程的记载类，用来记载这些进程的信息，包含与App进程通讯的IApplicationThread Binder目标；
• mProcessList则是一个列表，由于进程发动需求ATMS来告诉Zygote，因而ATMS需求办理多个进程，因而运用mProcessList用来存储多个ProcessRecord，并且是按照最近运用最少准则（NLU）进行处理，记载各个进程的信息。

所以终究在发动进程的时分，便是调用了mProcessList的startProcessLocked办法，第一个参数便是进程名。终究调用的便是android.os.Process的start办法。

Tools for managing OS processes

关于Process信任同伴们也不会生疏，咱们在杀进程或者获取进程id的时分都会运用到其间的办法，官方给出的解说便是办理体系进程的工具类。

android.os.Process # start

public static ProcessStartResult start(@NonNull final String processClass,
                                       @Nullable final String niceName,
                                       int uid, int gid, @Nullable int[] gids,
                                       int runtimeFlags,
                                       int mountExternal,
                                       int targetSdkVersion,
                                       @Nullable String seInfo,
                                       @NonNull String abi,
                                       @Nullable String instructionSet,
                                       @Nullable String appDataDir,
                                       @Nullable String invokeWith,
                                       @Nullable String packageName,
                                       int zygotePolicyFlags,
                                       boolean isTopApp,
                                       @Nullable long[] disabledCompatChanges,
                                       @Nullable Map<String, Pair<String, Long>>
                                               pkgDataInfoMap,
                                       @Nullable Map<String, Pair<String, Long>>
                                               whitelistedDataInfoMap,
                                       boolean bindMountAppsData,
                                       boolean bindMountAppStorageDirs,
                                       @Nullable String[] zygoteArgs) {
    return ZYGOTE_PROCESS.start(processClass, niceName, uid, gid, gids,
                runtimeFlags, mountExternal, targetSdkVersion, seInfo,
                abi, instructionSet, appDataDir, invokeWith, packageName,
                zygotePolicyFlags, isTopApp, disabledCompatChanges,
                pkgDataInfoMap, whitelistedDataInfoMap, bindMountAppsData,
                bindMountAppStorageDirs, zygoteArgs);
}

咱们看到Process的start办法，终究调用的是ZYGOTE_PROCESS的start办法，那么ZYGOTE_PROCESS是什么呢？

public static final ZygoteProcess ZYGOTE_PROCESS = new ZygoteProcess();

它是一个ZygoteProcess目标，官方解说如下：

Maintains communication state with the zygote processes. This class is responsible for the sockets opened to the zygotes and for starting processes on behalf of the Process class.

首要是用于保持与Zygote进程的通讯，这个类的责任便是翻开Zygote进程的socket并创立进程。

所以走到这儿，就进入到了与Zygote进程进行socket通讯的进程了。在通讯之前，会封装一系列关于进程相关的参数，终究调用attemptZygoteSendArgsAndGetResult办法与Zygote进程进行通讯。

private Process.ProcessStartResult attemptZygoteSendArgsAndGetResult(
        ZygoteState zygoteState, String msgStr) throws ZygoteStartFailedEx {
    try {
        final BufferedWriter zygoteWriter = zygoteState.mZygoteOutputWriter;
        final DataInputStream zygoteInputStream = zygoteState.mZygoteInputStream;
        //进行socket通讯
        zygoteWriter.write(msgStr);
        zygoteWriter.flush();
        // Always read the entire result from the input stream to avoid leaving
        // bytes in the stream for future process starts to accidentally stumble
        // upon.
        Process.ProcessStartResult result = new Process.ProcessStartResult();
        result.pid = zygoteInputStream.readInt();
        result.usingWrapper = zygoteInputStream.readBoolean();
        if (result.pid < 0) {
            throw new ZygoteStartFailedEx("fork() failed");
        }
        return result;
    } catch (IOException ex) {
        zygoteState.close();
        Log.e(LOG_TAG, "IO Exception while communicating with Zygote - "
                + ex.toString());
        throw new ZygoteStartFailedEx(ex);
    }
}

前面咱们 关于Zygote发动流程的剖析，在ZygoteServer创立之后，就会调用runSelectLoop办法进行死循环，当接收到Socket音讯之后，就会处理音讯，终究调用forkAndSpecialize办法来创立一个进程。这儿就与第一末节中介绍的共同，当创立进程之后，会判别fork回来的pid是否为0。

static int forkAndSpecialize(int uid, int gid, int[] gids, int runtimeFlags,
        int[][] rlimits, int mountExternal, String seInfo, String niceName, int[] fdsToClose,
        int[] fdsToIgnore, boolean startChildZygote, String instructionSet, String appDataDir,
        boolean isTopApp, String[] pkgDataInfoList, String[] allowlistedDataInfoList,
        boolean bindMountAppDataDirs, boolean bindMountAppStorageDirs) {
    ZygoteHooks.preFork();
    int pid = nativeForkAndSpecialize(
            uid, gid, gids, runtimeFlags, rlimits, mountExternal, seInfo, niceName, fdsToClose,
            fdsToIgnore, startChildZygote, instructionSet, appDataDir, isTopApp,
            pkgDataInfoList, allowlistedDataInfoList, bindMountAppDataDirs,
            bindMountAppStorageDirs);
    if (pid == 0) {
        // Note that this event ends at the end of handleChildProc,
        Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "PostFork");
        // If no GIDs were specified, don't make any permissions changes based on groups.
        if (gids != null && gids.length > 0) {
            NetworkUtilsInternal.setAllowNetworkingForProcess(containsInetGid(gids));
        }
    }
    // Set the Java Language thread priority to the default value for new apps.
    Thread.currentThread().setPriority(Thread.NORM_PRIORITY);
    ZygoteHooks.postForkCommon();
    return pid;
}

2.1.2 app进程发动流程剖析

前面咱们介绍，在ATMS中经过Socket通讯告诉Zygote创立一个app进程之后，后续app进程发动流程怎么，咱们接着往下看。

当发送指令告诉Zygote创立进程之后，假如创立子进程成功，那么此刻pid == 0，会进入到if代码块中，调用handleChildProc办法。

// Continue using old code for now. TODO: Handle these cases in the other path.
pid = Zygote.forkAndSpecialize(parsedArgs.mUid, parsedArgs.mGid,
        parsedArgs.mGids, parsedArgs.mRuntimeFlags, rlimits,
        parsedArgs.mMountExternal, parsedArgs.mSeInfo, parsedArgs.mNiceName,
        fdsToClose, fdsToIgnore, parsedArgs.mStartChildZygote,
        parsedArgs.mInstructionSet, parsedArgs.mAppDataDir,
        parsedArgs.mIsTopApp, parsedArgs.mPkgDataInfoList,
        parsedArgs.mAllowlistedDataInfoList, parsedArgs.mBindMountAppDataDirs,
        parsedArgs.mBindMountAppStorageDirs);
try {
    if (pid == 0) {
        // in child
        zygoteServer.setForkChild();
        zygoteServer.closeServerSocket();
        IoUtils.closeQuietly(serverPipeFd);
        serverPipeFd = null;
        return handleChildProc(parsedArgs, childPipeFd,
                parsedArgs.mStartChildZygote);
    } else {
        // In the parent. A pid < 0 indicates a failure and will be handled in
        // handleParentProc.
        IoUtils.closeQuietly(childPipeFd);
        childPipeFd = null;
        handleParentProc(pid, serverPipeFd);
        return null;
    }
} finally {
    IoUtils.closeQuietly(childPipeFd);
    IoUtils.closeQuietly(serverPipeFd);
}

ZygoteConnection # handleChildProc

private Runnable handleChildProc(ZygoteArguments parsedArgs,
        FileDescriptor pipeFd, boolean isZygote) {
    /*
     * By the time we get here, the native code has closed the two actual Zygote
     * socket connections, and substituted /dev/null in their place.  The LocalSocket
     * objects still need to be closed properly.
     */
    closeSocket();
    Zygote.setAppProcessName(parsedArgs, TAG);
    // End of the postFork event.
    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
    if (parsedArgs.mInvokeWith != null) {
        WrapperInit.execApplication(parsedArgs.mInvokeWith,
                parsedArgs.mNiceName, parsedArgs.mTargetSdkVersion,
                VMRuntime.getCurrentInstructionSet(),
                pipeFd, parsedArgs.mRemainingArgs);
        // Should not get here.
        throw new IllegalStateException("WrapperInit.execApplication unexpectedly returned");
    } else {
        if (!isZygote) {
            return ZygoteInit.zygoteInit(parsedArgs.mTargetSdkVersion,
                    parsedArgs.mDisabledCompatChanges,
                    parsedArgs.mRemainingArgs, null /* classLoader */);
        } else {
            return ZygoteInit.childZygoteInit(
                    parsedArgs.mRemainingArgs  /* classLoader */);
        }
    }
}

咱们看到终究仍是调用ZygoteInit的zygoteInit办法，这儿咱们能够回到第一末节中，其实终究调用的便是App进程的main办法，也便是ActivityThread的main函数。

这儿先简略总结一下，无论是forkSystemServer仍是fork一般进程，其实终究都是判别pid是否为0，由于这儿决定着进程是否创立成功，假如进程创立成功，才会有后续的流程，调用handlexx办法。

• 调用handleXX办法，终究都是调用ZygoteInit中的zygoteInit办法；
• 在zygoteInit办法中，会调用ZygoteInit的nativeZygoteInit办法，会开启Binder驱动，创立Binder线程池；
• 调用RuntimeInit的applicationInit办法，终究调用的便是某个类的main办法，例如forkSystemServer中，会调用SystemServer的main办法；经过ATMS发动进程，会调用ActivityThread的main办法。

2.1.3 ActivityThead剖析

前面咱们提到了，当Zygote fork出app进程之后，就会调用ActivityThread的main办法，这儿便是进入到咱们了解的App进程发动中了。

public static void main(String[] args) {
    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "ActivityThreadMain");
    // Install selective syscall interception
    AndroidOs.install();
    // CloseGuard defaults to true and can be quite spammy.  We
    // disable it here, but selectively enable it later (via
    // StrictMode) on debug builds, but using DropBox, not logs.
    CloseGuard.setEnabled(false);
    Environment.initForCurrentUser();
    // Make sure TrustedCertificateStore looks in the right place for CA certificates
    final File configDir = Environment.getUserConfigDirectory(UserHandle.myUserId());
    TrustedCertificateStore.setDefaultUserDirectory(configDir);
    // Call per-process mainline module initialization.
    initializeMainlineModules();
    Process.setArgV0("<pre-initialized>");
    Looper.prepareMainLooper();
    // Find the value for {@link #PROC_START_SEQ_IDENT} if provided on the command line.
    // It will be in the format "seq=114"
    long startSeq = 0;
    if (args != null) {
        for (int i = args.length - 1; i >= 0; --i) {
            if (args[i] != null && args[i].startsWith(PROC_START_SEQ_IDENT)) {
                startSeq = Long.parseLong(
                        args[i].substring(PROC_START_SEQ_IDENT.length()));
            }
        }
    }
    ActivityThread thread = new ActivityThread();
    thread.attach(false, startSeq);
    if (sMainThreadHandler == null) {
        sMainThreadHandler = thread.getHandler();
    }
    if (false) {
        Looper.myLooper().setMessageLogging(new
                LogPrinter(Log.DEBUG, "ActivityThread"));
    }
    // End of event ActivityThreadMain.
    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
    Looper.loop();
    throw new RuntimeException("Main thread loop unexpectedly exited");
}

这个办法大家很了解，首要也是创立looper，保证app进程不会退出；其次便是创立了ActivityThread目标，并调用了其间的attach办法。

在attch办法中，有一段中心代码：

final IActivityManager mgr = ActivityManager.getService();
try {
    mgr.attachApplication(mAppThread, startSeq);
} catch (RemoteException ex) {
    throw ex.rethrowFromSystemServer();
}

它会调用IActivityManager（也便是AMS在app进程的署理目标）的attachApplication办法，mAppThread便是ApplicationThread目标，这个归于app进程的署理目标，会丢给AMS运用。

final ApplicationThread mAppThread = new ApplicationThread();

就这样，App进程持有AMS端的署理，AMS端也会持有App进程的署理，双方就能够经过Binder完结进程间的通讯。

其实在App进程中，能够经过ServiceManager来获取AMS的署理目标的，

private static final Singleton<IActivityManager> IActivityManagerSingleton =
        new Singleton<IActivityManager>() {
            @Override
            protected IActivityManager create() {
                final IBinder b = ServiceManager.getService(Context.ACTIVITY_SERVICE);
                final IActivityManager am = IActivityManager.Stub.asInterface(b);
                return am;
            }
        };

经过源码便能够得知，获取AMS的署理目标之后，就能够调用它的办法，例如attachApplication，并且仍是一个接口类，能够经过动态署理的办法Hook AMS相关的办法调用。

ActivityManagerService # attachApplication

@Override
public final void attachApplication(IApplicationThread thread, long startSeq) {
    if (thread == null) {
        throw new SecurityException("Invalid application interface");
    }
    synchronized (this) {
        int callingPid = Binder.getCallingPid();
        final int callingUid = Binder.getCallingUid();
        final long origId = Binder.clearCallingIdentity();
        attachApplicationLocked(thread, callingPid, callingUid, startSeq);
        Binder.restoreCallingIdentity(origId);
    }
}

在这个办法中，终究调用的是attachApplicationLocked办法，在这个办法中，首要作用便是：

• 调用ApplicationThread的bindApplication办法，这儿会经过Handler发送音讯，用于创立和初始化Application目标；

private void handleBindApplication(AppBindData data) {
    // ......
    // probably end up doing the same disk access.
    Application app;
    final StrictMode.ThreadPolicy savedPolicy = StrictMode.allowThreadDiskWrites();
    final StrictMode.ThreadPolicy writesAllowedPolicy = StrictMode.getThreadPolicy();
    try {
        // 创立Application目标，调用Application的attach办法
        app = data.info.makeApplication(data.restrictedBackupMode, null);
        // ......
        // don't bring up providers in restricted mode; they may depend on the
        // app's custom Application class
        if (!data.restrictedBackupMode) {
            if (!ArrayUtils.isEmpty(data.providers)) {
                // 注册 ContentProvicer
                installContentProviders(app, data.providers);
            }
        }
        // Do this after providers, since instrumentation tests generally start their
        // test thread at this point, and we don't want that racing.
        try {
            mInstrumentation.onCreate(data.instrumentationArgs);
        }
        catch (Exception e) {
            throw new RuntimeException(
                "Exception thrown in onCreate() of "
                + data.instrumentationName + ": " + e.toString(), e);
        }
        try {
            // 调用Application的onCreate办法
            mInstrumentation.callApplicationOnCreate(app);
        } catch (Exception e) {
            if (!mInstrumentation.onException(app, e)) {
                throw new RuntimeException(
                  "Unable to create application " + app.getClass().getName()
                  + ": " + e.toString(), e);
            }
        }
    } finally {
        // If the app targets < O-MR1, or doesn't change the thread policy
        // during startup, clobber the policy to maintain behavior of b/36951662
        if (data.appInfo.targetSdkVersion < Build.VERSION_CODES.O_MR1
                || StrictMode.getThreadPolicy().equals(writesAllowedPolicy)) {
            StrictMode.setThreadPolicy(savedPolicy);
        }
    }
    // ......
}

所以调用bindApplication办法，首要分为3步：创立Application目标，调用其attach办法、注册Contentprovider、调用Application的onCreate办法。

所以假如想要在Application的onCreate办法履行之前做一些工作，能够放在Contentprovider中处理，可是会影响发动速度。

• 为ProcessRecord的mThread特点赋值，也就ApplicationThread，用于与App进程通讯。

public void makeActive(IApplicationThread thread, ProcessStatsService tracker) {
    mProfile.onProcessActive(thread, tracker);
    mThread = thread;
    mWindowProcessController.setThread(thread);
}

• 将新创立的ProcessRecord添加到ProcessList中。

final void updateLruProcessLocked(ProcessRecord app, boolean activityChange,
        ProcessRecord client) {
    mProcessList.updateLruProcessLocked(app, activityChange, client);
}

其实在AMS中便是保护了一组ProcessRecord，每个ProcessRecord中都持有这个进程的AppThread Binder目标。

那么到这儿，当Application的onCreate办法履行完结之后，app的进程就已经发动完结了，咱们总结一下：

• 当点击Launcher入口准备发动App时，首要会向AMS建议发动Activity的恳求，此刻AMS会判别当时进程是否存在，假如不存在，那么就会向Zygote进程发送socket音讯，把要创立的进程信息给到Zygote进程；
• Zygote进程解析进程信息参数之后，会fork一个子进程，发动Binder并创立Binder线程池，然后调用ActivityThread的main办法；
• 在ActivityThread的main办法中，创立Looper，并调用ActivityThread的attach办法；
• 在调用ActivityThread的attach办法时，其实会调用到AMS署理目标的attachApplication办法，进入到SystemServer进程中处理；
• 在SystemServer进程中，AMS终究会调用attachApplicationLocked办法，在这个办法中会履行AppThread的bindApplication办法，在这个办法中，会创立Application目标，终究履行Application的onCreate办法；
• 当履行完Application的onCreate办法之后，App进程算是发动了，此刻会对App进程对应的ProcessRecord目标调用makeActive赋值处理，然后将其添加到ProcessList傍边。

这便是AMS创立app进程的全流程，已然App进程已经发动了，那么下面一篇文章将会对Activity的发动流程做详细的剖析