Android?AMS啟動(dòng)App進(jìn)程原理分析
1 系統(tǒng)fork進(jìn)程分析
我們知道,Zygote進(jìn)程創(chuàng)建的第一個(gè)進(jìn)程就是system_server進(jìn)程,這個(gè)進(jìn)程的主要作用就是管理服務(wù),例如我們常見的AMS、WMS、PMS等,同時(shí)為App進(jìn)程提供服務(wù)支持。
1.1 fork函數(shù)分析
這里我們拿forkSystemServer方法對(duì)應(yīng)的JNI函數(shù)進(jìn)行分析,在上一節(jié)中已經(jīng)分析了會(huì)調(diào)用ForkCommon函數(shù)進(jìn)行進(jìn)程創(chuàng)建,我們看在這個(gè)方法中,調(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)建進(jìn)程 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ù)最終返回了一個(gè)pid,在這里會(huì)對(duì)pid判斷,這里伙伴們需要注意,雖然fork只會(huì)執(zhí)行一次,但是在返回值上會(huì)有兩次返回,這是什么原因呢?
因?yàn)槲覀冊趂ork進(jìn)程的時(shí)候,我們會(huì)在父進(jìn)程中執(zhí)行fork函數(shù),同時(shí)會(huì)將父進(jìn)程的信息全部拷貝一份,包括堆棧信息,也就是代碼會(huì)在子進(jìn)程中再次執(zhí)行一次,所以從現(xiàn)象上來看,在forkSystemServer方法執(zhí)行時(shí),會(huì)有兩次返回,一次是從父進(jìn)程返回,一次從子進(jìn)程中返回,那么如何判斷是在哪個(gè)進(jìn)程呢?
在ForkCommon函數(shù)中給了我們答案,當(dāng)pid = 0時(shí),因?yàn)樵谧舆M(jìn)程中沒有創(chuàng)建進(jìn)程,因此返回0;而在父進(jìn)程中則是會(huì)返回創(chuàng)建的子進(jìn)程pid;如果返回一個(gè)負(fù)值,那么說明創(chuàng)建進(jìn)程失敗了。
ZygoteInit # forkSystemServer /* For child process */ if (pid == 0) { if (hasSecondZygote(abiList)) { waitForSecondaryZygote(socketName); } zygoteServer.closeServerSocket(); return handleSystemServerProcess(parsedArgs); }
因此,在ZygoteInit調(diào)用forkSystemServer之后,會(huì)判斷其返回值,如果pid = 0,那么就說明創(chuàng)建進(jìn)程成功了,而且是子進(jìn)程,那么就會(huì)執(zhí)行handleSystemServerProcess方法,此時(shí)運(yùn)行在system_server進(jìn)程。
1.2 system_server進(jìn)程啟動(dòng)流程
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)用鏈會(huì)執(zhí)行ZygoteInit的zygoteInit方法,在這個(gè)方法中,又會(huì)執(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,這個(gè)方法比較重要,我們跟進(jìn)看一下。
private static native void nativeZygoteInit();
這是一個(gè)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源碼的伙伴,這里其實(shí)就是會(huì)創(chuàng)建Binder驅(qū)動(dòng)并啟動(dòng)Binder線程池,所以這里就有一個(gè)面試題,Binder驅(qū)動(dòng)是什么時(shí)候啟動(dòng)的?其實(shí)就是在fork進(jìn)程成功之后,處理進(jìn)程啟動(dòng)的時(shí)候完成的,具體函數(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); }
這個(gè)方法最終執(zhí)行findStaticMain方法,這個(gè)方法的其實(shí)很簡單,就是通過反射的方式去查找對(duì)應(yīng)的className的main方法,像我們現(xiàn)在是啟動(dòng)system_server進(jìn)程,所以查找的就是system_server的main方法,最終去執(zhí)行對(duì)應(yīng)的main方法,這樣system_server進(jìn)程就已經(jīng)啟動(dòng)了。
public static void main(String[] args) { new SystemServer().run(); }
我們可以看到,SystemServer的main方法,就是創(chuàng)建一個(gè)SystemServer對(duì)象并執(zhí)行其run方法。
1.2.1 SystemServer run方法分析
private void run() { TimingsTraceAndSlog t = new TimingsTraceAndSlog(); try { //啟動(dòng)服務(wù)之前的初始化操作 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對(duì)象,因?yàn)樽鳛橐粋€(gè)進(jìn)程,首先不會(huì)執(zhí)行完成之后立刻結(jié)束,包括前面在分析idle、init、zygote進(jìn)程時(shí),都是創(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)服務(wù),也就是后續(xù)的三個(gè)比較重要的方法,都需要使用SystemServiceManager來啟動(dòng)服務(wù)。
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(); // ...... }
這里我就拿啟動(dòng)AMS來做介紹,其實(shí)與startBootstrapServices同級(jí)的三個(gè)方法內(nèi)部都是通過SystemServiceManager來啟動(dòng)服務(wù),所以我們看一下SystemServiceManager的startService方法具體實(shí)現(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"); }
其實(shí)所有startService最終都會(huì)調(diào)用這個(gè)方法,傳值為SystemService對(duì)象,其實(shí)無論是AMS、WMS還是其他的系統(tǒng)服務(wù),都是繼承SystemService,因此在SystemServiceManager中有一個(gè)mServices List來收集這些系統(tǒng)服務(wù),最終啟動(dò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對(duì)于onStart方法的定義,當(dāng)調(diào)用這個(gè)方法的時(shí)候,會(huì)調(diào)用publishBinderService將其注冊binder service中。
protected final void publishBinderService(String name, IBinder service, boolean allowIsolated, int dumpPriority) { ServiceManager.addService(name, service, allowIsolated, dumpPriority); }
如果熟悉Binder進(jìn)程間通信的伙伴,我們通常喜歡叫ServiceManager為大管家,是因?yàn)镾erviceManager屬于Binder中用于管理各類服務(wù)的對(duì)象,尤其是涉及到跨進(jìn)程通信。
所以這里有幾個(gè)對(duì)象,我們需要分清楚一些:
- SystemServer:Zygote fork出來的一個(gè)進(jìn)程,主要用來管理各類服務(wù);
- SystemService:所有系統(tǒng)服務(wù)的父類,例如AMS、WMS、PKMS等都是這個(gè)大類的子類;
- SystemServiceManager:屬于SystemServer進(jìn)程,在SystemServer進(jìn)程啟動(dòng)時(shí)創(chuàng)建,SystemServer真正用于管理服務(wù)的類,其中startService方法用于啟動(dòng)服務(wù);
- ServiceManager:系統(tǒng)服務(wù)大管家,用于跨進(jìn)程通信,例如app進(jìn)程想要與AMS通信,那么就需要通過ServerManager來完成進(jìn)程間通信。
如此一來,SystemServer進(jìn)程也就啟動(dòng)完成了。
2 AMS職責(zé)分析
前面對(duì)于SystemServer的啟動(dòng)流程分析中,我們知道會(huì)啟動(dòng)AMS服務(wù),其實(shí)在Android10之前,AMS是會(huì)管理Activity、Service、廣播、Provider四大組件的啟動(dòng),但是因?yàn)槁氊?zé)太多,在Android10之后,專門使用ActivityTaskManagerService(ATMS)來管理Activity的啟動(dòng)。
2.1 App啟動(dòng)流程分析
如果有做過Launcher的伙伴,應(yīng)該明白當(dāng)我們點(diǎn)擊一個(gè)APP ICON的時(shí)候,就會(huì)啟動(dòng)一個(gè)app,這時(shí)APP的啟動(dòng)方式有很多,例如通過包名啟動(dòng)、通過scheme啟動(dòng),那么從點(diǎn)擊ICON到APP展示首頁,這個(gè)過程是如何完成的呢?這里AMS就起到作用了。
因?yàn)楫?dāng)我們啟動(dòng)一個(gè)app的時(shí)候,無論是通過包名還是scheme,都是啟動(dòng)的Activity;例如我們通過包名啟動(dòng),那么就會(huì)啟動(dòng)在Manifest清單文件中,標(biāo)注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啟動(dòng),那么也是啟動(dòng)標(biāo)注這個(gè)scheme的Activity,所以當(dāng)app啟動(dòng)的時(shí)候,也是啟動(dòng)Activity,所以最終我們還是繼續(xù)分析Activity的啟動(dòng)流程,但是對(duì)于app進(jìn)程是如何創(chuàng)建的,我們首先需要了解其中的原理。
2.1.1 app進(jìn)程創(chuàng)建
通過前面的分析,我們知道app啟動(dòng)其實(shí)也是Activity的啟動(dòng),所以肯定涉及到ATMS的職責(zé),所以當(dāng)啟動(dòng)一個(gè)app(Activity)的時(shí)候,system_server進(jìn)程首先會(huì)判斷當(dāng)前要啟動(dòng)的這個(gè)進(jìn)程是否存在,如果不存在,那么就需要通知Zygote進(jìn)程去fork app進(jìn)程。
所以這里就涉及到了system_server進(jìn)程與Zygote進(jìn)程間通信,我們知道當(dāng)Zygote進(jìn)程初始化的時(shí)候,創(chuàng)建了ZygoteServer對(duì)象,也就是socket,所以system_server通過socket發(fā)送消息通知Zygote去fork app進(jìn)程。
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); } }
在這個(gè)方法中,我們看到是調(diào)用ActivityManagerInternal # startProcess方法,這個(gè)就是真正去啟動(dòng)app進(jìn)程的方法,我們跟進(jìn)看一下,具體怎么發(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)有兩個(gè)比較重要的對(duì)象:ProcessRecord和mProcessList;
- 其中ProcessRecord,顧名思義就是進(jìn)程的記錄類,用來記錄這些進(jìn)程的信息,包括與App進(jìn)程通信的IApplicationThread Binder對(duì)象;
- mProcessList則是一個(gè)列表,因?yàn)檫M(jìn)程啟動(dòng)需要ATMS來通知Zygote,因此ATMS需要管理多個(gè)進(jìn)程,因此使用mProcessList用來存儲(chǔ)多個(gè)ProcessRecord,而且是按照最近使用最少原則(NLU)進(jìn)行處理,記錄各個(gè)進(jìn)程的信息。
所以最終在啟動(dòng)進(jìn)程的時(shí)候,就是調(diào)用了mProcessList的startProcessLocked方法,第一個(gè)參數(shù)就是進(jìn)程名。最終調(diào)用的就是android.os.Process的start方法。
Tools for managing OS processes
對(duì)于Process相信伙伴們也不會(huì)陌生,我們在殺進(jìn)程或者獲取進(jìn)程id的時(shí)候都會(huì)使用到其中的方法,官方給出的解釋就是管理系統(tǒng)進(jìn)程的工具類。
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();
它是一個(gè)ZygoteProcess對(duì)象,官方解釋如下:
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進(jìn)程的通信,這個(gè)類的職責(zé)就是打開Zygote進(jìn)程的socket并創(chuàng)建進(jìn)程。
所以走到這里,就進(jìn)入到了與Zygote進(jìn)程進(jìn)行socket通信的過程了。在通信之前,會(huì)封裝一系列關(guān)于進(jìn)程相關(guān)的參數(shù),最終調(diào)用attemptZygoteSendArgsAndGetResult方法與Zygote進(jìn)程進(jìn)行通信。
private Process.ProcessStartResult attemptZygoteSendArgsAndGetResult( ZygoteState zygoteState, String msgStr) throws ZygoteStartFailedEx { try { final BufferedWriter zygoteWriter = zygoteState.mZygoteOutputWriter; final DataInputStream zygoteInputStream = zygoteState.mZygoteInputStream; //進(jìn)行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); } }
前面我們 對(duì)于Zygote啟動(dòng)流程的分析,在ZygoteServer創(chuàng)建之后,就會(huì)調(diào)用runSelectLoop方法進(jìn)行死循環(huán),當(dāng)接收到Socket消息之后,就會(huì)處理消息,最終調(diào)用forkAndSpecialize方法來創(chuàng)建一個(gè)進(jìn)程。這里就與第一小節(jié)中介紹的一致,當(dāng)創(chuàng)建進(jìn)程之后,會(huì)判斷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進(jìn)程啟動(dòng)流程分析
前面我們介紹,在ATMS中通過Socket通信通知Zygote創(chuàng)建一個(gè)app進(jìn)程之后,后續(xù)app進(jìn)程啟動(dòng)流程如何,我們接著往下看。
當(dāng)發(fā)送指令告訴Zygote創(chuàng)建進(jìn)程之后,如果創(chuàng)建子進(jìn)程成功,那么此時(shí)pid == 0,會(huì)進(jìn)入到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é)中,其實(shí)最終調(diào)用的就是App進(jìn)程的main方法,也就是ActivityThread的main函數(shù)。
這里先簡單總結(jié)一下,無論是forkSystemServer還是fork普通進(jìn)程,其實(shí)最終都是判斷pid是否為0,因?yàn)檫@里決定著進(jìn)程是否創(chuàng)建成功,如果進(jìn)程創(chuàng)建成功,才會(huì)有后續(xù)的流程,調(diào)用handlexx方法。
- 調(diào)用handleXX方法,最終都是調(diào)用ZygoteInit中的zygoteInit方法;
- 在zygoteInit方法中,會(huì)調(diào)用ZygoteInit的nativeZygoteInit方法,會(huì)開啟Binder驅(qū)動(dòng),創(chuàng)建Binder線程池;
- 調(diào)用RuntimeInit的applicationInit方法,最終調(diào)用的就是某個(gè)類的main方法,例如forkSystemServer中,會(huì)調(diào)用SystemServer的main方法;通過ATMS啟動(dòng)進(jìn)程,會(huì)調(diào)用ActivityThread的main方法。
2.1.3 ActivityThead分析
前面我們提到了,當(dāng)Zygote fork出app進(jìn)程之后,就會(huì)調(diào)用ActivityThread的main方法,這里就是進(jìn)入到我們熟悉的App進(jìn)程啟動(dòng)中了。
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"); }
這個(gè)方法大家很熟悉,首先也是創(chuàng)建looper,保證app進(jìn)程不會(huì)退出;其次就是創(chuàng)建了ActivityThread對(duì)象,并調(diào)用了其中的attach方法。
在attch方法中,有一段核心代碼:
final IActivityManager mgr = ActivityManager.getService(); try { mgr.attachApplication(mAppThread, startSeq); } catch (RemoteException ex) { throw ex.rethrowFromSystemServer(); }
它會(huì)調(diào)用IActivityManager(也就是AMS在app進(jìn)程的代理對(duì)象)的attachApplication方法,mAppThread就是ApplicationThread對(duì)象,這個(gè)屬于app進(jìn)程的代理對(duì)象,會(huì)丟給AMS使用。
final ApplicationThread mAppThread = new ApplicationThread();
就這樣,App進(jìn)程持有AMS端的代理,AMS端也會(huì)持有App進(jìn)程的代理,雙方就可以通過Binder完成進(jìn)程間的通信。
其實(shí)在App進(jìn)程中,可以通過ServiceManager來獲取AMS的代理對(duì)象的,
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的代理對(duì)象之后,就可以調(diào)用它的方法,例如attachApplication,而且還是一個(gè)接口類,可以通過動(dòng)態(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); } }
在這個(gè)方法中,最終調(diào)用的是attachApplicationLocked方法,在這個(gè)方法中,主要作用就是:
- 調(diào)用ApplicationThread的bindApplication方法,這里會(huì)通過Handler發(fā)送消息,用于創(chuàng)建和初始化Application對(duì)象;
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對(duì)象,調(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對(duì)象,調(diào)用其attach方法、注冊Contentprovider、調(diào)用Application的onCreate方法。
所以如果想要在Application的onCreate方法執(zhí)行之前做一些事情,可以放在Contentprovider中處理,但是會(huì)影響啟動(dòng)速度。
- 為ProcessRecord的mThread屬性賦值,也就ApplicationThread,用于與App進(jìn)程通信。
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); }
其實(shí)在AMS中就是維護(hù)了一組ProcessRecord,每個(gè)ProcessRecord中都持有這個(gè)進(jìn)程的AppThread Binder對(duì)象。
那么到這里,當(dāng)Application的onCreate方法執(zhí)行完成之后,app的進(jìn)程就已經(jīng)啟動(dòng)完成了,我們總結(jié)一下:
- 當(dāng)點(diǎn)擊Launcher入口準(zhǔn)備啟動(dòng)App時(shí),首先會(huì)向AMS發(fā)起啟動(dòng)Activity的請求,此時(shí)AMS會(huì)判斷當(dāng)前進(jìn)程是否存在,如果不存在,那么就會(huì)向Zygote進(jìn)程發(fā)送socket消息,把要?jiǎng)?chuàng)建的進(jìn)程信息給到Zygote進(jìn)程;
- Zygote進(jìn)程解析進(jìn)程信息參數(shù)之后,會(huì)fork一個(gè)子進(jìn)程,啟動(dòng)Binder并創(chuàng)建Binder線程池,然后調(diào)用ActivityThread的main方法;
- 在ActivityThread的main方法中,創(chuàng)建Looper,并調(diào)用ActivityThread的attach方法;
- 在調(diào)用ActivityThread的attach方法時(shí),其實(shí)會(huì)調(diào)用到AMS代理對(duì)象的attachApplication方法,進(jìn)入到SystemServer進(jìn)程中處理;
- 在SystemServer進(jìn)程中,AMS最終會(huì)調(diào)用attachApplicationLocked方法,在這個(gè)方法中會(huì)執(zhí)行AppThread的bindApplication方法,在這個(gè)方法中,會(huì)創(chuàng)建Application對(duì)象,最終執(zhí)行Application的onCreate方法;
- 當(dāng)執(zhí)行完Application的onCreate方法之后,App進(jìn)程算是啟動(dòng)了,此時(shí)會(huì)對(duì)App進(jìn)程對(duì)應(yīng)的ProcessRecord對(duì)象調(diào)用makeActive賦值處理,然后將其添加到ProcessList當(dāng)中。
這就是AMS創(chuàng)建app進(jìn)程的全流程,既然App進(jìn)程已經(jīng)啟動(dòng)了。
以上就是Android AMS啟動(dòng)App進(jìn)程原理分析的詳細(xì)內(nèi)容,更多關(guān)于Android AMS啟動(dòng)App的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
Android獲取手機(jī)的版本號(hào)等信息的代碼
這篇文章主要為大家詳細(xì)介紹了Android獲取手機(jī)的版本號(hào)等信息的代碼,代碼很精彩,感興趣的小伙伴們可以參考一下2016-07-07簡析Android五大布局(LinearLayout、FrameLayout、RelativeLayout等)
這篇文章主要為大家簡單分析了Android五大布局,內(nèi)容有LinearLayout、FrameLayout、RelativeLayout、AbsoluteLayout和TableLayout的相關(guān)資料,感興趣的小伙伴們可以參考一下2016-06-06Android開發(fā)手冊TextInputLayout樣式使用示例
這篇文章主要為大家介紹了Android開發(fā)手冊TextInputLayout樣式使用示例,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-06-06android studio 安裝完成ButterKnife插件卻無法使用(解決方案)
這篇文章主要介紹了android studio 安裝完成ButterKnife插件卻無法使用問題,本文通過圖文并茂的形式給大家分享解決方法,對(duì)大家有非常好的幫助,需要的朋友可以參考下2020-03-03Android EditText 監(jiān)聽用戶輸入完成的實(shí)例
下面小編就為大家分享一篇Android EditText 監(jiān)聽用戶輸入完成的實(shí)例,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。一起跟隨小編過來看看吧2018-02-02Android調(diào)用默認(rèn)瀏覽器打開指定Url的方法實(shí)例
業(yè)務(wù)員有需求要將一個(gè)wap站在手機(jī)上以App的形式打開,還不要嵌套WebView,只能以瀏覽器打開.查了點(diǎn)資料,就有了下面這代碼2013-09-09Android如何動(dòng)態(tài)改變App桌面圖標(biāo)
這篇文章主要介紹了 Android動(dòng)態(tài)改變App桌面圖標(biāo)的方法,非常不錯(cuò),具有參考借鑒價(jià)值,需要的朋友參考下2017-01-01Android數(shù)據(jù)加密之Rsa加密的簡單實(shí)現(xiàn)
下面小編就為大家?guī)硪黄狝ndroid數(shù)據(jù)加密之Rsa加密的簡單實(shí)現(xiàn)。小編覺得挺不錯(cuò)的,現(xiàn)在就分享給大家,也給大家做個(gè)參考。一起跟隨小編過來看看吧2016-10-10深入分析Android ViewStub的應(yīng)用詳解
本篇文章是對(duì)Android ViewStub的應(yīng)用進(jìn)行了詳細(xì)的分析介紹,需要的朋友參考下2013-05-05