转https://www.jianshu.com/p/8d4e17836322
下边这个图是7.0 的
AMS类的结构，copy自网络
1.看得出AMS 实现了看门狗(Watchdog.Monitor)以及电量监控(BatteryStatsImpl.BatteryCallback) 接口，并且继承了ActivityManagerNative 2.ActivityManagerNative实现了IActivityManager，使用Binder来跟应用程序进行通信，只不过这里AMN内部增加了一个代理类解藕，最终其他进程要跟AMS交互还是使用Binder机制。 这里很好玩的是8.0系统上ActivityManagerNative上已经被delete
/** * {@hide} * @deprecated will be removed soon. See individual methods for alternatives. */ @Deprecated public abstract class ActivityManagerNative而且本身的AMS的继承类也相应的变化了：
public class ActivityManagerService extends IActivityManager.Stub implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback这里的它的区别是继承了IActivityManager.Stub 接口类，了解Bindler机制的人应该知道此处应该是一个IActivityManager.aidl生成的java类。只不过这里android可能删除了ActivityManagerNative这个类，并把一些Binder代码转化为了AIDL模版方式。 可以看下下边两个sdk中的代码： 8.0上： ActivityManagerNative.class中的代码：
/** * Retrieve the system's default/global activity manager. * * @deprecated use ActivityManager.getService instead. */ static public IActivityManager getDefault() { return ActivityManager.getService(); }ActivityManager.class 中的代码:
public static IActivityManager getService() { return IActivityManagerSingleton.get(); } 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; } };7.0上： ActivityManagerNative.class中的代码：
/** *获得IActivityManager类 */ static public IActivityManager getDefault() { return gDefault.get(); } static public IActivityManager asInterface(IBinder obj) { if (obj == null) { return null; } IActivityManager in = (IActivityManager)obj.queryLocalInterface(descriptor); if (in != null) { return in; } return new ActivityManagerProxy(obj);ActivityManager.class 中的代码:
private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() { protected IActivityManager create() { IBinder b = ServiceManager.getService("activity"); if (false) { Log.v("ActivityManager", "default service binder = " + b); } IActivityManager am = asInterface(b);//注意这一行 if (false) { Log.v("ActivityManager", "default service = " + am); } return am; } };可以看得出来，两个的写法不一样，本质上都是一样的，只不过这里android可能使用了统一的AIDL方式进行ipc，减少了代码的维护。所以我们在写ipc的时候还是使用aidl模版比较好，利于维护。
好了有点扯远了，回到正题上AMS的启动过程：
AMS的启动是在SystemServer(系统进程)中进行启动的，我们知道android所有的进程都是由zygote fork出来的，SystemServer也不例外。下边捋一下SystemServer的代码：
SystemServer
/** * The main entry point from zygote. */ //很清楚看到是由zygote进程fork来的 public static void main(String[] args) { new SystemServer().run(); }run方法：
private void run() { .... (1) Looper.prepareMainLooper(); // Initialize native services. System.loadLibrary("android_servers"); .... (2) // Initialize the system context. createSystemContext(); (3) // Create the system service manager. mSystemServiceManager = new SystemServiceManager(mSystemContext); mSystemServiceManager.setRuntimeRestarted(mRuntimeRestart); LocalServices.addService(SystemServiceManager.class, mSystemServiceManager); .... (4) // Start services. try { traceBeginAndSlog("StartServices"); startBootstrapServices(); startCoreServices(); startOtherServices(); SystemServerInitThreadPool.shutdown(); } catch (Throwable ex) { Slog.e("System", "******************************************"); Slog.e("System", "************ Failure starting system services", ex); throw ex; } finally { traceEnd(); } .... // Loop forever. Looper.loop(); (5) throw new RuntimeException("Main thread loop unexpectedly exited"); } (1).Looper.prepareMainLooper();方法：初始化MainLooper,这里可以看得出我们这个SystemServer本身可能就是一个应用进程。 这里稍微扩展一下Looper.prepareMainLooper()函数是创建了一个全局静态的sMainLooper,创建函数是：
private static void prepare(boolean quitAllowed) { if (sThreadLocal.get() != null) { throw new RuntimeException("Only one Looper may be created per thread"); } sThreadLocal.set(new Looper(quitAllowed)); }1.这里我当时没想明白是怎么把ActivityThread跟Looper进行绑定的，毕竟ActivityThread是在Looper初始化之后new的，而Looper的new过程是伴随着绑定当前线程的。这里我们一定要注意： ActivityThread不是一个线程，尽管以此命名，我们new的ActivityThread只不过是一个普通类。同时行使主线程的能力罢了。 2.这里的Looper是使用sThreadLocal保证全局唯一的，ThreadLocal也是一个很有意思的类，它可以看作是一个Map的工具类，使用统一的工具类管理各个分散在不同Thread中的ThreadLocalMap，以ThreadLocal为key，管理各个thread中map值，当然这里必须使用弱引用防止内存问题。这种统一管理方式很值得学习。
（2）createSystemContext方法：1.得到了一个ActivityThread对象，它代表当前进程 (此时为系统进程) 的主线程； 2.得到了一个Context对象，对于SystemServer而言，它包含的Application运行环境与framework-res.apk有关。
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); } public static ActivityThread systemMain() { // The system process on low-memory devices do not get to use hardware // accelerated drawing, since this can add too much overhead to the // process. if (!ActivityManager.isHighEndGfx()) { ThreadedRenderer.disable(true); } else { ThreadedRenderer.enableForegroundTrimming(); } ActivityThread thread = new ActivityThread(); thread.attach(true); return thread; } (3)创建SystemServiceManager，它会对系统的服务进行创建、启动和生命周期管理。(5)throw new RuntimeException("Main thread loop unexpectedly exited");这里一种防止Looper quit的一种方式
(4) 启动各种service，这里startBootstrapServices ()方法是初始化AMS的，只需要看此方法即可 private void startBootstrapServices() { .... Installer installer = mSystemServiceManager.startService(Installer.class); .... // Activity manager runs the show. //真正启动AMS的地方 mActivityManagerService = mSystemServiceManager.startService( ActivityManagerService.Lifecycle.class).getService(); mActivityManagerService.setSystemServiceManager(mSystemServiceManager); mActivityManagerService.setInstaller(installer); .... // Set up the Application instance for the system process and get started. //注册一些系统服务 //将framework-res.apk的信息加入到SystemServer对应的LoadedApk中， //同时构建SystemServer进程对应的ProcessRecord， 以将SystemServer进程纳入到AMS的管理中。 mActivityManagerService.setSystemProcess(); .... }可以看出AMS是使用SystemServiceManager(SSM)启动的，SSM启动的service必须继承自final Class<SystemService> serviceClass;,但是这里因为AMS并不是,所以使用了ActivityManagerService.Lifecycle.class类。
public static final class Lifecycle extends SystemService { private final ActivityManagerService mService; public Lifecycle(Context context) { super(context); mService = new ActivityManagerService(context); } @Override public void onStart() { mService.start(); } public ActivityManagerService getService() { return mService; } }很简单这只不过是AMS 的代理类，也是为了解藕，这种启动Service的处理方式蛮特别的。可以学习下SystemServiceManager的源码，这里不做深入。
这里Lifecycle.class中有两步操作 ，
mService = new ActivityManagerService(context); // Note: This method is invoked on the main thread but may need to attach various // handlers to other threads. So take care to be explicit about the looper. public ActivityManagerService(Context systemContext) { ... mServices = new ActiveServices(this); mProviderMap = new ProviderMap(this); mAppErrors = new AppErrors(mUiContext, this); ... Watchdog.getInstance().addMonitor(this); Watchdog.getInstance().addThread(mHandler); }可以看得出来AMS的构造方法中都是一些初始化操作，以及增加了看门狗
mService.start(); private void start() { //完成统计前的复位工作 removeAllProcessGroups(); //开始监控进程的CPU使用情况 mProcessCpuThread.start(); //注册服务 mBatteryStatsService.publish(mContext); mAppOpsService.publish(mContext); Slog.d("AppOps", "AppOpsService published"); LocalServices.addService(ActivityManagerInternal.class, new LocalService()); // Wait for the synchronized block started in mProcessCpuThread, // so that any other acccess to mProcessCpuTracker from main thread // will be blocked during mProcessCpuTracker initialization. try { mProcessCpuInitLatch.await(); } catch (InterruptedException e) { Slog.wtf(TAG, "Interrupted wait during start", e); Thread.currentThread().interrupt(); throw new IllegalStateException("Interrupted wait during start"); } }主要处理了： 1、启动CPU监控线程。该线程将会开始统计不同进程使用CPU的情况。 2、发布一些服务，如BatteryStatsService、AppOpsService(权限管理相关)和本地实现的继承ActivityManagerInternal的服务。
看上边的startBootstrapServices方法中mActivityManagerService.setSystemProcess()方法
public void setSystemProcess() { try { ServiceManager.addService(Context.ACTIVITY_SERVICE, this, true); ServiceManager.addService(ProcessStats.SERVICE_NAME, mProcessStats); ServiceManager.addService("meminfo", new MemBinder(this)); ServiceManager.addService("gfxinfo", new GraphicsBinder(this)); ServiceManager.addService("dbinfo", new DbBinder(this)); if (MONITOR_CPU_USAGE) { ServiceManager.addService("cpuinfo", new CpuBinder(this)); } ServiceManager.addService("permission", new PermissionController(this)); ServiceManager.addService("processinfo", new ProcessInfoService(this)); ApplicationInfo info = mContext.getPackageManager().getApplicationInfo( "android", STOCK_PM_FLAGS | MATCH_SYSTEM_ONLY); mSystemThread.installSystemApplicationInfo(info, getClass().getClassLoader()); synchronized (this) { ProcessRecord app = newProcessRecordLocked(info, info.processName, false, 0); app.persistent = true; app.pid = MY_PID; app.maxAdj = ProcessList.SYSTEM_ADJ; app.makeActive(mSystemThread.getApplicationThread(), mProcessStats); synchronized (mPidsSelfLocked) { mPidsSelfLocked.put(app.pid, app); } updateLruProcessLocked(app, false, null); updateOomAdjLocked(); } } catch (PackageManager.NameNotFoundException e) { throw new RuntimeException( "Unable to find android system package", e); } }此方法中主要处理了 1、注册一些服务； 2、获取package名为“android”的应用的ApplicationInfo； 3、调用ActivityThread的installSystemApplicationInfo； 4、AMS进程管理相关的操作。
这里注意installSystemApplicationInfo ()方法：它主要处理了将package名为“android”的应用的ApplicationInfo;(即framework-res.apk,资源apk)赋值给LoadedApk，这里不详细拆分 在SystemServer.run()下startOtherServices();方法中有一类似的代码mActivityManagerService.installSystemProviders();此方法是加载运行在SystemServer进程中的ContentProvider，即SettingsProvider.apk (定义于frameworks/base/packages/SettingsProvider)。最终ContentProvider信息都将注册到AMS中的mProviderMap集合中。
最后一步SystemSever#startOtherServices中调用ActivityManagerService#systemReady方法
public void systemReady(final Runnable goingCallback, BootTimingsTraceLog traceLog) { ... //通知一些服务可以进行systemReady相关的工作，并进行启动服务或应用进程的工作 ... //开启HomeActivity startHomeActivityLocked(currentUserId, "systemReady"); ... }到此我们的AMS已经启动完全，后续是Activity的启动流程，这里不做讲解。
鉴于时间限制，我就盗用下边的流程图作为总结吧。。。。
AMS的启动流程图
其他：
AMS的通信机制：（使用AIDL）APP向AMS发起进程间通信：(IActivityManager.aidl) ActivityManger.getService() 获得AMS的Binder接口，在通过Stub.asInterface的方式，转成IActivityManager的接口。然后就可以通过IActivityManager向AMS发起进程间通信。
// android/app/Instrumentation.java int result = ActivityManager.getService() .startActivity(whoThread, who.getBasePackageName(), intent, intent.resolveTypeIfNeeded(who.getContentResolver()), token, target, requestCode, 0, null, options); // android/app/ActivityManager.java public static IActivityManager getService() { return IActivityManagerSingleton.get(); } 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向APP发起进程间通信：(IApplication.aidl) 在AMS内部持有每个ActivityThread的IApplication接口实例，用时可以直接调用。当然这里也是Binder通信。 其实在ActivityThread.main()时会调用attach(bool)方法
private void attach(boolean system) { ... if (!system) { ... final IActivityManager mgr = ActivityManager.getService(); try { //将IApplication注册给AMS mgr.attachApplication(mAppThread); } catch (RemoteException ex) { throw ex.rethrowFromSystemServer(); } ... } @Override public final void attachApplication(IApplicationThread thread) { synchronized (this) { ... attachApplicationLocked(thread, callingPid); ... } } private final boolean attachApplicationLocked(IApplicationThread thread, int pid) { ... updateLruProcessLocked(app, false, null); ... final void updateLruProcessLocked(ProcessRecord app, boolean activityChange, ProcessRecord client) { ... //AMS中 final ArrayList<ProcessRecord> mLruProcesses = new ArrayList<ProcessRecord>(); mLruProcesses.add(app); ...反正一系列的方法最后将IApplication传递到了AMS中，等到AMS调用APP时使用。看下图：
AMS跟应用进程通信
AMS本身运行在SystemServer 中，但同时也管理SystemServer（可以看作一个特殊APP）
SettingProvider.apk
SettingProvider.apk 给Settings应用提供设置默认值、设置存储和设置修改服务。其源码在frameworks/base/packages目录下。其apk在设备上的位置:/system/priv-app/SettingsProvider。本次对SettingProvider的修改主要针对一些设置默认值
Framework-res.apk
系统默认的一些资源信息
tag：AMS启动流程，通信机制
