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基本类图，在Client端，我们平常接触的Application，Service和Activity都是Context的子类，Context理解为环境，上下文，也就是它能够告诉系统当前我运行的Activity，Service的情况，显示那些View，干那些活等。Context是一个abstract类，定义的方法具体实现在ContextImpl中，ContextWrapper作为Context的装饰类，里面的成员变量mBase指向ContextImpl，当然这儿并不是一定要执行ContextImpl，只要是继承了Context，实现了里面定义的接口，都可以实例化mBase对象。
    另外我们注意到我们调用很多Android的接口，必须要传入Context对象，通常我们直接将Activity对象作为参数传入，如果方法内部定义全局变量或者static的变量，导致长期占用mContext引用，这就会导致Activity对象无法被JVM回收，对此这样的引用占用，很可能导致OOM。我们注意到Application也是继承自Context，所以Application也是Context，我们知道Application在一个应用启动时就创建，所以我们的app一直存在着全局的Context对象——Application对象，那么我们在一些已知的全局占用Context对象引用的方法调用上可以传递Application对象来避免上面所说的OOM。
    IActivityManager接口定义了app访问AmS的接口，主要是应用请求AmS要完成某些操作，比如启动、finish某个Activity，启动、stop某个Service。ActivityManagerService实现了IActivityManager中定义的接口，该类可以说是AmS的核心，AmS的所有具体工作基本上都在该类中或者通过该类控制，ActivityManagerService的实例在进程SystemServer刚启动时初始化。IApplicationThread接口定义了AmS可以访问app的接口，AmS通过这些接口控制app进程以及完成app的响应，ApplicationThread是IApplicationThread接口的具体实现，ApplicationThread的实例是在app进程启动时创建ActivityThread对象时初始化，ActivityThread的成员变量mAppThread就是ApplicationThread对象。另外为了实现跨进程调用，ActivityManagerProxy和ApplicationThreadProxy分别实现了IActivityManager和IApplicationThread接口，其作为各自的代理供client和server使用。
     AmS也是作为一个系统服务，通过ActivityManager定义了一些借口可以供app使用，ActivityManager中访问AmS的接口都是通过ApplicationThreadProxy实现的。
     如下图是AmS内部主要数据结构类图，看了code相信大家都会知道这些类都是干什么的，这儿只是总结一下。
  
                                                           图2  AmS内部主要数据结构类图

转自：https://www.cnblogs.com/xingchenkn/p/3637137.html