#### 9.3.2 Service的綁定過程
和Service的啟動過程一樣，Service的綁定過程也是從ContextWrapper開始的，如下所示。
public boolean bindService(Intent service, ServiceConnection conn,
int flags) {
return mBase.bindService(service, conn, flags);
}
這個過程和Service的啟動過程是類似的，mBase同樣是ContextImpl類型的對象。ContextImpl的bindService方法最終會調用自己的bindServiceCommon方法，如下所示。
private boolean bindServiceCommon(Intent service, ServiceConnection conn,
int flags,
UserHandle user) {
IServiceConnection sd;
if (conn == null) {
throw new IllegalArgumentException("connection is null");
}
if (mPackageInfo ! = null) {
sd = mPackageInfo.getServiceDispatcher(conn, getOuterContext(),
mMainThread.getHandler(), flags);
} else {
throw new RuntimeException("Not supported in system context");
}
validateServiceIntent(service);
try {
IBinder token = getActivityToken();
if (token == null && (flags&BIND_AUTO_CREATE) == 0 && mPackageInfo ! =
null
&& mPackageInfo.getApplicationInfo().targetSdkVersion
< android.os.Build.VERSION_CODES.ICE_CREAM_SANDWICH) {
flags |= BIND_WAIVE_PRIORITY;
}
service.prepareToLeaveProcess();
int res = ActivityManagerNative.getDefault().bindService(
mMainThread.getApplicationThread(), getActivityToken(),
service, service.resolveTypeIfNeeded(getContentResolver()),
sd, flags, user.getIdentifier());
if (res < 0) {
throw new SecurityException(
"Not allowed to bind to service " + service);
}
return res ! = 0;
} catch (RemoteException e) {
return false;
}
}
bindServiceCommon方法主要完成如下兩件事情。
首先將客戶端的ServiceConnection對象轉化為ServiceDispatcher.InnerConnection對象。之所以不能直接使用ServiceConnection對象，這是因為服務的綁定有可能是跨進程的，因此ServiceConnection對象必須借助于Binder才能讓遠程服務端回調自己的方法，而ServiceDispatcher的內部類InnerConnection剛好充當了Binder這個角色。那么ServiceDispatcher的作用是什么呢？其實ServiceDispatcher起著連接ServiceConnection和InnerConnection的作用。這個過程由LoadedApk的getServiceDispatcher方法來完成，它的實現如下：
public final IServiceConnection getServiceDispatcher(ServiceConnection c,
Context context, Handler handler, int flags) {
synchronized (mServices) {
LoadedApk.ServiceDispatcher sd = null;
ArrayMap<ServiceConnection, LoadedApk.ServiceDispatcher> map =
mServices.get(context);
if (map ! = null) {
sd = map.get(c);
}
if (sd == null) {
sd = new ServiceDispatcher(c, context, handler, flags);
if (map == null) {
map = new ArrayMap<ServiceConnection, LoadedApk.Service-
Dispatcher>();
mServices.put(context, map);
}
map.put(c, sd);
} else {
sd.validate(context, handler);
}
return sd.getIServiceConnection();
}
}
在上面的代碼中，mServices是一個ArrayMap，它存儲了一個應用當前活動的ServiceConnection和ServiceDispatcher的映射關系，它的定義如下所示。
private final ArrayMap<Context, ArrayMap<ServiceConnection, LoadedApk.
ServiceDispatcher>> mServices = new ArrayMap<Context, ArrayMap
<ServiceConnection, LoadedApk.ServiceDispatcher>>();
系統首先會查找是否存在相同的ServiceConnection，如果不存在就重新創建一個ServiceDispatcher對象并將其存儲在mServices中，其中映射關系的key是ServiceConnection, value是ServiceDispatcher，在ServiceDispatcher的內部又保存了ServiceConnection和InnerConnection對象。當Service和客戶端建立連接后，系統會通過InnerConnection來調用ServiceConnection中的onServiceConnected方法，這個過程
有可能是跨進程的。當ServiceDispatcher創建好了以后，getServiceDispatcher會返回其保存的InnerConnection對象。
接著bindServiceCommon方法會通過AMS來完成Service的具體的綁定過程，這對應于AMS的bindService方法，如下所示。
public int bindService(IApplicationThread caller, IBinder token,
Intent service, String resolvedType,
IServiceConnection connection, int flags, int userId) {
enforceNotIsolatedCaller("bindService");
// Refuse possible leaked file descriptors
if (service ! = null && service.hasFileDescriptors() == true) {
throw new IllegalArgumentException("File descriptors passed in Intent");
}
synchronized(this) {
return mServices.bindServiceLocked(caller, token, service,
resolvedType,
connection, flags, userId);
}
}
接下來，AMS會調用ActiveServices的bindServiceLocked方法，bindServiceLocked再調用bringUpServiceLocked, bringUpServiceLocked又會調用realStartServiceLocked方法，realStartServiceLocked方法的執行邏輯和9.3.1節中的邏輯類似，最終都是通過ApplicationThread來完成Service實例的創建并執行其onCreate方法，這里不再重復講解了。和啟動Service不同的是，Service的綁定過程會調用app.thread的scheduleBindService方法，這個過程的實現在ActiveServices的requestServiceBindingLocked方法中，如下所示。
private final boolean requestServiceBindingLocked(ServiceRecord r,
IntentBindRecord i, boolean execInFg, boolean rebind) {
if (r.app == null || r.app.thread == null) {
// If service is not currently running, can't yet bind.
return false;
}
if ((! i.requested || rebind) && i.apps.size() > 0) {
try {
bumpServiceExecutingLocked(r, execInFg, "bind");
r.app.forceProcessStateUpTo(ActivityManager.PROCESS_STATE_
SERVICE);
r.app.thread.scheduleBindService(r, i.intent.getIntent(), rebind,
r.app.repProcState);
if (! rebind) {
i.requested = true;
}
i.hasBound = true;
i.doRebind = false;
} catch (RemoteException e) {
if (DEBUG_SERVICE) Slog.v(TAG, "Crashed while binding " + r);
return false;
}
}
return true;
}
在上述代碼中，app.thread這個對象多次出現過，對于它我們應該再熟悉不過了，它實際上就是ApplicationThread。ApplicationThread的一系列以schedule開頭的方法，其內部都是通過Handler H來中轉的，對于scheduleBindService方法來說也是如此，它的實現如下所示。
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);
}
在H內部，接收到BIND_SERVICE這類消息時，會交給ActivityThread的handleBind-Service方法來處理。在handleBindService中，首先根據Service的token取出Service對象，然后調用Service的onBind方法，Service的onBind方法會返回一個Binder對象給客戶端使用，這個過程我們在Service的開發過程中應該都比較熟悉了。原則上來說，Service的onBind方法被調用以后，Service就處于綁定狀態了，但是onBind方法是Service的方法，這個時候客戶端并不知道已經成功連接Service了，所以還必須調用客戶端的ServiceConnection中的onServiceConnected，這個過程是由ActivityManagerNative.getDefault()的publishService方法來完成的，而前面多次提到，ActivityManagerNative.getDefault()就是AMS。handleBindService的實現過程如下所示。
```
private void handleBindService(BindServiceData data) {
Service s = mServices.get(data.token);
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) {
IBinder binder = s.onBind(data.intent);
ActivityManagerNative.getDefault().publishService(
data.token, data.intent, binder);
} else {
s.onRebind(data.intent);
ActivityManagerNative.getDefault().serviceDoneExecuting(
data.token, 0, 0, 0);
}
ensureJitEnabled();
} catch (RemoteException ex) {
}
} catch (Exception e) {
if (! mInstrumentation.onException(s, e)) {
throw new RuntimeException(
"Unable to bind to service " + s
+ " with " + data.intent + ": " + e.toString(), e);
}
}
}
}
```
Service有一個特性，當多次綁定同一個Service時，Service的onBind方法只會執行一次，除非Service被終止了。當Service的onBind執行以后，系統還需要告知客戶端已經成功連接Service了。根據上面的分析，這個過程由AMS的publishService方法來實現，它的源碼如下所示。
public void publishService(IBinder token, Intent intent, IBinder service) {
// Refuse possible leaked file descriptors
if (intent ! = null && intent.hasFileDescriptors() == true) {
throw new IllegalArgumentException("File descriptors passed in
Intent");
}
synchronized(this) {
if (! (token instanceof ServiceRecord)) {
throw new IllegalArgumentException("Invalid service token");
}
mServices.publishServiceLocked((ServiceRecord)token, intent,
service);
}
}
從上面代碼可以看出，AMS的publishService方法將具體的工作交給了ActiveServices類型的mServices對象來處理。ActiveServices的publishServiceLocked方法看起來很復雜，但其實核心代碼就只有一句話：c.conn.connected(r.name, service)，其中c的類型是ConnectionRecord, c.conn的類型是ServiceDispatcher.InnerConnection, service就是Service的onBind方法返回的Binder對象。為了分析具體的邏輯，下面看一下ServiceDispatcher. InnerConnection的定義，如下所示。
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);
}
}
}
從InnerConnection的定義可以看出，它的connected方法又調用了ServiceDispatcher的connected方法，ServiceDispatcher的connected方法的實現如下所示。
public void connected(ComponentName name, IBinder service) {
if (mActivityThread ! = null) {
mActivityThread.post(new RunConnection(name, service, 0));
} else {
doConnected(name, service);
}
}
對于Service的綁定過程來說，ServiceDispatcher的mActivityThread是一個Handler，其實它就是ActivityThread中的H，從前面ServiceDispatcher的創建過程來說，mActivityThread不會為null，這樣一來，RunConnection就可以經由H的post方法從而運行在主線程中，因此，客戶端ServiceConnection中的方法是在主線程被回調的。RunConnection的定義如下所示。
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方法也是簡單調用了ServiceDispatcher的doConnected方法，由于ServiceDispatcher內部保存了客戶端的ServiceConnection對象，因此它可以很方便地調用ServiceConnection對象的onServiceConnected方法，如下所示。
// If there is a new service, it is now connected.
if (service ! = null) {
mConnection.onServiceConnected(name, service);
}
客戶端的onServiceConnected方法執行后，Service的綁定過程也就分析完成了，至于Service的停止過程和解除綁定的過程，系統的執行過程是類似的，讀者可以自行分析源碼，這里就不再分析了。
- 前言
- 第1章 Activity的生命周期和啟動模式
- 1.1 Activity的生命周期全面分析
- 1.1.1 典型情況下的生命周期分析
- 1.1.2 異常情況下的生命周期分析
- 1.2 Activity的啟動模式
- 1.2.1 Activity的LaunchMode
- 1.2.2 Activity的Flags
- 1.3 IntentFilter的匹配規則
- 第2章 IPC機制
- 2.1 Android IPC簡介
- 2.2 Android中的多進程模式
- 2.2.1 開啟多進程模式
- 2.2.2 多進程模式的運行機制
- 2.3 IPC基礎概念介紹
- 2.3.1 Serializable接口
- 2.3.2 Parcelable接口
- 2.3.3 Binder
- 2.4 Android中的IPC方式
- 2.4.1 使用Bundle
- 2.4.2 使用文件共享
- 2.4.3 使用Messenger
- 2.4.4 使用AIDL
- 2.4.5 使用ContentProvider
- 2.4.6 使用Socket
- 2.5 Binder連接池
- 2.6 選用合適的IPC方式
- 第3章 View的事件體系
- 3.1 View基礎知識
- 3.1.1 什么是View
- 3.1.2 View的位置參數
- 3.1.3 MotionEvent和TouchSlop
- 3.1.4 VelocityTracker、GestureDetector和Scroller
- 3.2 View的滑動
- 3.2.1 使用scrollTo/scrollBy
- 3.2.2 使用動畫
- 3.2.3 改變布局參數
- 3.2.4 各種滑動方式的對比
- 3.3 彈性滑動
- 3.3.1 使用Scroller7
- 3.3.2 通過動畫
- 3.3.3 使用延時策略
- 3.4 View的事件分發機制
- 3.4.1 點擊事件的傳遞規則
- 3.4.2 事件分發的源碼解析
- 3.5 View的滑動沖突
- 3.5.1 常見的滑動沖突場景
- 3.5.2 滑動沖突的處理規則
- 3.5.3 滑動沖突的解決方式
- 第4章 View的工作原理
- 4.1 初識ViewRoot和DecorView
- 4.2 理解MeasureSpec
- 4.2.1 MeasureSpec
- 4.2.2 MeasureSpec和LayoutParams的對應關系
- 4.3 View的工作流程
- 4.3.1 measure過程
- 4.3.2 layout過程
- 4.3.3 draw過程
- 4.4 自定義View
- 4.4.1 自定義View的分類
- 4.4.2 自定義View須知
- 4.4.3 自定義View示例
- 4.4.4 自定義View的思想
- 第5章 理解RemoteViews
- 5.1 RemoteViews的應用
- 5.1.1 RemoteViews在通知欄上的應用
- 5.1.2 RemoteViews在桌面小部件上的應用
- 5.1.3 PendingIntent概述
- 5.2 RemoteViews的內部機制
- 5.3 RemoteViews的意義
- 第6章 Android的Drawable
- 6.1 Drawable簡介
- 6.2 Drawable的分類
- 6.2.1 BitmapDrawable2
- 6.2.2 ShapeDrawable
- 6.2.3 LayerDrawable
- 6.2.4 StateListDrawable
- 6.2.5 LevelListDrawable
- 6.2.6 TransitionDrawable
- 6.2.7 InsetDrawable
- 6.2.8 ScaleDrawable
- 6.2.9 ClipDrawable
- 6.3 自定義Drawable
- 第7章 Android動畫深入分析
- 7.1 View動畫
- 7.1.1 View動畫的種類
- 7.1.2 自定義View動畫
- 7.1.3 幀動畫
- 7.2 View動畫的特殊使用場景
- 7.2.1 LayoutAnimation
- 7.2.2 Activity的切換效果
- 7.3 屬性動畫
- 7.3.1 使用屬性動畫
- 7.3.2 理解插值器和估值器 /
- 7.3.3 屬性動畫的監聽器
- 7.3.4 對任意屬性做動畫
- 7.3.5 屬性動畫的工作原理
- 7.4 使用動畫的注意事項
- 第8章 理解Window和WindowManager
- 8.1 Window和WindowManager
- 8.2 Window的內部機制
- 8.2.1 Window的添加過程
- 8.2.2 Window的刪除過程
- 8.2.3 Window的更新過程
- 8.3 Window的創建過程
- 8.3.1 Activity的Window創建過程
- 8.3.2 Dialog的Window創建過程
- 8.3.3 Toast的Window創建過程
- 第9章 四大組件的工作過程
- 9.1 四大組件的運行狀態
- 9.2 Activity的工作過程
- 9.3 Service的工作過程
- 9.3.1 Service的啟動過程
- 9.3.2 Service的綁定過程
- 9.4 BroadcastReceiver的工作過程
- 9.4.1 廣播的注冊過程
- 9.4.2 廣播的發送和接收過程
- 9.5 ContentProvider的工作過程
- 第10章 Android的消息機制
- 10.1 Android的消息機制概述
- 10.2 Android的消息機制分析
- 10.2.1 ThreadLocal的工作原理
- 10.2.2 消息隊列的工作原理
- 10.2.3 Looper的工作原理
- 10.2.4 Handler的工作原理
- 10.3 主線程的消息循環
- 第11章 Android的線程和線程池
- 11.1 主線程和子線程
- 11.2 Android中的線程形態
- 11.2.1 AsyncTask
- 11.2.2 AsyncTask的工作原理
- 11.2.3 HandlerThread
- 11.2.4 IntentService
- 11.3 Android中的線程池
- 11.3.1 ThreadPoolExecutor
- 11.3.2 線程池的分類
- 第12章 Bitmap的加載和Cache
- 12.1 Bitmap的高效加載
- 12.2 Android中的緩存策略
- 12.2.1 LruCache
- 12.2.2 DiskLruCache
- 12.2.3 ImageLoader的實現446
- 12.3 ImageLoader的使用
- 12.3.1 照片墻效果
- 12.3.2 優化列表的卡頓現象
- 第13章 綜合技術
- 13.1 使用CrashHandler來獲取應用的crash信息
- 13.2 使用multidex來解決方法數越界
- 13.3 Android的動態加載技術
- 13.4 反編譯初步
- 13.4.1 使用dex2jar和jd-gui反編譯apk
- 13.4.2 使用apktool對apk進行二次打包
- 第14章 JNI和NDK編程
- 14.1 JNI的開發流程
- 14.2 NDK的開發流程
- 14.3 JNI的數據類型和類型簽名
- 14.4 JNI調用Java方法的流程
- 第15章 Android性能優化
- 15.1 Android的性能優化方法
- 15.1.1 布局優化
- 15.1.2 繪制優化
- 15.1.3 內存泄露優化
- 15.1.4 響應速度優化和ANR日志分析
- 15.1.5 ListView和Bitmap優化
- 15.1.6 線程優化
- 15.1.7 一些性能優化建議
- 15.2 內存泄露分析之MAT工具
- 15.3 提高程序的可維護性