2019Android Framework 高频面试题总结
1. AMS 、PMS
1.AMS 概述
AMS 是系统的引导服务,应用进程的启动、切换和调度、四大组件的启动和管
理都需要 AMS 的支持。从这里可以看出 AMS 的功能会十分的繁多,当然它并不
是一个类承担这个重责,它有一些关联类,这在文章后面会讲到。AMS 的涉及
的知识点非常多,这篇文章主要会讲解 AMS 的以下几个知识点:
AMS 的启动流程。
AMS 与进程启动。
AMS 家族。
2.AMS 的启动流程
AMS 的启动是在 SyetemServer 进程中启动的,在 Android 系统启动流程(三)解
析 SyetemServer 进程启动过程这篇文章中提及过,这里从 SyetemServer 的 main
方法开始讲起:
frameworks/base/services/java/com/android/server/SystemServer.java
public static void main(String[] args) {
new SystemServer().run();
}
main 方法中只调用了 SystemServer 的 run 方法,如下所示。
frameworks/base/services/java/com/android/server/SystemServer.java
private void run() {
...
...
System.loadLibrary("android_servers");//1
mSystemServiceManager = new
SystemServiceManager(mSystemContext);//2
LocalServices.addService(SystemServiceManager.class,
mSystemServiceManager);
...
try {
Trace.traceBegin(Trace.TRACE_TAG_SYSTEM_SERVER,
"StartServices");
startBootstrapServices();//3
startCoreServices();//4
startOtherServices();//5
} catch (Throwable ex) {
Slog.e("System",
"******************************************");
Slog.e("System", "************ Failure starting system
services", ex);
throw ex;
} finally {
Trace.traceEnd(Trace.TRACE_TAG_SYSTEM_SERVER);
}
...
}
在注释 1 处加载了动态库 libandroid_servers.so。接下来在注释 2 处创建
SystemServiceManager,它会对系统的服务进行创建、启动和生命周期管理。在
注释 3 中的 startBootstrapServices 方法中用 SystemServiceManager 启动了
ActivityManagerService、PowerManagerService、PackageManagerService 等服务。
在注释 4 处的 startCoreServices 方法中则启动了 BatteryService、UsageStatsService
和 WebViewUpdateService。注释 5 处的 startOtherServices 方法中启动了
CameraService、AlarmManagerService、VrManagerService 等服务。这些服务的父
类均为 SystemService。从注释 3、4、5 的方法可以看出,官方把系统服务分为
了三种类型,分别是引导服务、核心服务和其他服务,其中其他服务是一些非紧
要和一些不需要立即启动的服务。系统服务总共大约有 80 多个,我们主要来查
看引导服务 AMS 是如何启动的,注释 3 处的 startBootstrapServices 方法如下所示。
frameworks/base/services/java/com/android/server/SystemServer.java
private void startBootstrapServices() {
Installer installer =
mSystemServiceManager.startService(Installer.class);
// Activity manager runs the show.
mActivityManagerService = mSystemServiceManager.startService(
ActivityManagerService.Lifecycle.class).getService();//1
mActivityManagerService.setSystemServiceManager(mSystemServiceManager)
;
mActivityManagerService.setInstaller(installer);
...
}
在注释 1 处调用了 SystemServiceManager 的 startService 方法,方法的参数是
ActivityManagerService.Lifecycle.class:
frameworks/base/services/core/java/com/android/server/SystemServiceManager.
java
@SuppressWarnings("unchecked")
public T startService(Class serviceClass)
{
try {
...
final T service;
try {
Constructor constructor =
serviceClass.getConstructor(Context.class);//1
service = constructor.newInstance(mContext);//2
} catch (InstantiationException ex) {
...
}
// Register it.
mServices.add(service);//3
// Start it.
try {
service.onStart();//4
} catch (RuntimeException ex) {
throw new RuntimeException("Failed to start service " + name
+ ": onStart threw an exception", ex);
}
return service;
} finally {
Trace.traceEnd(Trace.TRACE_TAG_SYSTEM_SERVER);
}
}
startService 方法传入的参数是 Lifecycle.class,Lifecycle 继承自 SystemService。首
先,通过反射来创建 Lifecycle 实例,注释 1 处得到传进来的 Lifecycle 的构造器
constructor,在注释 2 处调用 constructor 的 newInstance 方法来创建 Lifecycle 类
型的 service 对象。接着在注释 3 处将刚创建的 service 添加到 ArrayList 类型的
mServices 对象中来完成注册。最后在注释 4 处调用 service 的 onStart 方法来启
动 service,并返回该 service。Lifecycle 是 AMS 的内部类,代码如下所示。
frameworks/base/services/core/java/com/android/server/am/ActivityManagerSe
rvice.java
public static final class Lifecycle extends SystemService {
private final ActivityManagerService mService;
public Lifecycle(Context context) {
super(context);
mService = new ActivityManagerService(context);//1
}
@Override
public void onStart() {
mService.start();//2
}
public ActivityManagerService getService() {
return mService;//3
}
}
上面的代码结合 SystemServiceManager 的 startService 方法来分析,当通过反射
来创建 Lifecycle 实例时,会调用注释 1 处的方法创建 AMS 实例,当调用 Lifecycle
类型的 service 的 onStart 方法时,实际上是调用了注释 2 处 AMS 的 start 方法。
在 SystemServer 的 startBootstrapServices 方法的注释 1 处,调用了如下代码:
mActivityManagerService = mSystemServiceManager.startService(
ActivityManagerService.Lifecycle.class).getService();
我们知道 SystemServiceManager 的 startService 方法最终会返回 Lifecycle 类型的
对象,紧接着又调用了 Lifecycle 的 getService 方法,这个方法会返回 AMS 类型的
mService 对象,见注释 3 处,这样 AMS 实例就会被创建并且返回。
3.AMS 与进程启动
在 Android 系统启动流程(二)解析 Zygote 进程启动过程这篇文章中,我提到了
Zygote 的 Java 框架层中,会创建一个 Server 端的 Socket,这个 Socket 用来等待
AMS 来请求 Zygote 来创建新的应用程序进程。要启动一个应用程序,首先要保
证这个应用程序所需要的应用程序进程已经被启动。AMS 在启动应用程序时会
检查这个应用程序需要的应用程序进程是否存在,不存在就会请求 Zygote 进程
将需要的应用程序进程启动。Service 的启动过程中会调用 ActiveServices 的
bringUpServiceLocked 方法,如下所示。
frameworks/base/services/core/java/com/android/server/am/ActiveServices.java
private String bringUpServiceLocked(ServiceRecord r, int intentFlags,
boolean execInFg,
boolean whileRestarting, boolean permissionsReviewRequired)
throws TransactionTooLargeException {
...
final String procName = r.processName;//1
ProcessRecord app;
if (!isolated) {
app = mAm.getProcessRecordLocked(procName, r.appInfo.uid,
false);//2
if (DEBUG_MU) Slog.v(TAG_MU, "bringUpServiceLocked:
appInfo.uid=" + r.appInfo.uid
+ " app=" + app);
if (app != null && app.thread != null) {//3
try {
app.addPackage(r.appInfo.packageName,
r.appInfo.versionCode,
mAm.mProcessStats);
realStartServiceLocked(r, app, execInFg);//4
return null;
} catch (TransactionTooLargeException e) {
...
}
} else {
app = r.isolatedProc;
}
if (app == null && !permissionsReviewRequired) {//5
if ((app=mAm.startProcessLocked(procName, r.appInfo, true,
"service", r.name, false, isolated, false)) == null)
intentFlags,
{//6
...
}
if (isolated) {
r.isolatedProc = app;
}
}
}
...
在注释 1 处得到 ServiceRecord 的 processName 的值赋值给 procName ,其中
ServiceRecord 用来描述 Service 的 android:process 属性。注释 2 处将 procName
和 Service 的 uid 传入到 AMS 的 getProcessRecordLocked 方法中,来查询是否存
在一个与 Service 对应的 ProcessRecord 类型的对象 app,ProcessRecord 主要用来
记录运行的应用程序进程的信息。注释 5 处判断 Service 对应的 app 为 null 则说
明用来运行 Service 的应用程序进程不存在,则调用注释 6 处的 AMS 的
startProcessLocked 方法来创建对应的应用程序进程,
具体的过程请查看 Android 应用程序进程启动过程(前篇)。
4.AMS 家族
ActivityManager 是一个和 AMS 相关联的类,它主要对运行中的 Activity 进行管理,
这些管理工作并不是由 ActivityManager 来处理的,而是交由 AMS 来处理,
ActivityManager 中的方法会通过 ActivityManagerNative(以后简称 AMN)的
getDefault 方法来得到 ActivityManagerProxy(以后简称 AMP),通过 AMP 就可以和
AMN 进行通信,而 AMN 是一个抽象类,它会将功能交由它的子类 AMS 来处理,
因此,AMP 就是 AMS 的代理类。AMS 作为系统核心服务,很多 API 是不会暴露
给 ActivityManager 的,因此 ActivityManager 并不算是 AMS 家族一份子。
为了讲解 AMS 家族,这里拿 Activity 的启动过程举例,Activity 的启动过程中会
调用 Instrumentation 的 execStartActivity 方法,如下所示。
frameworks/base/core/java/android/app/Instrumentation.java
public ActivityResult execStartActivity(
Context who, IBinder contextThread, IBinder token, Activity
Intent intent, int requestCode, Bundle options) {
target,
...
try {
intent.migrateExtraStreamToClipData();
intent.prepareToLeaveProcess(who);
int result = ActivityManagerNative.getDefault()
.startActivity(whoThread, who.getBasePackageName(),
intent,
intent.resolveTypeIfNeeded(who.getContentResolver()),
token, target != null ? target.mEmbeddedID : null,
requestCode, 0, null, options);
checkStartActivityResult(result, intent);
} catch (RemoteException e) {
throw new RuntimeException("Failure from system", e);
}
return null;
}
execStartActivity 方法中会调用 AMN 的 getDefault 来获取 AMS 的代理类 AMP。接
着调用了 AMP 的 startActivity 方法,先来查看 AMN 的 getDefault 方法做了什么,
如下所示。
frameworks/base/core/java/android/app/ActivityManagerNative.java
static public IActivityManager getDefault() {
return gDefault.get();
}
private static final Singleton gDefault = new
Singleton() {
protected IActivityManager create() {
IBinder b = ServiceManager.getService("activity");//1
if (false) {
Log.v("ActivityManager", "default service binder = " + b);
}
IActivityManager am = asInterface(b);//2
if (false) {
Log.v("ActivityManager", "default service = " + am);
}
return am;
}+
};}
getDefault 方法调用了 gDefault 的 get 方法,我们接着往下看,gDefault 是一个
Singleton 类。注释 1 处得到名为”activity”的 Service 引用,也就是 IBinder 类型的
AMS 的引用。接着在注释 2 处将它封装成 AMP 类型对象,并将它保存到 gDefault
中,此后调用 AMN 的 getDefault 方法就会直接获得 AMS 的代理对象 AMP。注释
2 处的 asInterface 方法如下所示。
frameworks/base/core/java/android/app/ActivityManagerNative.java
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);}
asInterface 方法的主要作用就是将 IBinder 类型的 AMS 引用封装成 AMP,AMP
的构造方法如下所示。
frameworks/base/core/java/android/app/ActivityManagerNative.java
class ActivityManagerProxy implements IActivityManager{
public ActivityManagerProxy(IBinder remote)
{
mRemote = remote;
}...
}
AMP 的构造方法中将 AMS 的引用赋值给变量 mRemote ,这样在 AMP 中就可以
使用 AMS 了。
其中 IActivityManager 是一个接口,AMN 和 AMP 都实现了这个接口,用于实现
代理模式和 Binder 通信。
再回到 Instrumentation 的 execStartActivity 方法,来查看 AMP 的 startActivity 方
法,AMP 是 AMN 的内部类,代码如下所示。
frameworks/base/core/java/android/app/ActivityManagerNative.java
public int startActivity(IApplicationThread caller, String
callingPackage, Intent intent,
String resolvedType, IBinder resultTo, String resultWho, int
requestCode,
throws RemoteException {
int startFlags, ProfilerInfo profilerInfo, Bundle options)
...
data.writeInt(requestCode);
data.writeInt(startFlags);
...
mRemote.transact(START_ACTIVITY_TRANSACTION, data, reply, 0);//1
reply.readException();+
int result = reply.readInt();
reply.recycle();
data.recycle();
return result;
}
首先会将传入的参数写入到 Parcel 类型的 data 中。在注释 1 处,通过 IBinder 类
型对象 mRemote(AMS 的引用)向服务端的 AMS 发送一个
START_ACTIVITY_TRANSACTION 类型的进程间通信请求。那么服务端 AMS 就会从
Binder 线程池中读取我们客户端发来的数据,最终会调用 AMN 的 onTransact 方
法,如下所示。
frameworks/base/core/java/android/app/ActivityManagerNative.java
@Override
public boolean onTransact(int code, Parcel data, Parcel reply, int
flags)
throws RemoteException {
switch (code) {
case START_ACTIVITY_TRANSACTION:
{
...
int result = startActivity(app, callingPackage, intent,
resultTo, resultWho, requestCode, startFlags,
resolvedType,
profilerInfo, options);
reply.writeNoException();
reply.writeInt(result);
return true;
}
}