一. AMS简介
AmS可以说是Android上层系统最核心的模块之一，其主要完成管理应用进程的生命周期以及进程的Activity，Service，Broadcast和Provider等。
从系统运行的角度看，AmS可以分为Client端和Service端：
Client端运行在各个app进程，app进程实现了具体的 Activity，Service等，告诉系统我有那些Activity，Service等，并且调用系统接口来完成显示；
Service端运行在 SystemServer进程，是系统级别的ActivityManagerService的具体实现，其响应Client端的系统调用请求，并且管理 Client端各个app进程的生命周期。
图1 AmS基本类图
关于AMS的代理模式可以参考 http://www.cnblogs.com/neo-java/p/7230042.html
如下图是AmS内部主要数据结构类图，看了code相信大家都会知道这些类都是干什么的，这儿只是总结一下。
图2 AmS内部主要数据结构类图
二. AMS启动过程
启动过程主要分为四部分：
1、创建出SystemServer进程的Android运行环境。
在这一部分，SystemServer进程主要创建出对应的ActivityThread和ContextImpl，构成Android运行环境。
AMS的后续工作依赖于SystemServer在此创建出的运行环境。
2、完成AMS的初始化和启动。
在这一部分，单纯地调用AMS的构造函数和start函数，完成AMS的一些初始化工作。
3、将SystemServer进程纳入到AMS的管理体系中。
AMS作为Java世界的进程管理和调度中心，要对所有Java进程一视同仁，因此SystemServer进程也必须被AMS管理。
在这个过程中，AMS加载了SystemServer中framework-res.apk的信息，并启动和注册了SettingsProvider.apk。
4、开始执行AMS启动完毕后才能进行的工作。
系统中的一些服务和进程，必须等待AMS完成启动后，才能展开后续工作。
在这一部分，AMS通过调用systemReady函数，通知系统中的其它服务和进程，可以进行对应工作了。
在这个过程中，值得我们关注的是：Home Activity被启动了。当该Activity被加载完成后，最终会触发ACTION_BOOT_COMPLETED广播。
下面分别讲解。
2.1 创建SystemServer进程的Android运行环境
2.1.1 我们已经知道了，zygote创建出的第一个java进程是SystemServer。
在SystemServer的run函数中，在启动AMS之前，调用了createSystemContext函数。
其代码如下所示：
1 ............. 2 //SystemServer在启动任何服务之前，就调用了createSystemContext 3 //创建出的Context保存在mSystemContext中 4 // Initialize the system context. 5 createSystemContext(); 6 7 // Create the system service manager. 8 //SystemServiceManager负责启动所有的系统服务，使用的Context就是mSystemContext 9 mSystemServiceManager = new SystemServiceManager(mSystemContext); 10 .............
我们跟进一下createSystemContext：
1 private void createSystemContext() { 2 //调用ActivityThread的systemMain函数，其中会创建出系统对应的Context对象 3 ActivityThread activityThread = ActivityThread.systemMain(); 4 5 //取出上面函数创建的Context对象，保存在mSystemContext中 6 mSystemContext = activityThread.getSystemContext(); 7 8 //设置系统主题 9 mSystemContext.setTheme(DEFAULT_SYSTEM_THEME); 10 }
以上函数中，最重要的就是ActivityThread.systemMain了，我们分析一下该函数。
2.1.2 ActivityThread.systemMain的代码如下
1 public static ActivityThread systemMain() { 2 // The system process on low-memory devices do not get to use hardware 3 // accelerated drawing, since this can add too much overhead to the 4 // process. 5 if (!ActivityManager.isHighEndGfx()) { 6 //虽然写着ActivityManager，但和AMS没有任何关系 7 //就是利用系统属性和配置信息进行判断 8 9 //关闭硬件渲染功能 10 ThreadedRenderer.disable(true); 11 } else { 12 ThreadedRenderer.enableForegroundTrimming(); 13 } 14 15 //创建ActivityThread 16 ActivityThread thread = new ActivityThread(); 17 //调用attach函数，参数为true 18 thread.attach(true); 19 return thread; 20 }
从上面的代码可以看出，ActivityThread的systemMain函数中，除了进行是否开启硬件渲染的判断外，主要作用是：
创建出ActivityThread对象，然后调用该对象的attach函数。
ActivityThread的构造函数比较简单：
1 ActivityThread() { 2 mResourcesManager = ResourcesManager.getInstance(); 3 }
比较关键的是它的成员变量：
1 .......... 2 //定义了AMS与应用通信的接口 3 final ApplicationThread mAppThread = new ApplicationThread(); 4 5 //拥有自己的looper，说明ActivityThread确实可以代表事件处理线程 6 final Looper mLooper = Looper.myLooper(); 7 8 //H继承Handler，ActivityThread中大量事件处理依赖此Handler 9 final H mH = new H(); 10 11 //用于保存该进程的ActivityRecord 12 final ArrayMap<IBinder, ActivityClientRecord> mActivities = new ArrayMap<>() 13 .......... 14 //用于保存进程中的Service 15 final ArrayMap<IBinder, Service> mServices = new ArrayMap<>(); 16 ........... 17 //用于保存进程中的Application 18 final ArrayList<Application> mAllApplications = new ArrayList<Application>(); 19 ...........
我们需要知道的是，ActivityThread是android Framework中一个非常重要的类，它代表一个应用进程的主线程，其职责就是调度及执行在该线程中运行的四大组件。
在Android中，应用进程指那些运行APK的进程，它们由zygote fork出来，其中运行着独立的dalvik虚拟机。
与应用进程相对的就是系统进程，例如zygote和SystemServer。
注意到此处的ActivityThread创建于SystemServer进程中。
由于SystemServer中也运行着一些系统APK，例如framework-res.apk、SettingsProvider.apk等，因此也可以认为SystemServer是一个特殊的应用进程。
对于上面提到的ActivityThread的成员变量，其用途基本上可以从名称中得知，这里仅说明一下ApplicationThread。
AMS负责管理和调度进程，因此AMS需要通过Binder机制和应用进程通信。
为此，Android提供了一个IApplicationThread接口，该接口定义了AMS和应用进程之间的交互函数。
如上图所示，ActivityThread作为应用进程的主线程代表，在其中持有ApplicationThread。ApplicationThread继承ApplicationThreadNative。
当AMS与应用进程通信时，ApplicationThread将作为Binder通信的服务端。
AMS与应用进程通信时，通过ApplicationThreadNative获取应用进程对应的ApplicationThreadProxy对象。
通过ApplicationThreadProxy对象，将调用信息通过Binder传递到ActivityThread中的ApplicationThread。
这个调用过程，今后还会遇到，碰到的时候再详细分析。
2.1.3 ActivityThread.attach
1 我们看看ActivityThread的attach函数： 2 3 //此时，我们传入的参数为true，表示该ActivityThread是系统进程的ActivityThread 4 private void attach(boolean system) { 5 //创建出的ActivityThread保存在类的静态变量sCurrentActivityThread 6 //AMS中的大量操作将会依赖于这个ActivityThread 7 sCurrentActivityThread = this; 8 mSystemThread = system; 9 10 if (!system) { 11 //应用进程的处理流程 12 .......... 13 } else { 14 //系统进程的处理流程，该情况只在SystemServer中处理 15 16 // Don't set application object here -- if the system crashes, 17 // we can't display an alert, we just want to die die die. 18 //设置DDMS(Dalvik Debug Monitor Service)中看到的SystemServer进程的名称为“system_process” 19 android.ddm.DdmHandleAppName.setAppName("system_process", 20 UserHandle.myUserId()); 21 22 try { 23 //创建ActivityThread中的重要成员：Instrumentation、Application和Context 24 mInstrumentation = new Instrumentation(); 25 ContextImpl context = ContextImpl.createAppContext( 26 this, getSystemContext().mPackageInfo); 27 mInitialApplication = context.mPackageInfo.makeApplication(true, null); 28 mInitialApplication.onCreate(); 29 } catch (Exception e) { 30 throw new RuntimeException( 31 "Unable to instantiate Application():" + e.toString(), e); 32 } 33 } 34 35 //以下系统进程和非系统进程均会执行 36 ................ 37 //注册Configuration变化的回调通知 38 ViewRootImpl.addConfigCallback(new ComponentCallbacks2() { 39 @Override 40 public void onConfigurationChanged(Configuration newConfig) { 41 //当系统配置发生变化时（例如系统语言发生变化），回调该接口 42 ............... 43 } 44 ............. 45 }); 46 }
从上面的代码可以看出，对于系统进程而言，ActivityThread的attach函数最重要的工作就是创建了Instrumentation、Application和Context。
Instrumentation
Instrumentation是Android中的一个工具类，当该类被启用时，它将优先于应用中其它的类被初始化。
此时，系统先创建它，再通过它创建其它组件。
此外，系统和应用组件之间的交互也将通过Instrumentation来传递。
因此，Instrumentation就能监控系统和组件的交互情况了。
实际使用时，可以创建该类的派生类进行相应的操作。
这个类在介绍启动Activity的过程时还会碰到，此处不作展开。
Context
Context是Android中的一个抽象类，用于维护应用运行环境的全局信息。
通过Context可以访问应用的资源和类，甚至进行系统级的操作，例如启动Activity、发送广播等。
ActivityThread的attach函数中，通过下面的代码创建出系统应用对应的Context:
1 ....... 2 //ContextImpl是Context的实现类 3 ContextImpl context = ContextImpl.createAppContext( 4 this, getSystemContext().mPackageInfo); 5 .......
Application
Android中Application类用于保存应用的全局状态。
我们经常使用的Activity和Service均必须和具体的Application绑定在一起。
通过上图的继承关系，每个具体的Activity和Service均被加入到Android运行环境中。
在ActivityThread中，针对系统进程，通过下面的代码创建了初始的Application：
1 .............. 2 //调用LoadedApk的makeApplication函数 3 mInitialApplication = context.mPackageInfo.makeApplication(true, null); 4 5 //启动Application 6 mInitialApplication.onCreate(); 7 ..............
我们看一下LoadedApk.makeApplication：
1 public Application makeApplication(boolean forceDefaultAppClass, 2 Instrumentation instrumentation) { 3 if (mApplication != null) { 4 return mApplication; 5 } 6 ............. 7 Application app = null; 8 9 String appClass = mApplicationInfo.className; 10 if (forceDefaultAppClass || (appClass == null)) { 11 //系统进程中，对应下面的appClass 12 appClass = "android.app.Application"; 13 } 14 15 try { 16 java.lang.ClassLoader cl = getClassLoader(); 17 if (!mPackageName.equals("android")) { 18 ............ 19 } 20 21 ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this); 22 //实际上最后通过反射创建出Application 23 app = mActivityThread.mInstrumentation.newApplication( 24 cl, appClass, appContext); 25 appContext.setOuterContext(app); 26 } catch (Exception e) { 27 .......... 28 } 29 30 //一个进程支持多个Application，mAllApplications用于保存该进程中的Application对象 31 mActivityThread.mAllApplications.add(app); 32 mApplication = app; 33 34 .............. 35 }
从上面的代码不难看出，这部分主要是创建framework-res.apk对应的Application，然后调用它的onCreate函数，完成启动。
第一步的总结
至此，createSystemContext函数介绍完毕。
当SystemServer调用createSystemContext完毕后：
1、得到了一个ActivityThread对象，它代表当前进程 (此时为系统进程) 的主线程；
2、得到了一个Context对象，对于SystemServer而言，它包含的Application运行环境与framework-res.apk有关。
在继续分析AMS之前，我们先停下来思考一下，为什么在启动所有的服务前，SystemServer先要调用createSystemContext？
个人觉得《深入理解Android》对这个问题，解释的比较好，大致意思如下：
Android努力构筑了一个自己的运行环境。
在这个环境中，进程的概念被模糊化了。组件的运行及它们之间的交互均在该环境中实现。
createSystemContext函数就是为SystemServer进程搭建一个和应用进程一样的Android运行环境。
Android运行环境是构建在进程之上的，应用程序一般只和Android运行环境交互。
基于同样的道理，SystemServer进程希望它内部运行的应用，
也通过Android运行环境交互，因此才调用了createSystemContext函数。
创建Android运行环境时，
由于SystemServer的特殊性，调用了ActivityThread.systemMain函数；
对于普通的应用程序，将在自己的主线程中调用ActivityThread.main函数。
上图表示了进程的Android运行环境涉及的主要类之间的关系。
其中的核心类是ContextImpl，通过它可以得到ContentResolver、系统资源、应用信息等。
2.2 AMS的初始化和启动
创建完Android运行环境后，SystemServer调用startBootstrapServices，其中就创建并启动了AMS:
1 private void startBootstrapServices() { 2 Installer installer = mSystemServiceManager.startService(Installer.class); 3 4 // Activity manager runs the show. 5 //启动AMS，然后获取AMS保存到变量中 6 mActivityManagerService = mSystemServiceManager.startService( 7 ActivityManagerService.Lifecycle.class).getService(); 8 9 //以下均是将变量存储到AMS中 10 mActivityManagerService.setSystemServiceManager(mSystemServiceManager); 11 mActivityManagerService.setInstaller(installer); 12 .......... 13 }
注意到上面的代码并没有直接启动AMS，而是启动AMS的内部类Lifecycle。
这是迫不得已的做法，由于AMS并没有继承SystemService，因此不能通过SystemServiceManager的startService直接启动它。
可以这样理解：内部类Lifecycle对于AMS而言，就像一个适配器一样，让AMS能够像SystemService一样被SystemServiceManager通过反射的方式启动。
1 public static final class Lifecycle extends SystemService { 2 private final ActivityManagerService mService; 3 4 public Lifecycle(Context context) { 5 //Lifecycle由SystemServiceManager启动，传入的context就是SystemServer创建出的SystemContext 6 super(context); 7 8 //1、调用AMS的构造函数 9 mService = new ActivityManagerService(context); 10 } 11 12 @Override 13 public void onStart() { 14 //2、调用AMS的start函数 15 mService.start(); 16 } 17 18 public ActivityManagerService getService() { 19 return mService; 20 } 21 }
接下来我们分别看看AMS的构造函数和start函数。
AMS的构造函数
1 public ActivityManagerService(Context systemContext) { 2 //AMS的运行上下文与SystemServer一致 3 mContext = systemContext; 4 ............ 5 //取出的是ActivityThread的静态变量sCurrentActivityThread 6 //这意味着mSystemThread与SystemServer中的ActivityThread一致 7 mSystemThread = ActivityThread.currentActivityThread(); 8 ............ 9 mHandlerThread = new ServiceThread(TAG, 10 android.os.Process.THREAD_PRIORITY_FOREGROUND, false /*allowIo*/); 11 mHandlerThread.start(); 12 //处理AMS中消息的主力 13 mHandler = new MainHandler(mHandlerThread.getLooper()); 14 15 //UiHandler对应于Android中的UiThread 16 mUiHandler = new UiHandler(); 17 18 if (sKillHandler == null) { 19 sKillThread = new ServiceThread(TAG + ":kill", 20 android.os.Process.THREAD_PRIORITY_BACKGROUND, true /* allowIo */); 21 sKillThread.start(); 22 //用于接收消息，杀死进程 23 sKillHandler = new KillHandler(sKillThread.getLooper()); 24 } 25 26 //创建两个BroadcastQueue，前台的超时时间为10s，后台的超时时间为60s 27 mFgBroadcastQueue = new BroadcastQueue(this, mHandler, 28 "foreground", BROADCAST_FG_TIMEOUT, false); 29 mBgBroadcastQueue = new BroadcastQueue(this, mHandler, 30 "background", BROADCAST_BG_TIMEOUT, true); 31 mBroadcastQueues[0] = mFgBroadcastQueue; 32 mBroadcastQueues[1] = mBgBroadcastQueue; 33 34 //创建变量，用于存储信息 35 mServices = new ActiveServices(this); 36 mProviderMap = new ProviderMap(this); 37 mAppErrors = new AppErrors(mContext, this); 38 39 //这一部分，分析BatteryStatsService时提过，进行BSS的初始化 40 File dataDir = Environment.getDataDirectory(); 41 File systemDir = new File(dataDir, "system"); 42 systemDir.mkdirs(); 43 mBatteryStatsService = new BatteryStatsService(systemDir, mHandler); 44 mBatteryStatsService.getActiveStatistics().readLocked(); 45 mBatteryStatsService.scheduleWriteToDisk(); 46 mOnBattery = DEBUG_POWER ? true 47 : mBatteryStatsService.getActiveStatistics().getIsOnBattery(); 48 mBatteryStatsService.getActiveStatistics().setCallback(this); 49 50 //创建ProcessStatsService，感觉用于记录进程运行时的统计信息，例如内存使用情况，写入/proc/stat文件 51 mProcessStats = new ProcessStatsService(this, new File(systemDir, "procstats")); 52 53 //启动Android的权限检查服务，并注册对应的回调接口 54 mAppOpsService = new AppOpsService(new File(systemDir, "appops.xml"), mHandler); 55 mAppOpsService.startWatchingMode(AppOpsManager.OP_RUN_IN_BACKGROUND, null, 56 new IAppOpsCallback.Stub() { 57 @Override public void opChanged(int op, int uid, String packageName) { 58 if (op == AppOpsManager.OP_RUN_IN_BACKGROUND && packageName != null) { 59 if (mAppOpsService.checkOperation(op, uid, packageName) 60 != AppOpsManager.MODE_ALLOWED) { 61 runInBackgroundDisabled(uid); 62 } 63 } 64 } 65 }); 66 67 //用于定义ContentProvider访问指定Uri对应数据的权限，aosp中似乎没有这文件 68 mGrantFile = new AtomicFile(new File(systemDir, "urigrants.xml")); 69 70 //创建多用户管理器 71 mUserController = new UserController(this); 72 73 //获取OpenGL版本 74 GL_ES_VERSION = SystemProperties.getInt("ro.opengles.version", 75 ConfigurationInfo.GL_ES_VERSION_UNDEFINED); 76 ............ 77 //资源配置信息置为默认值 78 mConfiguration.setToDefaults(); 79 mConfiguration.setLocales(LocaleList.getDefault()); 80 mConfigurationSeq = mConfiguration.seq = 1; 81 82 //感觉用于记录进程的CPU使用情况 83 mProcessCpuTracker.init(); 84 85 //解析/data/system/packages-compat.xml文件，该文件用于存储那些需要考虑屏幕尺寸的APK的一些信息 86 //当APK所运行的设备不满足要求时，AMS会根据xml设置的参数以采用屏幕兼容的方式运行该APK 87 mCompatModePackages = new CompatModePackages(this, systemDir, mHandler); 88 89 //用于根据规则过滤一些Intent 90 mIntentFirewall = new IntentFirewall(new IntentFirewallInterface(), mHandler); 91 92 //以下的类，似乎用于管理和监控AMS维护的Activity Task信息 93 //ActivityStackSupervisor是AMS中用来管理Activity启动和调度的核心类 94 mStackSupervisor = new ActivityStackSupervisor(this); 95 mActivityStarter = new ActivityStarter(this, mStackSupervisor); 96 mRecentTasks = new RecentTasks(this, mStackSupervisor); 97 98 //创建线程用于统计进程的CPU使用情况 99 mProcessCpuThread = new Thread("CpuTracker") { 100 @Override 101 public void run() { 102 while (true) { 103 try { 104 try { 105 //计算更新信息的等待间隔 106 //同时利用wait等待计算出的间隔时间 107 ...... 108 } catch(InterruptedException e) { 109 } 110 //更新CPU运行统计信息 111 updateCpuStatsNow(); 112 } catch (Exception e) { 113 .......... 114 } 115 } 116 } 117 }; 118 119 //加入Watchdog的监控 120 Watchdog.getInstance().addMonitor(this); 121 Watchdog.getInstance().addThread(mHandler); 122 }
从代码来看，AMS的构造函数还是相对比较简单的，主要工作就是初始化一些变量。
大多数变量的用途，从命名上基本可以推测出来，实际的使用情况必须结合具体的场景才能进一步了解。
AMS的start函数
1 private void start() { 2 //完成统计前的复位工作 3 Process.removeAllProcessGroups(); 4 5 //开始监控进程的CPU使用情况 6 mProcessCpuThread.start(); 7 8 //注册服务 9 mBatteryStatsService.publish(mContext); 10 mAppOpsService.publish(mContext); 11 Slog.d("AppOps", "AppOpsService published"); 12 LocalServices.addService(ActivityManagerInternal.class, new LocalService()); 13 }
AMS的start函数比较简单，主要是：
1、启动CPU监控线程。该线程将会开始统计不同进程使用CPU的情况。
2、发布一些服务，如BatteryStatsService、AppOpsService(权限管理相关)和本地实现的继承ActivityManagerInternal的服务。
至此AMS初始化相关的内容基本结束，从这些代码可以看出AMS涉及的类比较多，我们目前无法一一详述每个类的具体用途。
有机会遇到具体的场景时，再深入分析，此处有个大致印象即可。
2.3 将SystemServer纳入AMS的管理体系
2.3.1 setSystemProcess
AMS完成启动后，在SystemServer的startBootstrapServices函数中，
下一个与AMS相关的重要调用就是AMS.setSystemProcess了：
1 private void startBootstrapServices() { 2 ........... 3 // Set up the Application instance for the system process and get started. 4 mActivityManagerService.setSystemProcess(); 5 ........... 6 }
我们跟进一下setSystemProcess函数：
1 public void setSystemProcess() { 2 try { 3 //以下是向ServiceManager注册几个服务 4 5 //AMS自己 6 ServiceManager.addService(Context.ACTIVITY_SERVICE, this, true); 7 8 //注册进程统计信息的服务 9 ServiceManager.addService(ProcessStats.SERVICE_NAME, mProcessStats); 10 11 //用于打印内存信息用的 12 ServiceManager.addService("meminfo", new MemBinder(this)); 13 14 //用于输出进程使用硬件渲染方面的信息 15 ServiceManager.addService("gfxinfo", new GraphicsBinder(this)); 16 17 //用于输出数据库相关的信息 18 ServiceManager.addService("dbinfo", new DbBinder(this)); 19 20 //MONITOR_CPU_USAGE默认为true 21 if (MONITOR_CPU_USAGE) { 22 //用于输出进程的CPU使用情况 23 ServiceManager.addService("cpuinfo", new CpuBinder(this)); 24 } 25 26 //注册权限管理服务 27 ServiceManager.addService("permission", new PermissionController(this)); 28 29 //注册获取进程信息的服务 30 ServiceManager.addService("processinfo", new ProcessInfoService(this)); 31 32 //1、向PKMS查询package名为“android”的应用的ApplicationInfo 33 ApplicationInfo info = mContext.getPackageManager().getApplicationInfo( 34 "android", STOCK_PM_FLAGS | MATCH_SYSTEM_ONLY); 35 36 //2、调用installSystemApplicationInfo 37 mSystemThread.installSystemApplicationInfo(info, getClass().getClassLoader()); 38 39 //3、以下与AMS的进程管理有关 40 synchronized (this) { 41 ProcessRecord app = newProcessRecordLocked(info, info.processName, false, 0); 42 app.persistent = true; 43 app.pid = MY_PID; 44 app.maxAdj = ProcessList.SYSTEM_ADJ; 45 app.makeActive(mSystemThread.getApplicationThread(), mProcessStats); 46 synchronized (mPidsSelfLocked) { 47 mPidsSelfLocked.put(app.pid, app); 48 } 49 updateLruProcessLocked(app, false, null); 50 updateOomAdjLocked(); 51 } 52 } catch (PackageManager.NameNotFoundException e) { 53 throw new RuntimeException( 54 "Unable to find android system package", e); 55 } 56 }
从上面的代码可以看出，AMS的setSystemProcess主要有四个主要的功能：
- 1、注册一些服务；
- 2、获取package名为“android”的应用的ApplicationInfo；
- 3、调用ActivityThread的installSystemApplicationInfo；
- 4、AMS进程管理相关的操作。
这四个主要的功能中，第一个比较简单，就是用Binder通信完成注册。
我们主要看看后三个功能对应的流程。
功能二，获取ApplicationInfo
如前所述，这部分相关的代码为：
1 .......... 2 ApplicationInfo info = mContext.getPackageManager().getApplicationInfo( 3 "android", STOCK_PM_FLAGS | MATCH_SYSTEM_ONLY); 4 ..........
我们先看看mContext.getPackageManager()的操作过程。
我们已经知道mContext的实现类是ContextImpl，其中对应的代码如下：
1 @Override 2 public PackageManager getPackageManager() { 3 if (mPackageManager != null) { 4 return mPackageManager; 5 } 6 7 //依赖于ActivityThread的getPackageManager函数 8 IPackageManager pm = ActivityThread.getPackageManager(); 9 if (pm != null) { 10 // Doesn't matter if we make more than one instance. 11 //利用PKMS的代理对象，构建ApplicationPackageManager 12 //该类继承PackageManager 13 return (mPackageManager = new ApplicationPackageManager(this, pm)); 14 } 15 16 return null; 17 }
跟进一下ActivityThread中的getPackageManager：
1 public static IPackageManager getPackageManager() { 2 if (sPackageManager != null) { 3 //Slog.v("PackageManager", "returning cur default = " + sPackageManager); 4 return sPackageManager; 5 } 6 //依赖于Binder通信，获取到PKMS对应的BpBinder 7 IBinder b = ServiceManager.getService("package"); 8 ..................... 9 //得到PKMS对应的Binder服务代理 10 sPackageManager = IPackageManager.Stub.asInterface(b); 11 .................... 12 return sPackageManager; 13 }
从上面的代码我们可以看到，AMS获取PKMS用到了Binder通信。
实际上，PKMS由SystemServer创建，与AMS运行在同一个进程，AMS完全可以不经过Context、ActivityThread、Binder来获取PKMS。
根据一些资料，推断出原生代码这么做的原因是：
SystemServer进程中的服务，也使用Android运行环境来交互， 保留了组件之间交互接口的统一，为未来的系统保留了可扩展性。
得到PKMS的代理对象后，AMS调用PKMS的getApplicationInfo接口，获取package名为”android”的ApplicationInfo。
在AMS的setSystemProcess被调用前，PKMS已经启动了。
之前分析PKMS的博客中，我们已经提到，在PKMS的构造函数中，它将解析手机中所有的AndroidManifest.xml，然后形成各种数据结构以维护应用的信息。
getApplicationInfo就是通过package名，从对应的数据结构中，取出对应的应用信息，这部分内容主要就是查询数据结构的内容，不作深入分析。
功能三，installSystemApplicationInfo
得到framework-res.apk对应的ApplicationInfo后，需要将这部分ApplicationInfo保存到SystemServer对应的ActivityThread中。
这部分对应的代码为：
1 .............. 2 mSystemThread.installSystemApplicationInfo(info, getClass().getClassLoader()); 3 ..............
AMS中的mSystemThread就是SystemServer中创建出的ActivityThread。
因此我们跟进一下ActivityThread的installSystemApplicationInfo函数：
1 public void installSystemApplicationInfo(ApplicationInfo info, ClassLoader classLoader) { 2 synchronized (this) { 3 //调用SystemServer中创建出的ContextImpl的installSystemApplicationInfo函数 4 getSystemContext().installSystemApplicationInfo(info, classLoader); 5 6 // give ourselves a default profiler 7 //创建一个Profiler对象，用于性能统计 8 mProfiler = new Profiler(); 9 } 10 }
继续跟进ContextImpl的installSystemApplicationInfo函数：
1 void installSystemApplicationInfo(ApplicationInfo info, ClassLoader classLoader) { 2 //前面已经提到过mPackageInfo的类型为LoadedApk 3 mPackageInfo.installSystemApplicationInfo(info, classLoader); 4 }
随着流程进入到LoadedApk：
1 /** 2 * Sets application info about the system package. 3 */ 4 void installSystemApplicationInfo(ApplicationInfo info, ClassLoader classLoader) { 5 //这个接口仅供系统进程调用，故这里断言一下 6 assert info.packageName.equals("android"); 7 8 mApplicationInfo = info; 9 mClassLoader = classLoader; 10 }
至此，我们知道了installSystemApplicationInfo的真相就是：
将“android”对应的ApplicationInfo（即framework-res.apk对应的ApplicationInfo），
加入到SystemServer之前调用createSystemContext时，创建出的LoadedApk中。
毕竟SystemServer创建System Context时，PKMS并没有完成对手机中文件的解析，初始的LoadedApk中并没有持有有效的ApplicationInfo。
在此基础上，AMS下一步的工作就呼之欲出了。
由于framework-res.apk运行在SystemServer进程中，而AMS是专门用于进程管理和调度的，因此SystemServer进程也应该在AMS中有对应的管理结构。
于是，AMS的下一步工作就是将SystemServer的运行环境和一个进程管理结构对应起来，并进行统一的管理。
功能四， AMS进程管理
注意到上面的ContentProvider注册到AMS后，进行了notifyAll的操作。
举例来说：进程A需要查询一个数据库，需要通过进程B中的某个ContentProvider来实施。
如果B还未启动，那么AMS就需要先启动B。在这段时间内，A需要等待B启动并注册对应的ContentProvider。
B一旦完成ContentProvider的注册，就需要告知A退出等待以继续后续的查询工作。
setSystemProcess函数中，进程管理相关的代码为：
1 ............. 2 synchronized (this) { 3 //创建进程管理对应的结构ProcessRecord 4 ProcessRecord app = newProcessRecordLocked(info, info.processName, false, 0); 5 6 //由于此时创建的是SystemServer进程对应ProcessRecord 7 //因此设定了一些特殊值 8 app.persistent = true; 9 app.pid = MY_PID; 10 app.maxAdj = ProcessList.SYSTEM_ADJ; 11 12 //将SystemServer对应的ApplicationThread保存到ProcessRecord中 13 app.makeActive(mSystemThread.getApplicationThread(), mProcessStats); 14 15 synchronized (mPidsSelfLocked) { 16 //按pid将ProcessRecord保存到mPidsSelfLocked中 17 mPidsSelfLocked.put(app.pid, app); 18 } 19 20 //updateLruProcessLocked来调整进程在mLruProcess列表的位置 21 //在这个列表中，最近活动过得进程总是位于前列，同时拥有Activity的进程位置总是前于只有Service的进程 22 updateLruProcessLocked(app, false, null); 23 24 //更新进程对应的oom_adj值(oom_adj将决定进程是否被kill掉） 25 updateOomAdjLocked(); 26 } 27 ...............
这里我们仅分析一下创建进程管理结构的函数newProcessRecordLocked。
updateLruProcessLocked和updateOomAdjLocked函数比较复杂，等对AMS有更多的了解后，再做分析。
1 final ProcessRecord newProcessRecordLocked(ApplicationInfo info, String customProcess, 2 boolean isolated, int isolatedUid) { 3 //进程的名称 4 String proc = customProcess != null ? customProcess : info.processName; 5 6 //将用于创建该进程的电源统计项 7 BatteryStatsImpl stats = mBatteryStatsService.getActiveStatistics(); 8 9 final int userId = UserHandle.getUserId(info.uid); 10 //isolated此时为false 11 if (isolated) { 12 .......... 13 } 14 //创建出对应的存储结构 15 final ProcessRecord r = new ProcessRecord(stats, info, proc, uid); 16 17 //判断进程是否常驻 18 if (!mBooted && !mBooting 19 && userId == UserHandle.USER_SYSTEM 20 && (info.flags & PERSISTENT_MASK) == PERSISTENT_MASK) { 21 r.persistent = true; 22 } 23 24 //按进程名将ProcessRecord存入到AMS的变量mProcessNames中 25 //该变量的类型为ProcessMap<ProcessRecord> 26 //结合前面的代码，我们知道AMS有两种方式可以取到ProcessRecord 27 //一是根据进程名，二是根据进程名称 28 addProcessNameLocked(r); 29 return r; 30 }
跟进一下ProcessRecord的构造函数：
1 ProcessRecord(BatteryStatsImpl _batteryStats, ApplicationInfo _info, 2 String _processName, int _uid) { 3 mBatteryStats = _batteryStats; //用于电量统计 4 info = _info; //保存ApplicationInfo 5 ........... 6 processName = _processName; //保存进程名 7 8 //一个进程能运行多个Package，pkgList用于保存package名 9 pkgList.put(_info.packageName, new ProcessStats.ProcessStateHolder(_info.versionCode)); 10 11 //以下变量和进程调度优先级有关 12 maxAdj = ProcessList.UNKNOWN_ADJ; 13 curRawAdj = setRawAdj = ProcessList.INVALID_ADJ; 14 curAdj = setAdj = verifiedAdj = ProcessList.INVALID_ADJ; 15 16 //决定进程是否常驻内存（即使被杀掉，系统也会重启它） 17 persistent = false; 18 19 removed = false; 20 lastStateTime = lastPssTime = nextPssTime = SystemClock.uptimeMillis(); 21 }
总结
至此，我们对AMS的setSystemProcess函数分析告一段落。
从上面的代码可以看出，在这个函数中除了发布一些服务外，主要是：
将framework-res.apk的信息加入到SystemServer对应的LoadedApk中，同时构建SystemServer进程对应的ProcessRecord，
以将SystemServer进程纳入到AMS的管理中。
2.3.2 AMS的installSystemProviders
接下来AMS启动相关的操作，定义于SystemServer的startOtherServices函数中。
1 private void startOtherServices() { 2 ........... 3 mActivityManagerService.installSystemProviders(); 4 ........... 5 }
我们跟进一下AMS的installSystemProviders函数：
1 public final void installSystemProviders() { 2 List<ProviderInfo> providers; 3 synchronized (this) { 4 //AMS根据进程名取出SystemServer对应的ProcessRecord 5 ProcessRecord app = mProcessNames.get("system", Process.SYSTEM_UID); 6 7 //1、得到该ProcessRecord对应的ProviderInfo 8 providers = generateApplicationProvidersLocked(app); 9 10 //这里仅处理系统级的Provider 11 if (providers != null) { 12 for (int i=providers.size()-1; i>=0; i--) { 13 ProviderInfo pi = (ProviderInfo)providers.get(i); 14 if ((pi.applicationInfo.flags&ApplicationInfo.FLAG_SYSTEM) == 0) { 15 Slog.w(TAG, "Not installing system proc provider " + pi.name 16 + ": not system .apk"); 17 providers.remove(i); 18 } 19 } 20 } 21 } 22 } 23 24 if (providers != null) { 25 //2、安装Provider 26 mSystemThread.installSystemProviders(providers); 27 } 28 29 //创建ContentObserver监控Settings数据库中Secure、System和Global表的变化 30 mCoreSettingsObserver = new CoreSettingsObserver(this); 31 32 //创建ContentObserver监控Settings数据库中字体大小的变化 33 mFontScaleSettingObserver = new FontScaleSettingObserver(); 34 }
从上面的代码可以看出，installSystemProviders主要是加载运行在SystemServer进程中的 ContentProvider，即SettingsProvider.apk (定义于frameworks/base/packages/SettingsProvider)。
上面有两个比较重要的函数：
1、generateApplicationProvidersLocked返回一个进程对应的ProviderInfo List。
2、ActivityThread可以看做是进程的Android运行环境，因此它的installSystemProviders表示为对应进程安装ContentProvider。
当SettingsProvider被加载到SystemServer进程中运行后，AMS就注册了两个ContentObserver监控SettingsProvider中的字段变化。
AMS监控的字段影响范围比较广，例如字体发生变化时，很多应用的显示界面都需要做出调整。
这也许就是让AMS来负责监控这些字段的原因。
2.4 AMS的systemReady
接下来，我们看看AMS启动的最后一部分：systemReady。
该函数在SystemServer中startOtherServices的最后被调用：
1 private void startOtherServices() { 2 ............ 3 // We now tell the activity manager it is okay to run third party 4 // code. It will call back into us once it has gotten to the state 5 // where third party code can really run (but before it has actually 6 // started launching the initial applications), for us to complete our 7 // initialization. 8 mActivityManagerService.systemReady(new Runnable() { 9 .............. 10 }); 11 }
我们分段看看AMS中systemReady的处理流程。
此处的分段并没有实际的意义，只是代码确实太长了，并且连续性不够，因此分开描述。
阶段一
1 public void systemReady(final Runnable goingCallback) { 2 synchronized(this) { 3 .......... 4 //这一部分主要是调用一些关键服务SystemReady相关的函数， 5 //进行一些等待AMS初始完，才能进行的工作 6 7 // Make sure we have the current profile info, since it is needed for security checks. 8 mUserController.onSystemReady(); 9 10 mRecentTasks.onSystemReadyLocked(); 11 mAppOpsService.systemReady(); 12 mSystemReady = true; 13 } 14 15 ArrayList<ProcessRecord> procsToKill = null; 16 synchronized(mPidsSelfLocked) { 17 //mPidsSelfLocked中保存当前正在运行的所有进程的信息 18 for (int i=mPidsSelfLocked.size()-1; i>=0; i--) { 19 ProcessRecord proc = mPidsSelfLocked.valueAt(i); 20 21 //在AMS启动完成前，如果没有FLAG_PERSISTENT标志的进程已经启动了， 22 //就将这个进程加入到procsToKill中 23 if (!isAllowedWhileBooting(proc.info)){ 24 if (procsToKill == null) { 25 procsToKill = new ArrayList<ProcessRecord>(); 26 } 27 procsToKill.add(proc); 28 } 29 } 30 } 31 32 synchronized(this) { 33 //利用removeProcessLocked关闭procsToKill中的进程 34 if (procsToKill != null) { 35 for (int i=procsToKill.size()-1; i>=0; i--) { 36 ProcessRecord proc = procsToKill.get(i); 37 Slog.i(TAG, "Removing system update proc: " + proc); 38 removeProcessLocked(proc, true, false, "system update done"); 39 } 40 } 41 42 // Now that we have cleaned up any update processes, we 43 // are ready to start launching real processes and know that 44 // we won't trample on them any more. 45 46 //至此系统准备完毕 47 mProcessesReady = true; 48 } 49 ............ 50 //根据数据库和资源文件，获取一些配置参数 51 retrieveSettings(); 52 53 final int currentUserId; 54 synchronized (this) { 55 //得到当前的用户ID 56 currentUserId = mUserController.getCurrentUserIdLocked(); 57 58 //读取urigrants.xml，为其中定义的ContentProvider配置对指定Uri数据的访问/修改权限 59 //原生代码中，似乎没有urigrants.xml文件 60 //实际使用的grant-uri-permission是分布式定义的 61 readGrantedUriPermissionsLocked(); 62 } 63 ..........
这一部分的工作主要是调用一些关键服务的初始化函数，
然后杀死那些没有FLAG_PERSISTENT却在AMS启动完成前已经存在的进程，
同时获取一些配置参数。
需要注意的是，由于只有Java进程才会向AMS注册，而一般的Native进程不会向AMS注册，因此此处杀死的进程是Java进程。
阶段二
1 //1、调用参数传入的runnable对象，SystemServer中有具体的定义 2 if (goingCallback != null) goingCallback.run(); 3 .............. 4 //调用所有系统服务的onStartUser接口 5 mSystemServiceManager.startUser(currentUserId); 6 ............. 7 synchronized (this) { 8 // Only start up encryption-aware persistent apps; once user is 9 // unlocked we'll come back around and start unaware apps 10 2、启动persistent为1的application所在的进程 11 startPersistentApps(PackageManager.MATCH_DIRECT_BOOT_AWARE); 12 13 // Start up initial activity. 14 mBooting = true; 15 16 // Enable home activity for system user, so that the system can always boot 17 //当isSplitSystemUser返回true时，意味者system user和primary user是分离的 18 //这里应该是让system user也有启动home activity的权限吧 19 if (UserManager.isSplitSystemUser()) { 20 ComponentName cName = new ComponentName(mContext, SystemUserHomeActivity.class); 21 try { 22 AppGlobals.getPackageManager().setComponentEnabledSetting(cName, 23 PackageManager.COMPONENT_ENABLED_STATE_ENABLED, 0, 24 UserHandle.USER_SYSTEM); 25 } catch (RemoteException e) { 26 throw e.rethrowAsRuntimeException(); 27 } 28 } 29 30 //3、启动Home 31 startHomeActivityLocked(currentUserId, "systemReady"); 32 33 try { 34 //发送消息，触发处理Uid错误的Application 35 if (AppGlobals.getPackageManager().hasSystemUidErrors()) { 36 .......... 37 mUiHandler.obtainMessage(SHOW_UID_ERROR_UI_MSG).sendToTarget(); 38 } 39 } catch (RemoteException e) { 40 } 41 //发送一些广播信息 42 ............ 43 //这里暂时先不深入，等进一步了解Activity的启动过程后，再做了解 44 mStackSupervisor.resumeFocusedStackTopActivityLocked(); 45 ............ 46 } 47 .............
从部分代码来看，主要的工作就是通知一些服务可以进行systemReady相关的工作，并进行启动服务或应用进程的工作。
2.4.1 调用回调接口
回调接口的具体内容定义与SystemServer.java中，其中会调用大量服务的onBootPhase函数、一些对象的systemReady函数或systemRunning函数。
此处，我们仅截取一些比较特别的内容：
1 public void run() { 2 ............ 3 try { 4 //启动NativeCrashListener监听"/data/system/ndebugsocket"中的信息 5 //实际上是监听debuggerd传入的信息 6 mActivityManagerService.startObservingNativeCrashes(); 7 } catch (Throwable e) { 8 reportWtf("observing native crashes", e); 9 } 10 ............ 11 try { 12 //启动SystemUi 13 startSystemUi(context); 14 } catch (Throwable e) { 15 reportWtf("starting System UI", e); 16 } 17 ............ 18 //这个以前分析过，启动Watchdog 19 Watchdog.getInstance().start(); 20 .................... 21 }
回调接口中的内容较多，不做一一分析。
2.4.2 启动persistent标志的进程
我们看看startPersistentApps对应的内容：
1 private void startPersistentApps(int matchFlags) { 2 ............. 3 4 synchronized (this) { 5 try { 6 //从PKMS中得到persistent为1的ApplicationInfo 7 final List<ApplicationInfo> apps = AppGlobals.getPackageManager() 8 .getPersistentApplications(STOCK_PM_FLAGS | matchFlags).getList(); 9 for (ApplicationInfo app : apps) { 10 //由于framework-res.apk已经由系统启动，所以此处不再启动它 11 if (!"android".equals(app.packageName)) { 12 //addAppLocked中将启动application所在进程 13 addAppLocked(app, false, null /* ABI override */); 14 } 15 } 16 } catch (RemoteException ex) { 17 } 18 } 19 }
跟进一下addAppLocked函数：
1 final ProcessRecord addAppLocked(ApplicationInfo info, boolean isolated, 2 String abiOverride) { 3 //以下是取出或构造出ApplicationInfo对应的ProcessRecord 4 ProcessRecord app; 5 if (!isolated) { 6 app = getProcessRecordLocked(info.processName, info.uid, true); 7 } else { 8 app = null; 9 } 10 11 if (app == null) { 12 app = newProcessRecordLocked(info, null, isolated, 0); 13 updateLruProcessLocked(app, false, null); 14 updateOomAdjLocked(); 15 } 16 ........... 17 // This package really, really can not be stopped. 18 try { 19 //通过PKMS将package对应数据结构的StoppedState置为fasle 20 AppGlobals.getPackageManager().setPackageStoppedState( 21 info.packageName, false, UserHandle.getUserId(app.uid)); 22 } catch (RemoteException e) { 23 } catch (IllegalArgumentException e) { 24 Slog.w(TAG, "Failed trying to unstop package " 25 + info.packageName + ": " + e); 26 } 27 28 if ((info.flags & PERSISTENT_MASK) == PERSISTENT_MASK) { 29 app.persistent = true; 30 app.maxAdj = ProcessList.PERSISTENT_PROC_ADJ; 31 } 32 33 if (app.thread == null && mPersistentStartingProcesses.indexOf(app) < 0) { 34 mPersistentStartingProcesses.add(app); 35 //启动应用所在进程，将发送消息给zygote，后者fork出进程 36 startProcessLocked(app, "added application", app.processName, abiOverride, 37 null /* entryPoint */, null /* entryPointArgs */); 38 } 39 40 return app; 41 }
这里最终将通过startProcessLocked函数，启动实际的应用进程。
正如之前分析zygote进程时，提过的一样，zygote中的server socket将接收消息，然后为应用fork出进程。
2.4.3 启动Home Activity
看看启动Home Activity对应的startHomeActivityLocked函数：
1 boolean startHomeActivityLocked(int userId, String reason) { 2 .............. 3 Intent intent = getHomeIntent(); 4 //根据intent中携带的ComponentName，利用PKMS得到ActivityInfo 5 ActivityInfo aInfo = resolveActivityInfo(intent, STOCK_PM_FLAGS, userId); 6 if (aInfo != null) { 7 intent.setComponent(new ComponentName(aInfo.applicationInfo.packageName, aInfo.name)); 8 aInfo = new ActivityInfo(aInfo); 9 aInfo.applicationInfo = getAppInfoForUser(aInfo.applicationInfo, userId); 10 11 //此时home对应进程应该还没启动，app为null 12 ProcessRecord app = getProcessRecordLocked(aInfo.processName, 13 aInfo.applicationInfo.uid, true); 14 if (app == null || app.instrumentationClass == null) { 15 intent.setFlags(intent.getFlags() | Intent.FLAG_ACTIVITY_NEW_TASK); 16 //启动home 17 mActivityStarter.startHomeActivityLocked(intent, aInfo, reason); 18 } 19 } else { 20 .......... 21 } 22 return true; 23 }
这里暂时先不深究Home Activity启动的具体过程。
从手头的资料来看，当Home Activity启动后，
ActivityStackSupervisor中的activityIdleInternalLocked函数将被调用（具体调用过程，还需要研究）：
1 final ActivityRecord activityIdleInternalLocked(final IBinder token, boolean fromTimeout, 2 Configuration config) { 3 ........... 4 if (isFocusedStack(r.task.stack) || fromTimeout) { 5 booting = checkFinishBootingLocked(); 6 } 7 ............ 8 }
在checkFinishBootingLocked函数中：
1 private boolean checkFinishBootingLocked() { 2 //mService为AMS，mBooting变量在AMS回调SystemServer中定义的Runnable时，置为了true 3 final boolean booting = mService.mBooting; 4 boolean enableScreen = false; 5 mService.mBooting = false; 6 if (!mService.mBooted) { 7 mService.mBooted = true; 8 enableScreen = true; 9 } 10 if (booting || enableScreen) {、 11 //调用AMS的接口，发送消息 12 mService.postFinishBooting(booting, enableScreen); 13 } 14 return booting; 15 }
最终，AMS的finishBooting函数将被调用：
1 final void finishBooting() { 2 ......... 3 //以下是注册广播接收器，用于处理需要重启的package 4 IntentFilter pkgFilter = new IntentFilter(); 5 pkgFilter.addAction(Intent.ACTION_QUERY_PACKAGE_RESTART); 6 pkgFilter.addDataScheme("package"); 7 mContext.registerReceiver(new BroadcastReceiver() { 8 @Override 9 public void onReceive(Context context, Intent intent) { 10 String[] pkgs = intent.getStringArrayExtra(Intent.EXTRA_PACKAGES); 11 if (pkgs != null) { 12 for (String pkg : pkgs) { 13 synchronized (ActivityManagerService.this) { 14 if (forceStopPackageLocked(pkg, -1, false, false, false, false, false, 15 0, "query restart")) { 16 setResultCode(Activity.RESULT_OK); 17 return; 18 } 19 } 20 } 21 } 22 } 23 }, pkgFilter); 24 ........... 25 // Let system services know. 26 mSystemServiceManager.startBootPhase(SystemService.PHASE_BOOT_COMPLETED); 27 28 //以下是启动那些等待启动的进程 29 synchronized (this) { 30 // Ensure that any processes we had put on hold are now started 31 // up. 32 final int NP = mProcessesOnHold.size(); 33 if (NP > 0) { 34 ArrayList<ProcessRecord> procs = 35 new ArrayList<ProcessRecord>(mProcessesOnHold); 36 for (int ip=0; ip<NP; ip++) { 37 ................. 38 startProcessLocked(procs.get(ip), "on-hold", null); 39 } 40 } 41 } 42 } 43 .............. 44 if (mFactoryTest != FactoryTest.FACTORY_TEST_LOW_LEVEL) { 45 // Start looking for apps that are abusing wake locks. 46 //每15min检查一次系统各应用进程使用电量的情况，如果某个进程使用WakeLock的时间过长 47 //AMS将关闭该进程 48 Message nmsg = mHandler.obtainMessage(CHECK_EXCESSIVE_WAKE_LOCKS_MSG); 49 mHandler.sendMessageDelayed(nmsg, POWER_CHECK_DELAY); 50 51 // Tell anyone interested that we are done booting! 52 SystemProperties.set("sys.boot_completed", "1"); 53 ................. 54 //此处从代码来看发送的是ACTION_LOCKED_BOOT_COMPLETED广播 55 //在进行unlock相关的工作后，mUserController将调用finishUserUnlocking，发送SYSTEM_USER_UNLOCK_MSG消息给AMS 56 //AMS收到消息后，调用mUserController的finishUserUnlocked函数，经过相应的处理后， 57 //在mUserController的finishUserUnlockedCompleted中，最终将会发送ACTION_BOOT_COMPLETED广播 58 mUserController.sendBootCompletedLocked(.........); 59 ................. 60 } 61 }
最终，当AMS启动Home Activity结束，并发送ACTION_BOOT_COMPLETED广播时，AMS的启动过程告一段落。
总结图
1490
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
