所有代码都是Android 11
在上一篇文章 app启动准备流程分析到了创建进程,那么今天就继续来分析一下进程是如何创建的,以及进程创建后的流程
AMS LocalService startProcessLocked --> 将参数传递进入 AMS 的 mProcessList 中去创建进程 ,此时有一个非常重要的参数需要了解ApplicationInfo info
class ApplicationInfo {
/**
* The name of the process this application should run in. From the
* "process" attribute or, if not set, the same as
* <var>packageName</var>.
*/
public String processName;
/**
* Class implementing the Application object. From the "class"
* attribute.
*/
public String className;
}
我截取了两个接下来比较重要的参数,一个是 className application对象的类名 ,另一个就是进程名字
ProcessList startProcessLocked 这个里面参数比较多,注意我们传递的数据类型就可以了继续跟踪了
if (!isolated) {
app = getProcessRecordLocked(processName, info.uid, keepIfLarge);
if ((intentFlags & Intent.FLAG_FROM_BACKGROUND) != 0) {
if (mService.mAppErrors.isBadProcessLocked(info)) {
return null;
}
} else {
mService.mAppErrors.resetProcessCrashTimeLocked(info);
if (mService.mAppErrors.isBadProcessLocked(info)) {
mService.mAppErrors.clearBadProcessLocked(info);
if (app != null) {
app.bad = false;
}
}
}
} else {
app = null;
}
ProcessRecord precedence = null;
if (app != null && app.pid > 0) {
if ((!knownToBeDead && !app.killed) || app.thread == null) {
app.addPackage(info.packageName, info.longVersionCode, mService.mProcessStats);
return app;
}
ProcessList.killProcessGroup(app.uid, app.pid);
precedence = app;
app = null;
}
if (app == null) {
app = newProcessRecordLocked(info, processName, isolated, isolatedUid, hostingRecord);
if (app == null) {
return null;
}
app.crashHandler = crashHandler;
app.isolatedEntryPoint = entryPoint;
app.isolatedEntryPointArgs = entryPointArgs;
if (precedence != null) {
app.mPrecedence = precedence;
precedence.mSuccessor = app;
}
} else {
app.addPackage(info.packageName, info.longVersionCode, mService.mProcessStats);
}
if (!mService.mProcessesReady
&& !mService.isAllowedWhileBooting(info)
&& !allowWhileBooting) {
if (!mService.mProcessesOnHold.contains(app)) {
mService.mProcessesOnHold.add(app);
}
return app;
}
在这里进行了一系列的判断 是否是系统级的孤立进程,如果不是会再去进程的Name 列表匹配一下,如果匹配到了,并且这个app 进程 的还需要查看一下他是否是后台启动的进程,是否是一个损坏的进程等一系列的判断,继续向下面传递各个参数,
在传递参数的过程中发现一个比较有意思的地方,
if (hostingRecord.usesWebviewZygote()) {
} else if (hostingRecord.usesAppZygote()) {
final AppZygote appZygote = createAppZygoteForProcessIfNeeded(app);
startResult = appZygote.getProcess().start()
} else {}
在启动过程中他会判断这个需要启动的进程是否是webviewzygote , 还是appzygote 从这里可以看出来 webview 在整个系统中是一个非常特殊的地位,app 进程会使用懒加载的方式查看appzygote 是否存在,如果不存在就创建,已经存在了则返回,调用 appZygote.getProcess().start 方法继续向下流转
ZygoteProcess.start
这里有一个需要非常重要的地方,那就是在进程创建后 AppThread 启动后,那么他是如何寻找 Applicaiton 的呢,看看下面代码就知道了
argsForZygote.add("--package-name=" + packageName);
这个就是在启动进程最初的阶段我们记录的ApplicaitonInfo 里面记录的信息, 数据继续流转
ZygoteProcess.attemptUsapSendArgsAndGetResult 向zygote 发起链接,并去读返回结果,
我们在Framework 的文章中的 App启动过程中提到过,zygote 在启动SystemServer 之前会创建一个Socket ,并开启looper,等待fork进程,那么这个最终就流向了ZygoteInit,
