Android中bindService是一個異步的過程,什麼意思呢?
使用bindService無非是想獲得一個Binder服務的Proxy,但這個代理獲取到的時機並非由bindService發起端控制,而是由Service端來控制,也就是說bindService之後,APP端並不會立刻獲得Proxy,而是要等待Service通知APP端,具體流程可簡化如下:
- APP端先通過bindService去AMS登記,說明自己需要綁定這樣一個服務,並留下派送地址
- APP回來,繼續做其他事情,可以看做是非阻塞的
- AMS通知Service端啓動這個服務
- Service啓動,並通知AMS啓動完畢
- AMS跟住之前APP端留下的地址通知APP端,並將Proxy代理傳遞給APP端
通過代碼來看更直接
void test(){
bindService(intent, new ServiceConnection() {
@Override
public void onServiceConnected(ComponentName componentName, IBinder iBinder) {
iMyAidlInterface = IMyAidlInterface.Stub.asInterface(iBinder);
Log.v(TAG, "onServiceConnected..." );
}
@Override
public void onServiceDisconnected(ComponentName componentName) {
}
}, Context.BIND_AUTO_CREATE);
Log.v(TAG, "end..." );
}
bindService的過程中,上面代碼的Log應該是怎麼樣的呢?如果bindService是一個同步過程,那麼Log應該如下:
TAG onServiceConnected ...
TAG end ...
但是由於是個異步過程,真實的Log如下
TAG end ...
TAG onServiceConnected ...
也就是說bindService不會阻塞等待APP端獲取Proxy,而是直接返回,這些都可以從源碼獲得支持,略過,直接去ActivityManagerNative去看
public int bindService(IApplicationThread caller, IBinder token,
Intent service, String resolvedType, IServiceConnection connection,
int flags, int userId) throws RemoteException {
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
data.writeInterfaceToken(IActivityManager.descriptor);
data.writeStrongBinder(caller != null ? caller.asBinder() : null);
data.writeStrongBinder(token);
service.writeToParcel(data, 0);
data.writeString(resolvedType);
data.writeStrongBinder(connection.asBinder());
data.writeInt(flags);
data.writeInt(userId);
<!--阻塞等待-->
mRemote.transact(BIND_SERVICE_TRANSACTION, data, reply, 0);
reply.readException();
int res = reply.readInt();
data.recycle();
reply.recycle();
return res;
}
mRemote.transact(BIND_SERVICE_TRANSACTION, data, reply, 0)確實會讓APP端調用線程阻塞,等待AMS執行BIND_SERVICE_TRANSACTION請求,不過AMS在執行這個請求的時候並非是喚醒Service才返回,它返回的時機更早,接着看ActivityManagerService,
public int bindService(IApplicationThread caller, IBinder token,
Intent service, String resolvedType,
IServiceConnection connection, int flags, int userId) {
...
synchronized(this) {
return mServices.bindServiceLocked(caller, token, service, resolvedType,
connection, flags, userId);
}
}
ActivityManagerService直接調用ActiveServices的函數bindServiceLocked,請求綁定Service,到這裏APP端線程依舊阻塞,等待AMS端返回,假定Service所處的進程已經啓動但是Service沒有啓動,這時ActiveServices會進一步調用bindServiceLocked->realStartServiceLocked來啓動Service,有趣的就在這裏:
private final void realStartServiceLocked(ServiceRecord r,
Proce***ecord app) throws RemoteException {
...
<!--請求Service端啓動Service-->
app.thread.scheduleCreateService(r, r.serviceInfo,
mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo));
...
<!--請求綁定Service-->
requestServiceBindingsLocked(r);
app.thread.scheduleCreateService也是一個Binder通信過程,他其實是AMS異步請求ActivityThread中的ApplicationThread服務,系統服務請求客戶端的本地服務一般都是異步的:
// 插入消息,等待主線程執行
public final void scheduleCreateService(IBinder token,
ServiceInfo info, CompatibilityInfo compatInfo) {
CreateServiceData s = new CreateServiceData();
s.token = token;
s.info = info;
s.compatInfo = compatInfo;
<!--向Loop的MessagerQueue插入一條消息就返回-->
queueOrSendMessage(H.CREATE_SERVICE, s);
}
不過,這個請求直接向Service端的ActivityThread線程中直接插入一個消息就返回了,而並未等到該請求執行,因爲AMS使用的非常頻繁,不可能老等待客戶端完成一些任務,所以AMS端向客戶端發送完命令就直接返回,這個時候其實Service還沒有被創建,也就是這個請求只是完成了一半,onServiceConnected也並不會執行,onServiceConnected什麼時候執行呢?app.thread.scheduleCreateService向APP端插入第一條消息,是用來創建Service的, requestServiceBindingsLocked其實就是第二條消息,用來處理綁定的
private final boolean requestServiceBindingLocked(ServiceRecord r,
IntentBindRecord i, boolean rebind) {
...
<!-- 第二個消息,請求處理綁定-->
r.app.thread.scheduleBindService(r, i.intent.getIntent(), rebind);
第二條消息是處理一些綁定需求,Android的Hanlder消息處理機制保證了第二條消息一定是在第一條消息之後執行,
public final void scheduleBindService(IBinder token, Intent intent,
boolean rebind) {
BindServiceData s = new BindServiceData();
s.token = token;
s.intent = intent;
s.rebind = rebind;
queueOrSendMessage(H.BIND_SERVICE, s);
}
以上兩條消息插入後,AMS端被喚醒,進而重新喚醒之前阻塞的bindService端,而這個時候,Service並不一定被創建,所以說這是個未知的異步過程,Service端處理第一條消息的時會創建Service,
private void handleCreateService(CreateServiceData data) {
...
LoadedApk packageInfo = getPackageInfoNoCheck(
data.info.applicationInfo, data.compatInfo);
Service service = null;
try {
java.lang.ClassLoader cl = packageInfo.getClassLoader();
service = (Service) cl.loadClass(data.info.name).newInstance();
...
執行第二條消息的時候, 會向AMS請求publishService,其實就是告訴AMS,服務啓動完畢,可以向之前請求APP端派發代理了。
private void handleBindService(BindServiceData data) {
Service s = mServices.get(data.token);
if (s != null) {
try {
data.intent.setExtrasClassLoader(s.getClassLoader());
try {
if (!data.rebind) {
IBinder binder = s.onBind(data.intent);
ActivityManagerNative.getDefault().publishService(
data.token, data.intent, binder);
...
AMS端收到publishService消息之後,纔會向APP端發送通知,進而通過Binder回調APP端onServiceConnected函數,同時傳遞Proxy Binder服務代理
void publishServiceLocked(ServiceRecord r, Intent intent, IBinder service) {
...
try {
<!--通過binder 回到APP端的onServiceConnected-->
c.conn.connected(r.name, service);
} catch (Exception e) {
到這裏,onServiceConnected纔會被回調,不過,至於Service端那兩條消息什麼時候執行,誰也不能保證,也許因爲特殊原因,那兩條消息永遠不被執行,那onServiceConnected也就不會被回調,但是這不會影響AMS與APP端處理其他問題,因爲這些消息是否被執行已經不能阻塞他們兩個了,簡單流程如下:
最後,其實startService也是異步。
文末
有些東西你不僅要懂,而且要能夠很好地表達出來,能夠讓面試官認可你的理解,例如Handler機制,這個是面試必問之題。有些晦澀的點,或許它只活在面試當中,實際工作當中你壓根不會用到它,但是你要知道它是什麼東西。
對於程序員來說,要學習的知識內容、技術有太多太多,要想不被環境淘汰就只有不斷提升自己,從來都是我們去適應環境,而不是環境來適應我們!
這裏附上上述的技術體系圖相關的幾十套騰訊、頭條、阿里、美團等公司19年的面試題,把技術點整理成了視頻和PDF(實際上比預期多花了不少精力),包含知識脈絡 + 諸多細節,由於篇幅有限,這裏以圖片的形式給大家展示一部分。
相信它會給大家帶來很多收穫:
上述【高清技術腦圖】以及【配套的架構技術PDF】可以 加我wx:X1524478394 免費獲取
當程序員容易,當一個優秀的程序員是需要不斷學習的,從初級程序員到高級程序員,從初級架構師到資深架構師,或者走向管理,從技術經理到技術總監,每個階段都需要掌握不同的能力。早早確定自己的職業方向,才能在工作和能力提升中甩開同齡人。
- 無論你現在水平怎麼樣一定要 持續學習 沒有及湯,別人看起來的毫不費力,其實費了很大力,這四個字就是我的建議!!!!!!!!!
- 我希望每一個努力生活的IT工程師,都會得到自己想要的,因爲我們很辛苦,我們應得的。