欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

Android?AMS啟動App進程原理分析

 更新時間:2023年05月21日 08:53:54   作者:layz4android  
這篇文章主要介紹了Android?AMS啟動App進程原理,系統(tǒng)fork函數(shù)是如何創(chuàng)建進程,文中有詳細的代碼示例,對大家的學習或工作有一定的幫助,需要的朋友可以參考下

1 系統(tǒng)fork進程分析

我們知道,Zygote進程創(chuàng)建的第一個進程就是system_server進程,這個進程的主要作用就是管理服務,例如我們常見的AMS、WMS、PMS等,同時為App進程提供服務支持。

1.1 fork函數(shù)分析

這里我們拿forkSystemServer方法對應的JNI函數(shù)進行分析,在上一節(jié)中已經(jīng)分析了會調(diào)用ForkCommon函數(shù)進行進程創(chuàng)建,我們看在這個方法中,調(diào)用了fork函數(shù)。

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();
  //調(diào)用fork函數(shù),創(chuàng)建進程
  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函數(shù)最終返回了一個pid,在這里會對pid判斷,這里伙伴們需要注意,雖然fork只會執(zhí)行一次,但是在返回值上會有兩次返回,這是什么原因呢?

因為我們在fork進程的時候,我們會在父進程中執(zhí)行fork函數(shù),同時會將父進程的信息全部拷貝一份,包括堆棧信息,也就是代碼會在子進程中再次執(zhí)行一次,所以從現(xiàn)象上來看,在forkSystemServer方法執(zhí)行時,會有兩次返回,一次是從父進程返回,一次從子進程中返回,那么如何判斷是在哪個進程呢?

在ForkCommon函數(shù)中給了我們答案,當pid = 0時,因為在子進程中沒有創(chuàng)建進程,因此返回0;而在父進程中則是會返回創(chuàng)建的子進程pid;如果返回一個負值,那么說明創(chuàng)建進程失敗了。

ZygoteInit # forkSystemServer

/* For child process */
if (pid == 0) {
    if (hasSecondZygote(abiList)) {
        waitForSecondaryZygote(socketName);
    }

    zygoteServer.closeServerSocket();
    return handleSystemServerProcess(parsedArgs);
}

因此,在ZygoteInit調(diào)用forkSystemServer之后,會判斷其返回值,如果pid = 0,那么就說明創(chuàng)建進程成功了,而且是子進程,那么就會執(zhí)行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 */
}

具體調(diào)用鏈會執(zhí)行ZygoteInit的zygoteInit方法,在這個方法中,又會執(zhí)行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));
}

最終執(zhí)行的是AndroidRuntime的onZygoteInit函數(shù)。

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

如果有熟悉Binder源碼的伙伴,這里其實就是會創(chuàng)建Binder驅(qū)動并啟動Binder線程池,所以這里就有一個面試題,Binder驅(qū)動是什么時候啟動的?其實就是在fork進程成功之后,處理進程啟動的時候完成的,具體函數(shù)就是在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);
}

這個方法最終執(zhí)行findStaticMain方法,這個方法的其實很簡單,就是通過反射的方式去查找對應的className的main方法,像我們現(xiàn)在是啟動system_server進程,所以查找的就是system_server的main方法,最終去執(zhí)行對應的main方法,這樣system_server進程就已經(jīng)啟動了。

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

我們可以看到,SystemServer的main方法,就是創(chuàng)建一個SystemServer對象并執(zhí)行其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方法中

  • 我們看到有創(chuàng)建Looper對象,因為作為一個進程,首先不會執(zhí)行完成之后立刻結(jié)束,包括前面在分析idle、init、zygote進程時,都是創(chuàng)建死循環(huán)處理消息,所以system_server也是如此。

  • 再往下看,我們看到執(zhí)行了createSystemContext方法,看注釋是創(chuàng)建了系統(tǒng)的上下文。

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);
}
  • 創(chuàng)建系統(tǒng)的ServiceManager,用來管理系統(tǒng)服務,也就是后續(xù)的三個比較重要的方法,都需要使用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同級的三個方法內(nèi)部都是通過SystemServiceManager來啟動服務,所以我們看一下SystemServiceManager的startService方法具體實現(xiàn):

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最終都會調(diào)用這個方法,傳值為SystemService對象,其實無論是AMS、WMS還是其他的系統(tǒng)服務,都是繼承SystemService,因此在SystemServiceManager中有一個mServices List來收集這些系統(tǒng)服務,最終啟動就是調(diào)用SystemService的onStart方法。

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

