5 ActivityManagerService(三)App启动

所有代码都是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,