Android ActivityManagerService 基本构架详解
学习AmS有段时日了,总结下,也好梳理一下自己的思路。小兵一个,有些地方理解不对,大家可以互相讨论,交流才有进步吗~~~
AmS可以说是Android上层系统最核心的模块之一,其主要完成管理应用进程的生命周期以及进程的Activity,Service,Broadcast和Provider等。
从系统运行的角度看,AmS可以分为Client端和Service端:Client端运行在各个app进程,app进程实现了具体的Activity,Service等,告诉系统我有那些Activity,Service等,并且调用系统接口来完成显示;Service端运行在SystemServer进程,是系统级别的ActivityManagerService的具体实现,其响应Client端的系统调用请求,并且管理Client端各个app进程的生命周期。
![](http://www.52ij.com/uploads/allimg/140401/0F351G18-0.png)
图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相信大家都会知道这些类都是干什么的,这儿只是总结一下。
![](http://www.52ij.com/uploads/allimg/140401/0F3512353-1.png)