我們看下SystemService對于onStart方法的定義,當調(diào)用這個方法的時候,會調(diào)用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:所有系統(tǒng)服務的父類,例如AMS、WMS、PKMS等都是這個大類的子類;
  • SystemServiceManager:屬于SystemServer進程,在SystemServer進程啟動時創(chuàng)建,SystemServer真正用于管理服務的類,其中startService方法用于啟動服務;
  • ServiceManager:系統(tǒng)服務大管家,用于跨進程通信,例如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,所以最終我們還是繼續(xù)分析Activity的啟動流程,但是對于app進程是如何創(chuàng)建的,我們首先需要了解其中的原理。

2.1.1 app進程創(chuàng)建

通過前面的分析,我們知道app啟動其實也是Activity的啟動,所以肯定涉及到ATMS的職責,所以當啟動一個app(Activity)的時候,system_server進程首先會判斷當前要啟動的這個進程是否存在,如果不存在,那么就需要通知Zygote進程去fork app進程。

所以這里就涉及到了system_server進程與Zygote進程間通信,我們知道當Zygote進程初始化的時候,創(chuàng)建了ZygoteServer對象,也就是socket,所以system_server通過socket發(fā)送消息通知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);
    }
}

在這個方法中,我們看到是調(diào)用ActivityManagerInternal # startProcess方法,這個就是真正去啟動app進程的方法,我們跟進看一下,具體怎么發(fā)送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 */);
}

這里我們發(fā)現(xiàn)有兩個比較重要的對象:ProcessRecord和mProcessList;

  • 其中ProcessRecord,顧名思義就是進程的記錄類,用來記錄這些進程的信息,包括與App進程通信的IApplicationThread Binder對象;
  • mProcessList則是一個列表,因為進程啟動需要ATMS來通知Zygote,因此ATMS需要管理多個進程,因此使用mProcessList用來存儲多個ProcessRecord,而且是按照最近使用最少原則(NLU)進行處理,記錄各個進程的信息。

所以最終在啟動進程的時候,就是調(diào)用了mProcessList的startProcessLocked方法,第一個參數(shù)就是進程名。最終調(diào)用的就是android.os.Process的start方法。

Tools for managing OS processes

對于Process相信伙伴們也不會陌生,我們在殺進程或者獲取進程id的時候都會使用到其中的方法,官方給出的解釋就是管理系統(tǒng)進程的工具類。

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方法,最終調(diào)用的是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并創(chuàng)建進程。

所以走到這里,就進入到了與Zygote進程進行socket通信的過程了。在通信之前,會封裝一系列關(guān)于進程相關(guān)的參數(shù),最終調(diào)用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創(chuàng)建之后,就會調(diào)用runSelectLoop方法進行死循環(huán),當接收到Socket消息之后,就會處理消息,最終調(diào)用forkAndSpecialize方法來創(chuàng)建一個進程。這里就與第一小節(jié)中介紹的一致,當創(chuàng)建進程之后,會判斷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創(chuàng)建一個app進程之后,后續(xù)app進程啟動流程如何,我們接著往下看。

當發(fā)送指令告訴Zygote創(chuàng)建進程之后,如果創(chuàng)建子進程成功,那么此時pid == 0,會進入到if代碼塊中,調(diào)用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 */);
        }
    }
}

我們看到最終還是調(diào)用ZygoteInit的zygoteInit方法,這里我們可以回到第一小節(jié)中,其實最終調(diào)用的就是App進程的main方法,也就是ActivityThread的main函數(shù)。

