Android四大组件之Activity（五）——AMS：针对新启动的Activity创建一个新的进程

1、使用的是Android 7.1.2的源代码：

https://pan.baidu.com/s/1XcVD68cC_2wKtm8jJkdNQA
przv

2、感谢IT先森的系列博客：

Android应用进程创建流程大揭秘
Android四大组件之bindService源码实现详解
Android四大组件之Activity启动流程源码实现详解概要
Activity启动流程(一)发起端进程请求启动目标Activity
Activity启动流程(二)system_server进程处理启动Activity请求
Activity启动流程(三)-Activity Task调度算法复盘分析
Activity启动流程(四)-Pause前台显示Activity，Resume目标Activity
Activity启动流程(五)请求并创建目标Activity进程
Activity启动流程(六)注册目标Activity进程到system_server进程以及创建目标Activity进程Application
Activity启动流程(七)初始化目标Activity并执行相关生命周期流程

3、理解Android进程创建流程：http://gityuan.com/2016/03/26/app-process-create/

继续上一篇：Android四大组件之Activity（四）—— 启动模式(launchMode) + Pause上一个Activity

AMS请求Zygote创建目标Activity所属进程_相关伪代码：

ActivityStackSupervisor.startSpecificActivityLocked
   AMS.startProcessLocked
      AMS.startProcessLocked
    	 AMS.newProcessRecordLocked
    		addProcessNameLocked(r);//将ProcessRecord信息在AMS中存储起来
    	 AMS.startProcessLocked
            //final String entryPoint = "android.app.ActivityThread";
            Process.start(entryPoint, ··· ···)
            Process.startViaZygote()	
            	Process.zygoteSendArgsAndGetResult(openZygoteSocketIfNeeded(abi), argsForZygote); 

AMS请求Zygote创建目标Activity所属进程_相关子流程：

• AMS请求Zygote创建目标Activity所属进程
• Zygote孵化目标Activity所属进程
• 初始化目标Activity所属进程
• 注册目标Activity所属进程到system_server
• 目标Activity所属进程创建Application实例对象

进程：每个App在启动之前必须先创建一个进程，该进程是由Zygote fork出来的，进程具有独立的资源空间，用于承载 App 上运行的各种 Activity/Service 等组件。大多数情况下，一个 App 就运行在一个进程中，除非在AndroidManifest.xml中 配置 android:process 属性，或通过 native 代码fork进程。

system_server进程：用于管理整个Java framework层，包含ActivityManager、PowerManager等各种系统服务。system_server进程以及所有的App进程都是Zygote的子进程。

Zygote进程：Android系统的首个Java进程，Zygote进程是所有Java进程的父进程。

1、AMS.startProcessLocked

