深入理解四大元件（四）Service 的繫結過程
概述
我們可以通過呼叫 Context 的 startService 來啟動 Service，也可以通過 Context 的 bindService 來繫結 ServiceService 的繫結過程將分為兩個部分來進行講解，分別是 ContextImpl 到 AMS 的呼叫過程和 Service 的繫結過程。
1. ContextImpl 到 AMS 的呼叫過程
ContextImpl 到 AMS 的呼叫過程如圖所示：
我們可以用 bindService 方法來繫結 Service，它的實現在 ContextWrapper 中，程式碼如下所示：
frameworks/base/core/java/android/content/ContextWrapper.java
@Override
public boolean bindService(Intent service, ServiceConnection conn,
int flags) {
return mBase.bindService(service, conn, flags);
}
上一章我們得知 mBase 具體就是指向 ContextImpl 的，接著檢視 ContextImpl 的 bindService 方法：
frameworks/base/core/java/android/app/ContextImpl.java
@Override
public boolean bindService(Intent service, ServiceConnection conn,
int flags) {
warnIfCallingFromSystemProcess();
return bindServiceCommon(service, conn, flags, mMainThread.getHandler(),
Process.myUserHandle());
}
在 bindService 方法中，又返回了 bindServiceCommon 方法，程式碼如下所示：
frameworks/base/core/java/android/app/ContextImpl.java
private boolean bindServiceCommon(Intent service, ServiceConnection conn, int flags, Handler
handler, UserHandle user) {
IServiceConnection sd;
if (conn == null) {
throw new IllegalArgumentException("connection is null");
}
if (mPackageInfo != null) {
sd = mPackageInfo.getServiceDispatcher(conn, getOuterContext(), handler, flags); //1
} else {
throw new RuntimeException("Not supported in system context");
}
validateServiceIntent(service);
try {
...
/**
* 2
*/
int res = ActivityManagerNative.getDefault().bindService(
mMainThread.getApplicationThread(), getActivityToken(), service,
service.resolveTypeIfNeeded(getContentResolver()),
sd, flags, getOpPackageName(), user.getIdentifier());
...
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
}
在註釋 1 處呼叫了 LoadedApk 型別的物件 mPackageInfo 的 getServiceDispatcher 方法，它的主要作用是將 ServiceConnection 封裝為 IServiceConnection 型別的物件 sd，從 IServiceConnection 的名字我們就能得知它實現了 Binder 機制，這樣 Service 的繫結就支援了跨程式。接著在註釋 2 處我們又看見了熟悉的程式碼，最終會呼叫 AMS 的 bindService 方法。
2. Service 的繫結過程
AMS 的 bindService 方法程式碼如下所示：
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
public int bindService(IApplicationThread caller, IBinder token, Intent service,
String resolvedType, IServiceConnection connection, int flags, String callingPackage,
int userId) throws TransactionTooLargeException {
enforceNotIsolatedCaller("bindService");
...
synchronized(this) {
return mServices.bindServiceLocked(caller, token, service,
resolvedType, connection, flags, callingPackage, userId);
}
}
bindService 方法最後會呼叫 ActiveServices 型別的物件 mServices 的 bindServiceLocked 方法：
frameworks/base/services/core/java/com/android/server/am/ActiveServices.java
int bindServiceLocked(IApplicationThread caller, IBinder token, Intent service,
String resolvedType, final IServiceConnection connection, int flags,
String callingPackage, final int userId) throws TransactionTooLargeException {
···
try {
···
AppBindRecord b = s.retrieveAppBindingLocked(service, callerApp); //1
···
if ((flags&Context.BIND_AUTO_CREATE) != 0) {
s.lastActivity = SystemClock.uptimeMillis();
if (bringUpServiceLocked(s, service.getFlags(), callerFg, false,
permissionsReviewRequired) != null) { //2
return 0;
}
}
···
if (s.app != null && b.intent.received) { //3
try {
c.conn.connected(s.name, b.intent.binder, false); //4
} catch (Exception e) {
Slog.w(TAG, "Failure sending service " + s.shortName
+ " to connection " + c.conn.asBinder()
+ " (in " + c.binding.client.processName + ")", e);
}
if (b.intent.apps.size() == 1 && b.intent.doRebind) { //5
requestServiceBindingLocked(s, b.intent, callerFg, true); //6
}
} else if (!b.intent.requested) { //7
requestServiceBindingLocked(s, b.intent, callerFg, false); //8
}
getServiceMapLocked(s.userId).ensureNotStartingBackgroundLocked(s);
} finally {
Binder.restoreCallingIdentity(origId);
}
return 1;
}
講到這裡，有必要先介紹幾個與 Service 相關的物件型別，這樣有助於對原始碼進行理解，如下所示：
- ServiceRecord：用於描述一個 Service。
- ProcessRecord：一個程式的資訊。
- ConnectionRecord：用於描述應用程式程式和 Service 建立的一次通訊。
- AppBindRecord：應用程式程式通過 Intent 繫結 Service 時，會通過 AppBindRecord 來維護 Service 與應用程式程式之間的關聯。其內部儲存了誰繫結的 Service（ProcessRecord）、被繫結的 Service（AppBindRecord ）、繫結 Service 的 Intent（IntentBindRecord）和所有繫結通訊記錄的資訊（ArraySet<ConnectionRecord>）。
- IntentBindRecord：用於描述繫結 Service 的 Intent。
在註釋 1 處呼叫了 ServiceRecord 的 retrieveAppBindingLocked 方法來獲得 AppBindRecord，retrieveAppBindingLocked 方法內部建立 IntentBindRecord，並對 IntentBindRecord 的成員變數進行賦值，後面我們會詳細極少這個關鍵的方法。
在註釋 2 處呼叫 bringUpServiceLocked 方法，在 bringUpServiceLocked 方法中又呼叫 realStartServiceLocked 方法，最終由 ActivityThread 來呼叫 Service 的 onCreate 方法啟動 Service，這也說明了 bindService 方法內部會啟動 Service，啟動 Service 這一過程上一章我們已經講過。在註釋 3 處 s.app != null 表示 Service 已經執行，其中 s 是 ServiceRecord 型別物件，app 是 ProcessRecord 型別物件。b.intent.received 表示當前應用程式程式已經接受到繫結 Service 時返回的 Binder，這樣應用程式程式就可以通過 Binder 來獲取要繫結的 Service 的訪問介面。在註釋 4 處呼叫 c.conn 的 connected 方法，其中 c.conn 指的是 IServiceConnection，它的具體實現為 ServiceDispatcher.InnerConnection，其中 ServiceDispathcer 是 LoadedApk 的內部類，InnerConnection 的 connected 方法內部會呼叫 H 的 post 方法向主執行緒傳送訊息，並且解決當前應用程式程式和 Service 跨程式通訊的問題，在後面會詳細介紹這一過程。在註釋 5 處如果當前應用程式程式是第一個與 Service 進行繫結的，並且 Service 已經呼叫過 onUnBind 方法，則需要呼叫註釋 6 處的程式碼。在註釋 7 處如果應用程式程式的 Client 端沒有傳送過繫結 Service 的請求，則會呼叫註釋 8 處的程式碼，註釋 8 處和註釋 6 處的程式碼區別就是最後一個引數 rebind 為 false，表示不是重新繫結。接著我們檢視註釋 6 處的 requestServiceBindingLocked 方法，程式碼如下所示：
frameworks/base/services/core/java/com/android/server/am/ActiveServices.java
private final boolean requestServiceBindingLocked(ServiceRecord r, IntentBindRecord i,
boolean execInFg, boolean rebind) throws TransactionTooLargeException {
...
if ((!i.requested || rebind) && i.apps.size() > 0) { //1
try {
bumpServiceExecutingLocked(r, execInFg, "bind");
r.app.forceProcessStateUpTo(ActivityManager.PROCESS_STATE_SERVICE);
r.app.thread.scheduleBindService(r, i.intent.getIntent(), rebind,
r.app.repProcState); //2
...
}
...
}
return true;
}
註釋 1 處 i.requested 表示是否傳送過繫結 Service 的請求，從前面的程式碼得知是沒有傳送過，因此，!i.requested 為 true。從前面的程式碼得知 rebind 值為 false，那麼 (!i.requested || rebind) 的值為 true。i.apps.size() > 0 表示什麼呢？其中 i 是 IntentBindRecord 型別的物件，AMS 會為每個繫結 Service 的 Intent 分配一個 IntentBindRecord 型別物件，程式碼如下所示：
frameworks/base/services/core/java/com/android/server/am/IntentBindRecord.java
final class IntentBindRecord {
//被繫結的 Service
final ServiceRecord service;
//繫結 Service 的 Intent
final Intent.FilterComparison intent; //
//所有用當前 Intent 繫結 Service 的應用程式程式
final ArrayMap<ProcessRecord, AppBindRecord> apps
= new ArrayMap<ProcessRecord, AppBindRecord>(); //1
···
}
我們來檢視 IntentBindRecord 類，不同的應用程式程式可能使用同一個 Intent 來繫結 Service，因此在註釋 1 處會用 apps 來儲存所有用當前 Intent 繫結 Service 的應用程式程式。i.apps.size() > 0 表示所有用當前 Intent 繫結 Service 的應用程式程式個數大於 0，下面來驗證 i.apps.size() > 0 是否為 ture。我們回到 bindServiceLocked 方法的註釋 1 處，ServiceRecord 的 retrieveAPPBindingLocked 方法如下所示：
frameworks/base/services/core/java/com/android/server/am/ServiceRecord.java
public AppBindRecord retrieveAppBindingLocked(Intent intent,
ProcessRecord app) {
Intent.FilterComparison filter = new Intent.FilterComparison(intent);
IntentBindRecord i = bindings.get(filter);
if (i == null) {
i = new IntentBindRecord(this, filter); //1
bindings.put(filter, i);
}
AppBindRecord a = i.apps.get(app); //2
if (a != null) {
return a;
}
a = new AppBindRecord(this, i, app); //3
i.apps.put(app, a);
return a;
}
註釋 1 處建立了 IntentBindRecord，註釋 2 處根據 ProcessRecord 獲得 IntentBindRecord 中儲存的 AppBindRecord，如果 AppBindRecord 不為 null 就返回，如果不為 null 就在註釋 3 處建立 AppBindRecord，並將 ProcessRecord 作為 key，AppBindRecord 作為 value 儲存在 IntentBindRecord 的 apps（i.apps）中。回到 requestServiceBindingLocked 方法的註釋 1 處，結合 ServiceRecord 的 requestServiceBindingLocked 方法，我們得知 i.apps.size() > 0 為 ture，這樣就會呼叫註釋 2 處的程式碼，r.app.thread 的型別為 IApplicationThread，它的實現我們已經很熟悉了，是 ActivityThread 的內部類 ApplicationThread，scheduleBindService 方法如下所示：
frameworks/base/core/java/android/app/ActivityThread.java
public final void scheduleBindService(IBinder token, Intent intent,
boolean rebind, int processState) {
updateProcessState(processState, false);
BindServiceData s = new BindServiceData();
s.token = token;
s.intent = intent;
s.rebind = rebind;
if (DEBUG_SERVICE)
Slog.v(TAG, "scheduleBindService token=" + token + " intent=" + intent + " uid="
+ Binder.getCallingUid() + " pid=" + Binder.getCallingPid());
sendMessage(H.BIND_SERVICE, s);
}
首先將 Service 的資訊封裝成 BindServiceData 物件，需要注意的 BindServiceData 的成員變數 rebind 的值為 false，後面會用到它。接著將 BindServiceData 傳入到 sendMessage 方法中。sendMessage 向 H 傳送訊息，我們接著檢視 H 的 handleMessage 方法：
frameworks/base/core/java/android/app/ActivityThread.java
public void handleMessage(Message msg) {
if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));
switch (msg.what) {
...
case BIND_SERVICE:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "serviceBind");
handleBindService((BindServiceData)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
break;
...
}
...
}
H 在接受到 BIND_SERVICE 型別訊息時，會在 handleMessage 方法中會呼叫 handleBindService 方法：
frameworks/base/core/java/android/app/ActivityThread.java
private void handleBindService(BindServiceData data) {
Service s = mServices.get(data.token); //1
if (DEBUG_SERVICE)
Slog.v(TAG, "handleBindService s=" + s + " rebind=" + data.rebind);
if (s != null) {
try {
data.intent.setExtrasClassLoader(s.getClassLoader());
data.intent.prepareToEnterProcess();
try {
if (!data.rebind) { //2
IBinder binder = s.onBind(data.intent); //3
ActivityManager.getService().publishService(
data.token, data.intent, binder); //4
} else {
s.onRebind(data.intent); //5
ActivityManager.getService().serviceDoneExecuting(
data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
}
ensureJitEnabled();
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
}
} catch (Exception e) {
if (!mInstrumentation.onException(s, e)) {
throw new RuntimeException(
"Unable to bind to service " + s
+ " with " + data.intent + ": " + e.toString(), e);
}
}
}
}
在註釋 1 處獲取要繫結的 Service。註釋 2 處的 BindServiceData 的成員變數 rebind 的值為 false，這樣會呼叫註釋 3 處的程式碼來呼叫 Service 的 onBind 方法，到這裡 Service 處於繫結狀態了。如果 rebind 的值為 ture 就會呼叫註釋 5 處的 Service 的 onRebind 方法，這一點結合前文的 bindServiceLocked 方法的註釋 5 處，得出的結論就是：如果當前應用程式程式第一個與 Service 進行繫結，並且 Service 已經呼叫過 onUnBind 方法，則會呼叫 Service 的 onBind 方法。handleBindService 方法有兩個分支，一個是繫結過 Service 的情況，另一個是未繫結的情況，這裡分析未繫結的情況，檢視註釋 4 處的程式碼，實際上是呼叫 AMS 的 publishService 方法。講到這，先給出這一部分的程式碼時序圖（不包括 Service 啟動過程）
接著來檢視 AMS 的 publishService 方法，程式碼如下所示：
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
public void publishService(IBinder token, Intent intent, IBinder service) {
...
synchronized(this) {
if (!(token instanceof ServiceRecord)) {
throw new IllegalArgumentException("Invalid service token");
}
mServices.publishServiceLocked((ServiceRecord)token, intent, service);
}
}
publishService 方法中，呼叫了 ActiveServices 型別的 mServices 物件的 publishServiceLocked 方法：
frameworks/base/services/core/java/com/android/server/am/ActiveServices.java
void publishServiceLocked(ServiceRecord r, Intent intent, IBinder service) {
final long origId = Binder.clearCallingIdentity();
try {
...
for (int conni=r.connections.size()-1; conni>=0; conni--) {
ArrayList<ConnectionRecord> clist = r.connections.valueAt(conni);
for (int i=0; i<clist.size(); i++) {
...
try {
c.conn.connected(r.name, service); //1
} catch (Exception e) {
...
}
}
}
}
serviceDoneExecutingLocked(r, mDestroyingServices.contains(r), false);
}
} finally {
Binder.restoreCallingIdentity(origId);
}
}
註釋 1 處的程式碼，我在前面介紹過，c.conn 指的是 IServiceConnection，它是 ServiceConnection 在本地的代理，用於解決當前應用程式程式和 Service 跨程式通訊的問題，具體實現為 ServiceDispatcher.InnerConnection，其中 ServiceDispatcher 是 LoadedApk 的內部類，ServiceDispatcher.InnerConnectiond 的 connected 方法的程式碼如下所示：
frameworks/base/core/java/android/app/LoadedApk.java
static final class ServiceDispatcher {
...
private static class InnerConnection extends IServiceConnection.Stub {
final WeakReference<LoadedApk.ServiceDispatcher> mDispatcher;
InnerConnection(LoadedApk.ServiceDispatcher sd) {
mDispatcher = new WeakReference<LoadedApk.ServiceDispatcher>(sd);
}
public void connected(ComponentName name, IBinder service) throws RemoteException {
LoadedApk.ServiceDispatcher sd = mDispatcher.get();
if (sd != null) {
sd.connected(name, service); //1
}
}
}
...
}
在註釋 1 處呼叫了 ServiceDispatcher 型別的 sd 物件的 connected 方法，程式碼如下所示：
frameworks/base/core/java/android/app/LoadedApk.java
public void connected(ComponentName name, IBinder service) {
if (mActivityThread != null) {
mActivityThread.post(new RunConnection(name, service, 0)); //1
} else {
doConnected(name, service);
}
}
註釋 1 處呼叫 Handler 型別的物件 mActivityThread 的 post 方法，mActivityThread 實際上指向的是 H。因此，通過呼叫 H 的 post 方法將 RunConnection 物件的內容執行在主執行緒中。RunConnection 是 LoadedApk 的內部類，定義如下所示：
frameworks/base/core/java/android/app/LoadedApk.java
private final class RunConnection implements Runnable {
RunConnection(ComponentName name, IBinder service, int command) {
mName = name;
mService = service;
mCommand = command;
}
public void run() {
if (mCommand == 0) {
doConnected(mName, mService);
} else if (mCommand == 1) {
doDeath(mName, mService);
}
}
final ComponentName mName;
final IBinder mService;
final int mCommand;
}
在 RunConnection 的 run 方法中呼叫了 doConnected 方法：
frameworks/base/core/java/android/app/LoadedApk.java
public void doConnected(ComponentName name, IBinder service) {
...
if (old != null) {
mConnection.onServiceDisconnected(name);
}
if (service != null) {
mConnection.onServiceConnected(name, service); //1
}
}
在註釋 1 處呼叫了 ServiceConnection 型別的物件 mConnection 的 onServiceConnected 方法，這樣在客戶端中實現了 ServiceConnection 介面的類的 onServiceConnected 方法就會被執行。至此，Service 的繫結過程就分析到這。
最後給出剩餘部分的程式碼時序圖：
相關文章
- Android深入四大元件（三）Service的繫結過程Android元件
- Android深入四大元件（二）Service的啟動過程Android元件
- 【Android原始碼】Service的繫結過程Android原始碼
- 四大元件之 Service元件
- Android深入四大元件（五）Content Provider的啟動過程Android元件IDE
- Android 四大元件之 ServiceAndroid元件
- Android 四大元件之" Service "Android元件
- Android四大元件之Service篇Android元件
- 四大元件之Service_AIDL元件AI
- Android 四大元件之二-------ServiceAndroid元件
- Android四大元件之Service，以及IntentServiceAndroid元件Intent
- 第七章：四大元件之Service元件
- Android深入四大元件（六）Android8.0 根Activity啟動過程（前篇）Android元件
- Android深入四大元件（七）Android8.0 根Activity啟動過程（後篇）Android元件
- Android學習之四大元件（二）——serviceAndroid元件
- Android必知必會的四大元件 -- Service篇Android元件
- IOC容器的繫結解析過程(繫結單例)單例
- 深入理解 C++ 的動態繫結和靜態繫結C++
- 四大元件以及Application和Context的全面理解元件APPContext
- Android原始碼解析四大元件系列（八）---廣播幾個問題的深入理解Android原始碼元件
- 深入理解ORACLE啟動過程Oracle
- 深入理解 iOS App 的啟動過程iOSAPP
- 深入理解ES6--1.塊級繫結
- 深入理解linux啟動過程Linux
- 【AAC 系列四】深入理解架構元件：ViewModel架構元件View
- 四大元件之Activity元件
- 深入理解Logger日誌——框架繫結原理框架
- 深入理解Linux啟動過程薦Linux
- 深入理解 C 語言的函式呼叫過程函式
- 深入理解Fabric環境搭建的詳細過程
- 深入理解C語言的函式呼叫過程C語言函式
- 透過 Chrome 深入理解瀏覽器導航過程Chrome瀏覽器
- JavaScript 進階之深入理解資料雙向繫結JavaScript
- （一） Android 四大元件Android元件
- Android之四大元件Android元件
- Android四大元件概述Android元件
- Android 四大元件的解讀Android元件
- 深入理解 HTTPS 原理、過程與實踐HTTP