這里先簡單總結(jié)一下,無論是forkSystemServer還是fork普通進程,其實最終都是判斷pid是否為0,因為這里決定著進程是否創(chuàng)建成功,如果進程創(chuàng)建成功,才會有后續(xù)的流程,調(diào)用handlexx方法。

  • 調(diào)用handleXX方法,最終都是調(diào)用ZygoteInit中的zygoteInit方法;
  • 在zygoteInit方法中,會調(diào)用ZygoteInit的nativeZygoteInit方法,會開啟Binder驅(qū)動,創(chuàng)建Binder線程池;
  • 調(diào)用RuntimeInit的applicationInit方法,最終調(diào)用的就是某個類的main方法,例如forkSystemServer中,會調(diào)用SystemServer的main方法;通過ATMS啟動進程,會調(diào)用ActivityThread的main方法。

2.1.3 ActivityThead分析

前面我們提到了,當Zygote fork出app進程之后,就會調(diào)用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");
}

這個方法大家很熟悉,首先也是創(chuàng)建looper,保證app進程不會退出;其次就是創(chuàng)建了ActivityThread對象,并調(diào)用了其中的attach方法。

在attch方法中,有一段核心代碼:

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

它會調(diào)用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的代理對象之后,就可以調(diào)用它的方法,例如attachApplication,而且還是一個接口類,可以通過動態(tài)代理的方式Hook AMS相關(guān)的方法調(diào)用。

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);
    }
}

在這個方法中,最終調(diào)用的是attachApplicationLocked方法,在這個方法中,主要作用就是:

  • 調(diào)用ApplicationThread的bindApplication方法,這里會通過Handler發(fā)送消息,用于創(chuàng)建和初始化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 {
        // 創(chuàng)建Application對象,調(diào)用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 {
            // 調(diào)用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);
        }
    }

    // ......
}

所以調(diào)用bindApplication方法,主要分為3步:創(chuàng)建Application對象,調(diào)用其attach方法、注冊Contentprovider、調(diào)用Application的onCreate方法。

所以如果想要在Application的onCreate方法執(zhí)行之前做一些事情,可以放在Contentprovider中處理,但是會影響啟動速度。

  • 為ProcessRecord的mThread屬性賦值,也就ApplicationThread,用于與App進程通信。
public void makeActive(IApplicationThread thread, ProcessStatsService tracker) {
    mProfile.onProcessActive(thread, tracker);
    mThread = thread;
    mWindowProcessController.setThread(thread);
}
  • 將新創(chuàng)建的ProcessRecord添加到ProcessList中。
final void updateLruProcessLocked(ProcessRecord app, boolean activityChange,
        ProcessRecord client) {
    mProcessList.updateLruProcessLocked(app, activityChange, client);
}

其實在AMS中就是維護了一組ProcessRecord,每個ProcessRecord中都持有這個進程的AppThread Binder對象

那么到這里,當Application的onCreate方法執(zhí)行完成之后,app的進程就已經(jīng)啟動完成了,我們總結(jié)一下:

  • 當點擊Launcher入口準備啟動App時,首先會向AMS發(fā)起啟動Activity的請求,此時AMS會判斷當前進程是否存在,如果不存在,那么就會向Zygote進程發(fā)送socket消息,把要創(chuàng)建的進程信息給到Zygote進程;
  • Zygote進程解析進程信息參數(shù)之后,會fork一個子進程,啟動Binder并創(chuàng)建Binder線程池,然后調(diào)用ActivityThread的main方法;
  • 在ActivityThread的main方法中,創(chuàng)建Looper,并調(diào)用ActivityThread的attach方法;
  • 在調(diào)用ActivityThread的attach方法時,其實會調(diào)用到AMS代理對象的attachApplication方法,進入到SystemServer進程中處理;
  • 在SystemServer進程中,AMS最終會調(diào)用attachApplicationLocked方法,在這個方法中會執(zhí)行AppThread的bindApplication方法,在這個方法中,會創(chuàng)建Application對象,最終執(zhí)行Application的onCreate方法;
  • 當執(zhí)行完Application的onCreate方法之后,App進程算是啟動了,此時會對App進程對應的ProcessRecord對象調(diào)用makeActive賦值處理,然后將其添加到ProcessList當中。

這就是AMS創(chuàng)建app進程的全流程,既然App進程已經(jīng)啟動了。

以上就是Android AMS啟動App進程原理分析的詳細內(nèi)容,更多關(guān)于Android AMS啟動App的資料請關(guān)注腳本之家其它相關(guān)文章!

相關(guān)文章

最新評論