//[ActivityManagerService.java]
	//这个参数够多的，真是够多的
    final ProcessRecord startProcessLocked(String processName, //目标Activity对应的进程名，通常上是包名
    									   ApplicationInfo info,//Activity所属App的Application信息
            							   boolean knownToBeDead, //这个参数具体意义不明，传递过来的值为true
            							   int intentFlags, //参数的值为0
            							   String hostingType, //这个参数意义不明，参数值为"activity"
            							   ComponentName hostingName,//启动目标Activity时解析intent时得到的
            							   boolean allowWhileBooting, //是否允许在开启启动时，参数未false
            							   boolean isolated, //参数为false，这个值的意思是该进程是否是隔离的
            							   int isolatedUid, //指定隔离进程的UID
            							   boolean keepIfLarge,//参数意义不明，传递的值为true
            							   String abiOverride, //是否覆盖目标Activity所属app安装时的abi，abi通常影响so库的选择，取值为null
            							   String entryPoint, //参数意义不明，取值为null
            							   String[] entryPointArgs, //参数意义不明，取值为null
            							   Runnable crashHandler) //参数意义不明，取值为null
    {
   
        ...
        ProcessRecord app;
        if (!isolated) {
   //当不是隔离进程时
        	/*
	        	获取AMS中是否存在目标Activity所属进程的ProcessRecord记录，在非isolated模式下AMS可以重用先前的ProcessRecord记录
	        	这里小伙们肯定有个疑问就是为啥startSpecificActivityLocked中检查了一次，这里又检查一次，
	        	而和startSpecificActivityLocked处理不同的是这里并没有因为ProcessRecord的存在而停止后续的脚步呢
	        	好吗，此处的逻辑感觉有点不是很清晰啊
                
                在startSpecificActivityLocked中已经调用过一次getProcessRecordLocked来看目的Activity的进程是否存在
        	*/
            app = getProcessRecordLocked(processName, info.uid, keepIfLarge);
			// 启动参数中，带有FLAG_FROM_BACKGROUND标志，表示进程需要后台启动
            if ((intentFlags & Intent.FLAG_FROM_BACKGROUND) != 0) {
   
            	// 后台启动一个BadProcess，直接退出
                if (mAppErrors.isBadProcessLocked(info)) {
   
                    return null;
                }
            } else {
   
                //清理进程Crash消息
                mAppErrors.resetProcessCrashTimeLocked(info);
                if (mAppErrors.isBadProcessLocked(info)) {
   
                	// 前台启动，则需要将宿主进程从坏的进程中剔除
                    mAppErrors.clearBadProcessLocked(info);
                    if (app != null) {
   
                        app.bad = false;
                    }
                }
            }
        } else {
   
            app = null;
        }
		
		/*
			此处涉及到了超自然现象,看注释的意思是对于大小核的架构的设备的话，此时使用cpuset将前台任务迁移到大核上
			这个已经超过本人的能力范畴之外了，pass
		*/
		nativeMigrateToBoost();
        mIsBoosted = true;
		...
		
		// 当进程已经被分配了PID时
        if (app != null && app.pid > 0) {
   
        	// 进程还处于启动的过程中
            if ((!knownToBeDead && !app.killed) || app.thread == null) {
   
                app.addPackage(info.packageName, info.versionCode, mProcessStats);
                return app;
            }

			/*
				这个地方要怎么理解呢，可能前面目标Activity所属App进程被创建过
				但是已经over了再启动时需要对其做一些清理工作
			*/
            killProcessGroup(app.uid, app.pid);
            handleAppDiedLocked(app, true, true);
        }

        String hostingNameStr = hostingName != null
                ? hostingName.flattenToShortString() : null;

        if (app == null) {
   
        //
        	//在AMS中创建ProcessRecord信息记录
            app = newProcessRecordLocked(info, processName, isolated, isolatedUid);//-->1 进入这里
            if (app == null) {
   
                return null;
            }
            //设置crashHandler
            app.crashHandler = crashHandler;
        } else {
   
            app.addPackage(info.packageName, info.versionCode, mProcessStats);
        }

		// 如果系统还未启动，则需要将待启动进程先保持住，等系统启动后，再来启动这些进程
		//final ArrayList<ProcessRecord> mProcessesOnHold = new ArrayList<ProcessRecord>();
        if (!mProcessesReady
                && !isAllowedWhileBooting(info)
                && !allowWhileBooting) {
   
            if (!mProcessesOnHold.contains(app)) {
   
                mProcessesOnHold.add(app);
            }
            return app;
        }

        //又调用另外一个重载的startProcessLocked
        startProcessLocked(
                app, hostingType, hostingNameStr, abiOverride, entryPoint, entryPointArgs);//2 -->进入这里
        
        return (app.pid != 0) ? app : null;
    }

2、AMS.newProcessRecordLocked

//[ActivityManagerService.java]
/**
* @param0，info，值为Activity B所属App的Application信息
* @param1，customProcess，值为Activity B对应的进程名，通常上是包名
* @param2，isolated，参数为false，这个值的意思是该进程是否是隔离的