這幾天分析了一下Activity的啓動過程和Service的啓動過程,於是乎,今天寫一下Service是如何啓動的。給我的感覺是這些啓動過程並不複雜,千萬不要被一坨一坨的代碼嚇住了,雖然彎彎繞繞不少,重載函數一個接着一個,就向走迷宮一樣,但只要抓住主線閱讀,很快就能找到出口。強調一下閱讀系統源碼,起碼要對進程間通信要了解,對binder機制非常非常清楚,binder就是指南針,要不然你會暈頭轉向。強行閱讀,就容易睡着。如果想看Binder的,移步Android源碼解析RPC系列(一)—Binder原理。
Service啓動先來一張圖感受一下
這張圖能夠說明一個大致的流程,但是服務的啓動肯定不是這麼簡單,但是我們先簡單的總結一下,逐漸深入。服務的啓動形式有兩種,startService()和 binderService(),我們看startService()這一種。startService是ContextWrapper裏面的方法。
ContextWrapper.java
@Override
public ComponentName startService(Intent service) {
return mBase.startService(service);//mBase這裏指的是ContextImpl類
}
ContextImpl.java
@Override
public ComponentName startService(Intent service) {
warnIfCallingFromSystemProcess();
return startServiceCommon(service, mUser);
}
private ComponentName startServiceCommon(Intent service, UserHandle user) {
try {
//檢驗Intent
validateServiceIntent(service);
......
ComponentName cn = ActivityManagerNative.getDefault().startService(
mMainThread.getApplicationThread(), service, service.resolveTypeIfNeeded(
getContentResolver()), getOpPackageName(), user.getIdentifier());
......
return cn;
} catch (RemoteException e) {
throw new RuntimeException("Failure from system", e);
}
}
校驗完Intent後,就調用ActivityManagerNative.getDefault(),獲取一個IActivityManager對象,將啓動Service這件事情交給了IActivityManager。我們看一下ActivityManagerNative的類定義
public abstract class ActivityManagerNative extends Binder implements IActivityManager
這種模式是不是非常熟悉啊?繼承了Binder,實現了一個IActivityManager接口,這個跟我們生成了遠程服務通信生成的AIDL的java文件怎麼那麼像,現在告訴你,這就是爲了遠程服務通信做準備的,只是一般這種類我們都是自動生成的,ActivityManagerNative 是谷歌的人自己寫。一個完整的AID L有兩部分,一個是個跟服務端通信的Stub,一個是跟客戶端通信的Proxy。ActivityManagerNative就是Stub,閱讀源碼發現在ActivityManagerNative 文件中還有個ActivityManagerProxy,那麼跟客戶端通信的Proxy也有了。先看IActivityManager怎麼獲取的。
ActivityManagerNative.java
static public IActivityManager getDefault() {
return gDefault.get();
}
private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
protected IActivityManager create() {
//獲取名爲"activity"的服務,服務都註冊到ServiceManager來統一管理
IBinder b = ServiceManager.getService("activity");
if (false) {
Log.v("ActivityManager", "default service binder = " + b);
}
IActivityManager am = asInterface(b);
if (false) {
Log.v("ActivityManager", "default service = " + am);
}
return am;
}
};
就是一個單例設計模式,獲取到服務對象IBinder,把這個IBinder轉換成IActivityManager返回了。現在由IActivityManager啓動服務。
public ComponentName startService(IApplicationThread caller, Intent service,
String resolvedType, String callingPackage, int userId) throws RemoteException
{
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
data.writeInterfaceToken(IActivityManager.descriptor);
data.writeStrongBinder(caller != null ? caller.asBinder() : null);
service.writeToParcel(data, 0);
data.writeString(resolvedType);
data.writeString(callingPackage);
data.writeInt(userId);
mRemote.transact(START_SERVICE_TRANSACTION, data, reply, 0);
reply.readException();
ComponentName res = ComponentName.readFromParcel(reply);
data.recycle();
reply.recycle();
return res;
}
上面說了ActivityManagerProxy作爲binder通信的客戶端,ActivityManagerNative 作爲binder通信的服務端。mRemote.transact()是binder通信的客戶端發起方法,經過binder驅動,最後回到binder服務端ActivityManagerNative的onTransact()方法。
@Override
public boolean onTransact(int code, Parcel data, Parcel reply, int flags)
throws RemoteException {
.......
switch (code) {
case START_SERVICE_TRANSACTION: {
data.enforceInterface(IActivityManager.descriptor);
IBinder b = data.readStrongBinder();
IApplicationThread app = ApplicationThreadNative.asInterface(b);
Intent service = Intent.CREATOR.createFromParcel(data);
String resolvedType = data.readString();
String callingPackage = data.readString();
int userId = data.readInt();
ComponentName cn = startService(app, service, resolvedType, callingPackage, userId);
reply.writeNoException();
ComponentName.writeToParcel(cn, reply);
return true;
}
}
.......
}
ActivityManagerNative的真正實現是ActivityManagerService,所以binder通信的服務端的ActivityManagerService,ActivityManagerProxy.startService()最終調用ActivityManagerService.startService()。注意這就跨進程了,ActivityManagerService是一個服務端的進程。看ActivityManagerService中的startService方法。
ActivityManagerService.java
public ComponentName startService(IApplicationThread caller, Intent service,
String resolvedType, String callingPackage, int userId)
throws TransactionTooLargeException {
......
synchronized(this) {
.......
ComponentName res = mServices.startServiceLocked(caller, service,
resolvedType, callingPid, callingUid, callingPackage, userId);
Binder.restoreCallingIdentity(origId);
return res;
}
}
ActivityManagerService沒有直接幹這個活,而是把這個任務交給了mService, mService 是一個 ActiveServices 對象。在早期的安卓版本中並沒有這個類,後來重構時抽出這個類專門用來管理Service.
ActiveServices.java
ComponentName startServiceLocked(IApplicationThread caller, Intent service, String resolvedType,
int callingPid, int callingUid, String callingPackage, int userId)
throws TransactionTooLargeException {
........
return startServiceInnerLocked(smap, service, r, callerFg, addToStarting);
}
startServiceInnerLocked調用了 bringUpServiceLocked(),bringUpServiceLocked()內部調用了realStartServiceLocked(),我們看realStartServiceLocked()方法。
private final void realStartServiceLocked(ServiceRecord r,
ProcessRecord app, boolean execInFg) throws RemoteException {
.......
try {
.......
app.thread.scheduleCreateService(r, r.serviceInfo,
mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),
app.repProcState);
r.postNotification();
created = true;
} catch (DeadObjectException e) {
....
} finally {
....
}
requestServiceBindingsLocked(r, execInFg);
updateServiceClientActivitiesLocked(app, null, true);
// If the service is in the started state, and there are no
// pending arguments, then fake up one so its onStartCommand() will
// be called.
if (r.startRequested && r.callStart && r.pendingStarts.size() == 0) {
r.pendingStarts.add(new ServiceRecord.StartItem(r, false, r.makeNextStartId(),
null, null));
}
// 進入onStartCommand()
sendServiceArgsLocked(r, execInFg, true);
....
}
這裏的關鍵是
app.thread.scheduleCreateService(r, r.serviceInfo,
mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),
app 是要運行 Service 的進程對應的 ProcessRecord 對象,代表一個應用進程。要區分一下,一般我們都是單方向通信,客戶端將處理請求發送給服務端,服務端處理後返回,如果要服務端向客戶端發送一個“請求”呢?這裏的thread 是一個 ApplicationThreadProxy 對象,它是應用進程的 ApplicatonThread 對象在 AMS 端的代理,AMS 靠它來和應用進程進行通信。所以AMS和應用進程可以雙向通信了。
ApplicationThreadProxy.java
public final void scheduleCreateService(IBinder token, ServiceInfo info,
CompatibilityInfo compatInfo, int processState) throws RemoteException {
Parcel data = Parcel.obtain();
data.writeInterfaceToken(IApplicationThread.descriptor);
data.writeStrongBinder(token);
info.writeToParcel(data, 0);
compatInfo.writeToParcel(data, 0);
data.writeInt(processState);
try {
mRemote.transact(SCHEDULE_CREATE_SERVICE_TRANSACTION, data, null, IBinder.FLAG_ONEWAY);
} catch (TransactionTooLargeException e) {
throw e;
}
data.recycle();
}
執行mRemote.transact後,就會回調ApplicationThreadNative的onTransact,這是Binder的套路。
ApplicationThreadNative.java
public boolean onTransact(int code, Parcel data, Parcel reply, int flags)
throws RemoteException {
switch (code) {
case SCHEDULE_CREATE_SERVICE_TRANSACTION: {
data.enforceInterface(IApplicationThread.descriptor);
IBinder token = data.readStrongBinder();
ServiceInfo info = ServiceInfo.CREATOR.createFromParcel(data);
CompatibilityInfo compatInfo = CompatibilityInfo.CREATOR.createFromParcel(data);
int processState = data.readInt();
scheduleCreateService(token, info, compatInfo, processState);
return true;
}
...
}
內部調用scheduleCreateService,看上面的圖,可以知道,scheduleCreateService是屬於ApplicatonThread的。
ApplicatonThread.java
public final void scheduleCreateService(IBinder token,
ServiceInfo info, CompatibilityInfo compatInfo, int processState) {
updateProcessState(processState, false);
CreateServiceData s = new CreateServiceData();
s.token = token;
s.info = info;
s.compatInfo = compatInfo;
sendMessage(H.CREATE_SERVICE, s);
}
發送一個消息,這個消息都是由H類處理的,H類就是系統Hander,專門處理系統請求的,比如一些Activity的生命週期等全在這裏面。這個 H對象是在應用進程的主線程中創建的,所以最終的結果是把創建 Service 的消息傳到了主線程,因此Service是運行在主線程中的。
H.java
private class H extends Handler {
.........
public void handleMessage(Message msg) {
if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));
switch (msg.what) {
case CREATE_SERVICE:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "serviceCreate");
handleCreateService((CreateServiceData)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
}
}
ActivityThread.java
private void handleCreateService(CreateServiceData data) {
.......
LoadedApk packageInfo = getPackageInfoNoCheck(
data.info.applicationInfo, data.compatInfo);
Service service = null;
try {
// 反射加載Service
java.lang.ClassLoader cl = packageInfo.getClassLoader();
service = (Service) cl.loadClass(data.info.name).newInstance();
} catch (Exception e) {
.......
}
try {
if (localLOGV) Slog.v(TAG, "Creating service " + data.info.name);
//創建ContextImpl對象
ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
context.setOuterContext(service);
//創建Application對象
Application app = packageInfo.makeApplication(false, mInstrumentation);
service.attach(context, this, data.info.name, data.token, app,
ActivityManagerNative.getDefault());
//回調onCreate方法
service.onCreate();
mServices.put(data.token, service);
try {
//調用服務創建完成
ActivityManagerNative.getDefault().serviceDoneExecuting(
data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
} catch (RemoteException e) {
// nothing to do.
}
} catch (Exception e) {
.......
}
}
到此Service的onCreate就回調了,那麼onStartCommand()何時回調呢?在realStartServiceLocked中調用了sendServiceArgsLocked(r, execInFg, true),sendServiceArgsLocked與上面類似,最終也是發送了一個(SERVICE_ARGS)消息。
ApplicationThread.java
public final void scheduleServiceArgs(IBinder token, boolean taskRemoved, int startId,
int flags ,Intent args) {
ServiceArgsData s = new ServiceArgsData();
s.token = token;
s.taskRemoved = taskRemoved;
s.startId = startId;
s.flags = flags;
s.args = args;
sendMessage(H.SERVICE_ARGS, s);
}
ActivityThread.java
private void handleServiceArgs(ServiceArgsData data) {
Service s = mServices.get(data.token);
if (s != null) {
try {
if (data.args != null) {
data.args.setExtrasClassLoader(s.getClassLoader());
data.args.prepareToEnterProcess();
}
int res;
if (!data.taskRemoved) {
//onStartCommand回調
res = s.onStartCommand(data.args, data.flags, data.startId);
} else {
s.onTaskRemoved(data.args);
res = Service.START_TASK_REMOVED_COMPLETE;
}
QueuedWork.waitToFinish();
try {
ActivityManagerNative.getDefault().serviceDoneExecuting(
data.token, SERVICE_DONE_EXECUTING_START, data.startId, res);
} catch (RemoteException e) {
// nothing to do.
}
ensureJitEnabled();
} catch (Exception e) {
......
}
}
}
Service的onCreate的回調和onStartCommand的回調套路是完全一樣的,朋友們可以自己體會,onCreate的回調先執行scheduleCreateService()方法,最終回調Service.onCreate(); onStartCommand的回調先執行scheduleServiceArgs()方法,最終回調Service.onStartCommand()。
總結一下:
IActivityManager接口中定義了AMS嚮應用程序(本例中即Activity)提供的多種API,Activity通過ActivityManagerProxy就可以使用這些API,向AMS發出請求,所以是通過ActivityManagerProxy,調用ActivityManagerProxy的startService方法,在內部調用transact,然後會調用ActivityManagerNative中的onTransact()方法,在該方法中,將會r完成AMS與Activity的連接並調用AMS的startService()方法,那麼AMS是如何Service所在的應用程序呢?比如scheduleCreateService。原來ApplicationThreadProxy 是應用進程的 ApplicatonThread 對象在 AMS 端的代理,AMS 靠它來和應用進程進行通信。這就是Activity與AMS之間的雙向Binder連接。Activity用IActivityManager提供的APIActivityManagerService提出執行某個動作的請求(本例中是啓動RemoteService),ActivityManagerService通過IApplicationThread提供的API來控制Activity所在的應用程序。
上面的分析省去了很多的內容,如果從進程角度看服務啓動過程。
Process A進程:是指調用startService命令所在的進程,也就是啓動服務的發起端進程。
system_server進程:系統進程,是java framework框架的核心載體,裏面運行了大量的系統服務,比如這裏提供ApplicationThreadProxy,ActivityManagerService,這個兩個服務都運行在system_server進程的不同線程中。
Zygote進程:是由init進程孵化而來的,用於創建Java層進程的母體,所有的Java層進程都是由Zygote進程孵化而來;
Remote Service進程:遠程服務所在進程,是由Zygote進程孵化而來的用於運行Remote服務的進程。主線程主要負責Activity/Service等組件的生命週期以及UI相關操作都運行在這個線程; 另外,每個App進程中至少會有兩個binder線程 ApplicationThread和ActivityManagerProxy
啓動流程:
- Process A進程採用Binder IPC向system_server進程發起startService請求;
- system_server進程接收到請求後,向zygote進程發送創建進程的請求;
- zygote進程fork出新的子進程Remote Service進程;
- Remote Service進程,通過Binder IPC向sytem_server進程發起attachApplication請求;
- system_server進程在收到請求後,進行一系列準備工作後,再通過binder IPC向remote Service進程發送scheduleCreateService請求;
- Remote Service進程的binder線程在收到請求後,通過handler向主線程發送CREATE_SERVICE消息;
- 主線程在收到Message後,通過發射機制創建目標Service,並回調Service.onCreate()方法。
到此,服務便正式啓動完成。當創建的是本地服務或者服務所屬進程已創建時,則無需經過上述步驟2、3,直接創建服務即可
參考:http://www.itdadao.com/articles/c15a1052268p0.html
http://gityuan.com/2016/03/06/start-service/
Please accept mybest wishes for your happiness and success !