相關(guān)文章
Android系統(tǒng)啟動(dòng)流程系列
Android應(yīng)用進(jìn)程系列
Android深入四大組件系列
前言
此前在A(yíng)ndroid系統(tǒng)啟動(dòng)流程躲因、應(yīng)用進(jìn)程以及深入四大組件這三個(gè)系列文章中棘伴,都提及到了AMS,但都沒(méi)有系統(tǒng)的來(lái)講解它摩骨,本文就以AMS為主來(lái)進(jìn)行講解通贞,其中會(huì)有一些知識(shí)點(diǎn)與這些系列文章有所重合,這里會(huì)盡量做到詳盡講解恼五。閱讀此文章前昌罩,最好閱讀相關(guān)文章中列出的系列文章,否則我不敢保證這篇文章你能看的懂唤冈。
1.概述
AMS是系統(tǒng)的引導(dǎo)服務(wù)峡迷,應(yīng)用進(jìn)程的啟動(dòng)、切換和調(diào)度你虹、四大組件的啟動(dòng)和管理都需要AMS的支持绘搞。從這里可以看出AMS的功能會(huì)十分的繁多,當(dāng)然它并不是一個(gè)類(lèi)承擔(dān)這個(gè)重責(zé)傅物,它有一些關(guān)聯(lián)類(lèi)夯辖,這在文章后面會(huì)講到。AMS的涉及的知識(shí)點(diǎn)非常多董饰,這篇文章主要會(huì)講解AMS的以下幾個(gè)知識(shí)點(diǎn):
- AMS的啟動(dòng)流程蒿褂。
- AMS與進(jìn)程啟動(dòng)。
- AMS家族卒暂。
2.AMS的啟動(dòng)流程
AMS的啟動(dòng)是在SyetemServer進(jìn)程中啟動(dòng)的啄栓,在Android系統(tǒng)啟動(dòng)流程(三)解析SyetemServer進(jìn)程啟動(dòng)過(guò)程這篇文章中提及過(guò),這里從SyetemServer的main方法開(kāi)始講起:
frameworks/base/services/java/com/android/server/SystemServer.java
public static void main(String[] args) {
new SystemServer().run();
}
main方法中只調(diào)用了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處加載了動(dòng)態(tài)庫(kù)libandroid_servers.so。接下來(lái)在注釋2處創(chuàng)建SystemServiceManager诈嘿,它會(huì)對(duì)系統(tǒng)的服務(wù)進(jìn)行創(chuàng)建堪旧、啟動(dòng)和生命周期管理削葱。在注釋3中的startBootstrapServices方法中用SystemServiceManager啟動(dòng)了ActivityManagerService、PowerManagerService淳梦、PackageManagerService等服務(wù)析砸。在注釋4處的startCoreServices方法中則啟動(dòng)了BatteryService、UsageStatsService和WebViewUpdateService爆袍。注釋5處的startOtherServices方法中啟動(dòng)了CameraService首繁、AlarmManagerService、VrManagerService等服務(wù)螃宙。這些服務(wù)的父類(lèi)均為SystemService蛮瞄。從注釋3所坯、4谆扎、5的方法可以看出,官方把系統(tǒng)服務(wù)分為了三種類(lèi)型芹助,分別是引導(dǎo)服務(wù)堂湖、核心服務(wù)和其他服務(wù),其中其他服務(wù)是一些非緊要和一些不需要立即啟動(dòng)的服務(wù)状土。系統(tǒng)服務(wù)總共大約有80多個(gè)无蜂,我們主要來(lái)查看引導(dǎo)服務(wù)AMS是如何啟動(dòng)的,注釋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處調(diào)用了SystemServiceManager的startService方法斥季,方法的參數(shù)是ActivityManagerService.Lifecycle.class:
frameworks/base/services/core/java/com/android/server/SystemServiceManager.java
@SuppressWarnings("unchecked")
public <T extends SystemService> T startService(Class<T> serviceClass) {
try {
...
final T service;
try {
Constructor<T> 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方法傳入的參數(shù)是Lifecycle.class,Lifecycle繼承自SystemService累驮。首先酣倾,通過(guò)反射來(lái)創(chuàng)建Lifecycle實(shí)例,注釋1處得到傳進(jìn)來(lái)的Lifecycle的構(gòu)造器constructor谤专,在注釋2處調(diào)用constructor的newInstance方法來(lái)創(chuàng)建Lifecycle類(lèi)型的service對(duì)象躁锡。接著在注釋3處將剛創(chuàng)建的service添加到ArrayList類(lèi)型的mServices對(duì)象中來(lái)完成注冊(cè)。最后在注釋4處調(diào)用service的onStart方法來(lái)啟動(dòng)service置侍,并返回該service映之。Lifecycle是AMS的內(nèi)部類(lèi),代碼如下所示蜡坊。
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.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
}
}
上面的代碼結(jié)合SystemServiceManager的startService方法來(lái)分析杠输,當(dāng)通過(guò)反射來(lái)創(chuàng)建Lifecycle實(shí)例時(shí),會(huì)調(diào)用注釋1處的方法創(chuàng)建AMS實(shí)例秕衙,當(dāng)調(diào)用Lifecycle類(lèi)型的service的onStart方法時(shí)蠢甲,實(shí)際上是調(diào)用了注釋2處AMS的start方法。在SystemServer的startBootstrapServices方法的注釋1處灾梦,調(diào)用了如下代碼:
mActivityManagerService = mSystemServiceManager.startService(
ActivityManagerService.Lifecycle.class).getService();
我們知道SystemServiceManager的startService方法最終會(huì)返回Lifecycle類(lèi)型的對(duì)象峡钓,緊接著又調(diào)用了Lifecycle的getService方法妓笙,這個(gè)方法會(huì)返回AMS類(lèi)型的mService對(duì)象,見(jiàn)注釋3處能岩,這樣AMS實(shí)例就會(huì)被創(chuàng)建并且返回寞宫。
3.AMS與進(jìn)程啟動(dòng)
在Android系統(tǒng)啟動(dòng)流程(二)解析Zygote進(jìn)程啟動(dòng)過(guò)程這篇文章中,我提到了Zygote的Java框架層中拉鹃,會(huì)創(chuàng)建一個(gè)Server端的Socket辈赋,這個(gè)Socket用來(lái)等待AMS來(lái)請(qǐng)求Zygote來(lái)創(chuàng)建新的應(yīng)用程序進(jìn)程。要啟動(dòng)一個(gè)應(yīng)用程序膏燕,首先要保證這個(gè)應(yīng)用程序所需要的應(yīng)用程序進(jìn)程已經(jīng)被啟動(dòng)钥屈。AMS在啟動(dòng)應(yīng)用程序時(shí)會(huì)檢查這個(gè)應(yīng)用程序需要的應(yīng)用程序進(jìn)程是否存在,不存在就會(huì)請(qǐng)求Zygote進(jìn)程將需要的應(yīng)用程序進(jìn)程啟動(dòng)坝辫。Service的啟動(dòng)過(guò)程中會(huì)調(diào)用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, intentFlags,
"service", r.name, false, isolated, false)) == null) {//6
...
}
if (isolated) {
r.isolatedProc = app;
}
}
...
}
在注釋1處得到ServiceRecord的processName的值賦值給procName 近忙,其中ServiceRecord用來(lái)描述Service的android:process屬性竭业。注釋2處將procName和Service的uid傳入到AMS的getProcessRecordLocked方法中,來(lái)查詢(xún)是否存在一個(gè)與Service對(duì)應(yīng)的ProcessRecord類(lèi)型的對(duì)象app及舍,ProcessRecord主要用來(lái)記錄運(yùn)行的應(yīng)用程序進(jìn)程的信息未辆。注釋5處判斷Service對(duì)應(yīng)的app為null則說(shuō)明用來(lái)運(yùn)行Service的應(yīng)用程序進(jìn)程不存在,則調(diào)用注釋6處的AMS的startProcessLocked方法來(lái)創(chuàng)建對(duì)應(yīng)的應(yīng)用程序進(jìn)程锯玛,
具體的過(guò)程請(qǐng)查看Android應(yīng)用程序進(jìn)程啟動(dòng)過(guò)程(前篇)咐柜。
4.AMS家族
ActivityManager是一個(gè)和AMS相關(guān)聯(lián)的類(lèi),它主要對(duì)運(yùn)行中的Activity進(jìn)行管理攘残,這些管理工作并不是由ActivityManager來(lái)處理的拙友,而是交由AMS來(lái)處理,ActivityManager中的方法會(huì)通過(guò)ActivityManagerNative(以后簡(jiǎn)稱(chēng)AMN)的getDefault方法來(lái)得到ActivityManagerProxy(以后簡(jiǎn)稱(chēng)AMP)肯腕,通過(guò)AMP就可以和AMN進(jìn)行通信献宫,而AMN是一個(gè)抽象類(lèi),它會(huì)將功能交由它的子類(lèi)AMS來(lái)處理实撒,因此姊途,AMP就是AMS的代理類(lèi)。AMS作為系統(tǒng)核心服務(wù)知态,很多API是不會(huì)暴露給ActivityManager的捷兰,因此ActivityManager并不算是AMS家族一份子。
為了講解AMS家族负敏,這里拿Activity的啟動(dòng)過(guò)程舉例贡茅,Activity的啟動(dòng)過(guò)程中會(huì)調(diào)用Instrumentation的execStartActivity方法,如下所示。
frameworks/base/core/java/android/app/Instrumentation.java
public ActivityResult execStartActivity(
Context who, IBinder contextThread, IBinder token, Activity target,
Intent intent, int requestCode, Bundle options) {
...
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方法中會(huì)調(diào)用AMN的getDefault來(lái)獲取AMS的代理類(lèi)AMP顶考。接著調(diào)用了AMP的startActivity方法赁还,先來(lái)查看AMN的getDefault方法做了什么,如下所示驹沿。
frameworks/base/core/java/android/app/ActivityManagerNative.java
static public IActivityManager getDefault() {
return gDefault.get();
}
private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
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方法調(diào)用了gDefault的get方法艘策,我們接著往下看,gDefault 是一個(gè)Singleton類(lèi)渊季。注釋1處得到名為”activity”的Service引用朋蔫,也就是IBinder類(lèi)型的AMS的引用。接著在注釋2處將它封裝成AMP類(lèi)型對(duì)象却汉,并將它保存到gDefault中驯妄,此后調(diào)用AMN的getDefault方法就會(huì)直接獲得AMS的代理對(duì)象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類(lèi)型的AMS引用封裝成AMP青扔,AMP的構(gòu)造方法如下所示。
frameworks/base/core/java/android/app/ActivityManagerNative.java
class ActivityManagerProxy implements IActivityManager
{
public ActivityManagerProxy(IBinder remote)
{
mRemote = remote;
}
...
}
AMP的構(gòu)造方法中將AMS的引用賦值給變量mRemote 既穆,這樣在A(yíng)MP中就可以使用AMS了赎懦。
其中IActivityManager是一個(gè)接口,AMN和AMP都實(shí)現(xiàn)了這個(gè)接口幻工,用于實(shí)現(xiàn)代理模式和Binder通信。
再回到Instrumentation的execStartActivity方法黎茎,來(lái)查看AMP的startActivity方法囊颅,AMP是AMN的內(nèi)部類(lèi),代碼如下所示傅瞻。
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,
int startFlags, ProfilerInfo profilerInfo, Bundle options) throws RemoteException {
...
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;
}
首先會(huì)將傳入的參數(shù)寫(xiě)入到Parcel類(lèi)型的data中踢代。在注釋1處,通過(guò)IBinder類(lèi)型對(duì)象mRemote(AMS的引用)向服務(wù)端的AMS發(fā)送一個(gè)START_ACTIVITY_TRANSACTION類(lèi)型的進(jìn)程間通信請(qǐng)求嗅骄。那么服務(wù)端AMS就會(huì)從Binder線(xiàn)程池中讀取我們客戶(hù)端發(fā)來(lái)的數(shù)據(jù)胳挎,最終會(huì)調(diào)用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, resolvedType,
resultTo, resultWho, requestCode, startFlags, profilerInfo, options);
reply.writeNoException();
reply.writeInt(result);
return true;
}
}
onTransact中會(huì)調(diào)用AMS的startActivity方法慕爬,如下所示。
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
@Override
public final int startActivity(IApplicationThread caller, String callingPackage,
Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode,
int startFlags, ProfilerInfo profilerInfo, Bundle bOptions) {
return startActivityAsUser(caller, callingPackage, intent, resolvedType, resultTo,
resultWho, requestCode, startFlags, profilerInfo, bOptions,
UserHandle.getCallingUserId());
}
startActivity方法會(huì)最后return startActivityAsUser方法屏积,如下所示医窿。
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
@Override
public final int startActivityAsUser(IApplicationThread caller, String callingPackage,
Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode,
int startFlags, ProfilerInfo profilerInfo, Bundle bOptions, int userId) {
enforceNotIsolatedCaller("startActivity");
userId = mUserController.handleIncomingUser(Binder.getCallingPid(), Binder.getCallingUid(),
userId, false, ALLOW_FULL_ONLY, "startActivity", null);
return mActivityStarter.startActivityMayWait(caller, -1, callingPackage, intent,
resolvedType, null, null, resultTo, resultWho, requestCode, startFlags,
profilerInfo, null, null, bOptions, false, userId, null, null);
}
startActivityAsUser方法最后會(huì)return ActivityStarter的startActivityMayWait方法,這一調(diào)用過(guò)程已經(jīng)脫離了本節(jié)要講的AMS家族炊林,因此這里不做介紹了姥卢,具體的調(diào)用過(guò)程可以查看Android深入四大組件(一)應(yīng)用程序啟動(dòng)過(guò)程(后篇)這篇文章。
在A(yíng)ctivity的啟動(dòng)過(guò)程中提到了AMP、AMN和AMS独榴,它們共同組成了AMS家族的主要部分僧叉,如下圖所示。
AMP是AMN的內(nèi)部類(lèi)棺榔,它們都實(shí)現(xiàn)了IActivityManager接口彪标,這樣它們就可以實(shí)現(xiàn)代理模式,具體來(lái)講是遠(yuǎn)程代理:AMP和AMN是運(yùn)行在兩個(gè)進(jìn)程的掷豺,AMP是Client端捞烟,AMN則是Server端,而Server端中具體的功能都是由AMN的子類(lèi)AMS來(lái)實(shí)現(xiàn)的当船,因此题画,AMP就是AMS在Client端的代理類(lèi)。AMN又實(shí)現(xiàn)了Binder類(lèi)德频,這樣AMP可以和AMS就可以通過(guò)Binder來(lái)進(jìn)行進(jìn)程間通信苍息。
ActivityManager通過(guò)AMN的getDefault方法得到AMP,通過(guò)AMP就可以和AMN進(jìn)行通信壹置,也就是間接的與AMS進(jìn)行通信竞思。除了ActivityManager,其他想要與AMS進(jìn)行通信的類(lèi)都需要通過(guò)AMP钞护,如下圖所示盖喷。
參考資料
[深入理解Android卷二 全文-第六章]深入理解ActivityManagerService
Framework源碼分析(一):ActivityManagerService
ActivityManager與Proxy模式的運(yùn)用