Androi ActivityManagerService 基本构架详解.docVIP

ActivityManagerService 概述： ActivityManagerService 负责四大组件的启动/切换/调度、进程的管理/调度等； ActivityManagerService 继承自 ActivityManagerNative 类，并实现了 Watchdog.Monitor 和 BatteryStatsImpl.BatteryCallback 接口；而 ActivityManagerNative 继承自 Binder 类，并实现了 IActivityManager 接口； 客户端使用的是 ActivityManager 类，其内部通过调用 ActivityManagerNative.getDefault() 得到一个 ActivityManagerProxy 对象，通过它与 ActivityManagerService 通信； Android ActivityManagerService 基本构架详解 学习AmS有段时日了，总结下，也好梳理一下自己的思路。小兵一个，有些地方理解不对，大家可以互相讨论，交流才有进步吗~~~ AmS可以说是Android上层系统最核心的模块之一，其主要完成管理 HYPERLINK /app/ \t _blank 应用进程的生命周期以及进程的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接口，其作为各自的代理