Android应用程序组件Service与Activity一样,既能够在新的进程中启动,也能够在应用程序进程内部启动;前面我们已经分析了在新的进程中启动Service的过程,本文将要介绍在应用程序内部绑定Service的过程,这是一种在应用程序进程内部启动Service的方法。

在前面一篇文章Android进程间通信(IPC)机制Binder简要介绍和学习计划中,我们就以前提到,在Android系统中,每个应用程序都是由一些Activity和Service组成的,一般Service运行在独立的进程中,而Activity有可能运行在同一个进程中,也有可能运行在不同的进程中;在接下来的文章中,Android系统在新进程中启动自己定义服务过程(startService)的原理分析一文介绍了在新的进程中启动Service的过程,Android应用程序启动过程源码分析一文介绍了在新的进程中启动Activity的过程,而Android应用程序内部启动Activity过程(startActivity)的源码分析一文则介绍了在应用程序进程内部启动Activity的过程;本文接过最后一棒,继续介绍在应用程序进程内部启动Service的过程,这样的过程又能够称在应用程序进程内部绑定服务(bindService)的过程,这样,读者应该就能够对Android应用程序启动Activity和Service有一个充分的认识了。

这里仍然是依照老规矩,通过详细的样例来分析Android应用程序绑定Service的过程,而所使用的样例便是前面我们在介绍Android系统广播机制的一篇文章Android系统中的广播(Broadcast)机制简要介绍和学习计划中所开发的应用程序Broadcast了。

我们先简单回顾一下这个应用程序实例绑定Service的过程。在这个应用程序的MainActivity的onCreate函数中,会调用bindService来绑定一个计数器服务CounterService,这里绑定的意思事实上就是在MainActivity内部获得CounterService的接口,所以,这个过程的第一步就是要把CounterService启动起来。当CounterService的onCreate函数被调用起来了,就说明CounterService已经启动起来了,接下来系统还要调用CounterService的onBind函数,跟CounterService要一个Binder对象,这个Binder对象是在CounterService内部自己定义的CounterBinder类的一个实例,它继承于Binder类,里面实现一个getService函数,用来返回外部的CounterService接口。系统得到这个Binder对象之后,就会调用MainActivity在bindService函数里面传过来的ServiceConnection实例的onServiceConnected函数,并把这个Binder对象以參数的形式传到onServiceConnected函数里面,于是,MainActivity就能够调用这个Binder对象的getService函数来获得CounterService的接口了。

这个过程比較复杂,但整体来说,思路还是比較清晰的,整个调用过程为MainActivity.bindService->CounterService.onCreate->CounterService.onBind->MainActivity.ServiceConnection.onServiceConnection->CounterService.CounterBinder.getService。以下,我们就先用一个序列图来整体描写叙述这个服务绑定的过程,然后就详细分析每个步骤。

点击查看大图

Step 1. ContextWrapper.bindService

这个函数定义在frameworks/base/core/java/android/content/ContextWrapper.java文件里:

public class ContextWrapper extends Context {
Context mBase;
...... @Override
public boolean bindService(Intent service, ServiceConnection conn,
int flags) {
return mBase.bindService(service, conn, flags);
} ......
}

这里的mBase是一个ContextImpl实例变量,于是就调用ContextImpl的bindService函数来进一步处理。

Step 2. ContextImpl.bindService

这个函数定义在frameworks/base/core/java/android/app/ContextImpl.java文件里:

class ContextImpl extends Context {
...... @Override
public boolean bindService(Intent service, ServiceConnection conn,
int flags) {
IServiceConnection sd;
if (mPackageInfo != null) {
sd = mPackageInfo.getServiceDispatcher(conn, getOuterContext(),
mMainThread.getHandler(), flags);
} else {
......
}
try {
int res = ActivityManagerNative.getDefault().bindService(
mMainThread.getApplicationThread(), getActivityToken(),
service, service.resolveTypeIfNeeded(getContentResolver()),
sd, flags);
......
return res != 0;
} catch (RemoteException e) {
return false;
}
} ...... }

这里的mMainThread是一个ActivityThread实例,通过它的getHandler函数能够获得一个Handler对象,有了这个Handler对象后,就能够把消息分发到ActivityThread所在的线程消息队列中去了,后面我们将会看到这个使用方法,如今我们临时不关注,仅仅要知道这里从ActivityThread处获得了一个Handler而且保存在以下要介绍的ServiceDispatcher中去就能够了。

我们先看一下ActivityThread.getHandler的实现,然后再回到这里的bindService函数来。

Step 3. ActivityThread.getHandler

这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件里:

public final class ActivityThread {
...... final H mH = new H(); ...... private final class H extends Handler {
...... public void handleMessage(Message msg) {
......
} ......
} ...... final Handler getHandler() {
return mH;
} ......
}

这里返回的Handler是在ActivityThread类内部从Handler类继承下来的一个H类实例变量。

回到Step 2中的ContextImpl.bindService函数中,获得了这个Handler对象后,就调用mPackageInfo.getServiceDispatcher函数来获得一个IServiceConnection接口,这里的mPackageInfo的类型是LoadedApk,我们来看看它的getServiceDispatcher函数的实现,然后再回到ContextImpl.bindService函数来。

Step 4. LoadedApk.getServiceDispatcher

这个函数定义在frameworks/base/core/java/android/app/LoadedApk.java文件里:

final class LoadedApk {
...... public final IServiceConnection getServiceDispatcher(ServiceConnection c,
Context context, Handler handler, int flags) {
synchronized (mServices) {
LoadedApk.ServiceDispatcher sd = null;
HashMap<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 HashMap<ServiceConnection, LoadedApk.ServiceDispatcher>();
mServices.put(context, map);
}
map.put(c, sd);
} else {
sd.validate(context, handler);
}
return sd.getIServiceConnection();
}
} ...... static final class ServiceDispatcher {
private final ServiceDispatcher.InnerConnection mIServiceConnection;
private final ServiceConnection mConnection;
private final Handler mActivityThread;
...... private static class InnerConnection extends IServiceConnection.Stub {
final WeakReference<LoadedApk.ServiceDispatcher> mDispatcher;
...... InnerConnection(LoadedApk.ServiceDispatcher sd) {
mDispatcher = new WeakReference<LoadedApk.ServiceDispatcher>(sd);
} ......
} ...... ServiceDispatcher(ServiceConnection conn,
Context context, Handler activityThread, int flags) {
mIServiceConnection = new InnerConnection(this);
mConnection = conn;
mActivityThread = activityThread;
......
} ...... IServiceConnection getIServiceConnection() {
return mIServiceConnection;
} ......
} ......
}

在getServiceDispatcher函数中,传进来的參数context是一个MainActivity实例,先以它为Key值在mServices中查看一下,是不是已经存在对应的ServiceDispatcher实例,假设有了,就不用创建了,直接取出来。在我们这个情景中,须要创建一个新的ServiceDispatcher。在创建新的ServiceDispatcher实例的过程中,将上面传下来ServiceConnection參数c和Hanlder參数保存在了ServiceDispatcher实例的内部,而且创建了一个InnerConnection对象,这是一个Binder对象,一会是要传递给ActivityManagerService的,ActivityManagerServic兴许就是要通过这个Binder对象和ServiceConnection通信的。

函数getServiceDispatcher最后就是返回了一个InnerConnection对象给ContextImpl.bindService函数。回到ContextImpl.bindService函数中,它接着就要调用ActivityManagerService的远程接口来进一步处理了。

Step 5. ActivityManagerService.bindService

这个函数定义在frameworks/base/core/java/android/app/ActivityManagerNative.java文件里:

class ActivityManagerProxy implements IActivityManager
{
...... public int bindService(IApplicationThread caller, IBinder token,
Intent service, String resolvedType, IServiceConnection connection,
int flags) 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);
mRemote.transact(BIND_SERVICE_TRANSACTION, data, reply, 0);
reply.readException();
int res = reply.readInt();
data.recycle();
reply.recycle();
return res;
} ......
}

这个函数通过Binder驱动程序就进入到ActivityManagerService的bindService函数去了。

Step 6. ActivityManagerService.bindService

这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件里:

public final class ActivityManagerService extends ActivityManagerNative
implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
...... public int bindService(IApplicationThread caller, IBinder token,
Intent service, String resolvedType,
IServiceConnection connection, int flags) {
...... synchronized(this) {
......
final ProcessRecord callerApp = getRecordForAppLocked(caller);
...... ActivityRecord activity = null;
if (token != null) {
int aindex = mMainStack.indexOfTokenLocked(token);
......
activity = (ActivityRecord)mMainStack.mHistory.get(aindex);
} ...... ServiceLookupResult res =
retrieveServiceLocked(service, resolvedType,
Binder.getCallingPid(), Binder.getCallingUid()); ...... ServiceRecord s = res.record; final long origId = Binder.clearCallingIdentity(); ...... AppBindRecord b = s.retrieveAppBindingLocked(service, callerApp);
ConnectionRecord c = new ConnectionRecord(b, activity,
connection, flags, clientLabel, clientIntent); IBinder binder = connection.asBinder();
ArrayList<ConnectionRecord> clist = s.connections.get(binder); if (clist == null) {
clist = new ArrayList<ConnectionRecord>();
s.connections.put(binder, clist);
}
clist.add(c);
b.connections.add(c);
if (activity != null) {
if (activity.connections == null) {
activity.connections = new HashSet<ConnectionRecord>();
}
activity.connections.add(c);
}
b.client.connections.add(c);
clist = mServiceConnections.get(binder);
if (clist == null) {
clist = new ArrayList<ConnectionRecord>();
mServiceConnections.put(binder, clist);
} clist.add(c); if ((flags&Context.BIND_AUTO_CREATE) != 0) {
......
if (!bringUpServiceLocked(s, service.getFlags(), false)) {
return 0;
}
} ......
} return 1;
} ......
}

函数首先依据传进来的參数token是MainActivity在ActivityManagerService里面的一个令牌,通过这个令牌就能够将这个代表MainActivity的ActivityRecord取回来了。

接着通过retrieveServiceLocked函数,得到一个ServiceRecord,这个ServiceReocrd描写叙述的是一个Service对象,这里就是CounterService了,这是依据传进来的參数service的内容获得的。回顾一下在MainActivity.onCreate函数绑定服务的语句:

Intent bindIntent = new Intent(MainActivity.this, CounterService.class);
bindService(bindIntent, serviceConnection, Context.BIND_AUTO_CREATE);

这里的參数service,就是上面的bindIntent了,它里面设置了CounterService类的信息(CounterService.class),因此,这里能够通过它来把CounterService的信息取出来,而且保存在ServiceRecord对象s中。

接下来,就是把传进来的參数connection封装成一个ConnectionRecord对象。注意,这里的參数connection是一个Binder对象,它的类型是LoadedApk.ServiceDispatcher.InnerConnection,是在Step 4中创建的,兴许ActivityManagerService就是要通过它来告诉MainActivity,CounterService已经启动起来了,因此,这里要把这个ConnectionRecord变量c保存下来,它保在在好几个地方,都是为了后面要用时方便地取回来的,这里就不细致去研究了,仅仅要知道ActivityManagerService要使用它时就能够方便地把它取出来就能够了,详细后面我们再分析。

最后,传进来的參数flags的位Context.BIND_AUTO_CREATE为1(參见上面MainActivity.onCreate函数调用bindService函数时设置的參数),因此,这里会调用bringUpServiceLocked函数进一步处理。

Step 7. ActivityManagerService.bringUpServiceLocked

这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件里:

public final class ActivityManagerService extends ActivityManagerNative
implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
...... private final boolean bringUpServiceLocked(ServiceRecord r,
int intentFlags, boolean whileRestarting) {
...... final String appName = r.processName;
ProcessRecord app = getProcessRecordLocked(appName, r.appInfo.uid); if (app != null && app.thread != null) {
try {
realStartServiceLocked(r, app);
return true;
} catch (RemoteException e) {
......
}
} // Not running -- get it started, and enqueue this service record
// to be executed when the app comes up.
if (startProcessLocked(appName, r.appInfo, true, intentFlags,
"service", r.name, false) == null) {
......
} ......
} ......
}

回顾在Android系统中的广播(Broadcast)机制简要介绍和学习计划中一文中,我们没有在程序的AndroidManifest.xml配置文件里设置CounterService的process属性值,因此,它默认就为application标签的process属性值,而application标签的process属性值也没有设置,于是,它们就默觉得应用程序的包名了,即这里的appName的值为"shy.luo.broadcast"。接下来依据appName和应用程序的uid值获得一个ProcessRecord记录,因为之前在启动MainActivity的时候,已经依据这个appName和uid值创建了一个ProcessReocrd对象(详细能够參考Android应用程序启动过程源码分析一文),因此,这里取回来的app和app.thread均不为null,于是,就运行realStartServiceLocked函数来运行下一步操作了。

假设这里得到的ProcessRecord变量app为null,又是什么情况呢?在这样的情况下,就会运行后面的startProcessLocked函数来创建一个新的进程,然后在这个新的进程中启动这个Service了,详细能够參考前面一篇文章Android系统在新进程中启动自己定义服务过程(startService)的原理分析

Step 8. ActivityManagerService.realStartServiceLocked

这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件里:

public final class ActivityManagerService extends ActivityManagerNative
implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
...... private final void realStartServiceLocked(ServiceRecord r,
ProcessRecord app) throws RemoteException {
......
r.app = app;
...... app.services.add(r);
...... try {
......
app.thread.scheduleCreateService(r, r.serviceInfo);
......
} finally {
......
} requestServiceBindingsLocked(r); ......
} ......
}

这个函数运行了两个操作,一个是操作是调用app.thread.scheduleCreateService函数来在应用程序进程内部启动CounterService,这个操作会导致CounterService的onCreate函数被调用;还有一个操作是调用requestServiceBindingsLocked函数来向CounterService要一个Binder对象,这个操作会导致CounterService的onBind函数被调用。

这里,我们先沿着app.thread.scheduleCreateService这个路径分析下去,然后再回过头来分析requestServiceBindingsLocked的调用过程。这里的app.thread是一个Binder对象的远程接口,类型为ApplicationThreadProxy。每个Android应用程序进程里面都有一个ActivtyThread对象和一个ApplicationThread对象,当中是ApplicationThread对象是ActivityThread对象的一个成员变量,是ActivityThread与ActivityManagerService之间用来运行进程间通信的,详细能够參考Android应用程序启动过程源码分析一文。

Step 9. ApplicationThreadProxy.scheduleCreateService

这个函数定义在frameworks/base/core/java/android/app/ApplicationThreadNative.java文件里:

class ApplicationThreadProxy implements IApplicationThread {
...... public final void scheduleCreateService(IBinder token, ServiceInfo info)
throws RemoteException {
Parcel data = Parcel.obtain();
data.writeInterfaceToken(IApplicationThread.descriptor);
data.writeStrongBinder(token);
info.writeToParcel(data, 0);
mRemote.transact(SCHEDULE_CREATE_SERVICE_TRANSACTION, data, null,
IBinder.FLAG_ONEWAY);
data.recycle();
} ......
}

这里通过Binder驱动程序就进入到ApplicationThread的scheduleCreateService函数去了。

Step 10. ApplicationThread.scheduleCreateService
         这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件里:

public final class ActivityThread {
...... private final class ApplicationThread extends ApplicationThreadNative {
...... public final void scheduleCreateService(IBinder token,
ServiceInfo info) {
CreateServiceData s = new CreateServiceData();
s.token = token;
s.info = info; queueOrSendMessage(H.CREATE_SERVICE, s);
} ......
} ......
}

这里它运行的操作就是调用ActivityThread的queueOrSendMessage函数把一个H.CREATE_SERVICE类型的消息放到ActivityThread的消息队列中去。

Step 11. ActivityThread.queueOrSendMessage
         这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件里:

public final class ActivityThread {
...... // if the thread hasn't started yet, we don't have the handler, so just
// save the messages until we're ready.
private final void queueOrSendMessage(int what, Object obj) {
queueOrSendMessage(what, obj, 0, 0);
} private final void queueOrSendMessage(int what, Object obj, int arg1) {
queueOrSendMessage(what, obj, arg1, 0);
} private final void queueOrSendMessage(int what, Object obj, int arg1, int arg2) {
synchronized (this) {
......
Message msg = Message.obtain();
msg.what = what;
msg.obj = obj;
msg.arg1 = arg1;
msg.arg2 = arg2;
mH.sendMessage(msg);
}
} ......
}

这个消息终于是通过mH.sendMessage发送出去的,这里的mH是一个在ActivityThread内部定义的一个类,继承于Hanlder类,用于处理消息的。

Step 12. H.sendMessage

因为H类继承于Handler类,因此,这里实际运行的Handler.sendMessage函数,这个函数定义在frameworks/base/core/java/android/os/Handler.java文件,这里我们就不看了,有兴趣的读者能够自己研究一下,调用了这个函数之后,这个消息就真正地进入到ActivityThread的消息队列去了,终于这个消息由H.handleMessage函数来处理,这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件里:

public final class ActivityThread {
...... private final class H extends Handler {
...... public void handleMessage(Message msg) {
......
switch (msg.what) {
......
case CREATE_SERVICE:
handleCreateService((CreateServiceData)msg.obj);
break;
......
}
}
} ......
}

这个消息终于由ActivityThread的handleCreateService函数来处理。

Step 13. ActivityThread.handleCreateService
        这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件里:

public final class ActivityThread {
...... private final void handleCreateService(CreateServiceData data) {
...... LoadedApk packageInfo = getPackageInfoNoCheck(
data.info.applicationInfo);
Service service = null;
try {
java.lang.ClassLoader cl = packageInfo.getClassLoader();
service = (Service) cl.loadClass(data.info.name).newInstance();
} catch (Exception e) {
......
} try {
...... ContextImpl context = new ContextImpl();
context.init(packageInfo, null, this); Application app = packageInfo.makeApplication(false, mInstrumentation);
context.setOuterContext(service);
service.attach(context, this, data.info.name, data.token, app,
ActivityManagerNative.getDefault()); service.onCreate();
mServices.put(data.token, service);
......
} catch (Exception e) {
......
}
} ......
}

这个函数的工作就是把CounterService类载入到内存中来,然后调用它的onCreate函数。

Step 14. CounterService.onCreate

这个函数定义在Android系统中的广播(Broadcast)机制简要介绍和学习计划中一文中所介绍的应用程序Broadcast的project文件夹下的src/shy/luo/broadcast/CounterService.java文件里:

public class CounterService extends Service implements ICounterService {
...... @Override
public void onCreate() {
super.onCreate(); Log.i(LOG_TAG, "Counter Service Created.");
} ......
}

这样,CounterService就启动起来了。

至此,应用程序绑定服务过程中的第一步MainActivity.bindService->CounterService.onCreate就完毕了。

这一步完毕之后,我们还要回到Step  8中去,运行下一个操作,即调用ActivityManagerService.requestServiceBindingsLocked函数,这个调用是用来运行CounterService的onBind函数的。

Step 15. ActivityManagerService.requestServiceBindingsLocked

这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件里:

public final class ActivityManagerService extends ActivityManagerNative
implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
...... private final void requestServiceBindingsLocked(ServiceRecord r) {
Iterator<IntentBindRecord> bindings = r.bindings.values().iterator();
while (bindings.hasNext()) {
IntentBindRecord i = bindings.next();
if (!requestServiceBindingLocked(r, i, false)) {
break;
}
}
} private final boolean requestServiceBindingLocked(ServiceRecord r,
IntentBindRecord i, boolean rebind) {
......
if ((!i.requested || rebind) && i.apps.size() > 0) {
try {
......
r.app.thread.scheduleBindService(r, i.intent.getIntent(), rebind);
......
} catch (RemoteException e) {
......
}
}
return true;
} ......
}

这里的參数r就是我们在前面的Step 6中创建的ServiceRecord了,它代表刚才已经启动了的CounterService。函数requestServiceBindingsLocked调用了requestServiceBindingLocked函数来处理绑定服务的操作,而函数requestServiceBindingLocked又调用了app.thread.scheduleBindService函数运行操作,前面我们已经介绍过app.thread,它是一个Binder对象的远程接口,类型是ApplicationThreadProxy。

Step 16. ApplicationThreadProxy.scheduleBindService

这个函数定义在frameworks/base/core/java/android/app/ApplicationThreadNative.java文件里:

class ApplicationThreadProxy implements IApplicationThread {
...... public final void scheduleBindService(IBinder token, Intent intent, boolean rebind)
throws RemoteException {
Parcel data = Parcel.obtain();
data.writeInterfaceToken(IApplicationThread.descriptor);
data.writeStrongBinder(token);
intent.writeToParcel(data, 0);
data.writeInt(rebind ? 1 : 0);
mRemote.transact(SCHEDULE_BIND_SERVICE_TRANSACTION, data, null,
IBinder.FLAG_ONEWAY);
data.recycle();
} ......
}

这里通过Binder驱动程序就进入到ApplicationThread的scheduleBindService函数去了。

Step 17. ApplicationThread.scheduleBindService
         这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件里:

public final class ActivityThread {
...... 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);
} ......
}

这里像上面的Step 11一样,调用ActivityThread.queueOrSendMessage函数来发送消息。
        Step 18. ActivityThread.queueOrSendMessage

參考上面的Step 11,只是这里的消息类型是H.BIND_SERVICE。

Step 19. H.sendMessage

參考上面的Step 12,只是这里终于在H.handleMessage函数中,要处理的消息类型是H.BIND_SERVICE:

public final class ActivityThread {
...... private final class H extends Handler {
...... public void handleMessage(Message msg) {
......
switch (msg.what) {
......
case BIND_SERVICE:
handleBindService((BindServiceData)msg.obj);
break;
......
}
}
} ......
}

这里调用ActivityThread.handleBindService函数来进一步处理。

Step 20. ActivityThread.handleBindService

这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件里:

public final class ActivityThread {
...... private final 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);
} else {
......
}
......
} catch (RemoteException ex) {
}
} catch (Exception e) {
......
}
}
} ......
}

在前面的Step 13运行ActivityThread.handleCreateService函数中,已经将这个CounterService实例保存在mServices中,因此,这里首先通过data.token值将它取回来,保存在本地变量s中,接着运行了两个操作,一个操作是调用s.onBind,即CounterService.onBind获得一个Binder对象,还有一个操作就是把这个Binder对象传递给ActivityManagerService。

我们先看CounterService.onBind操作,然后再回到ActivityThread.handleBindService函数中来。

Step 21. CounterService.onBind

这个函数定义在Android系统中的广播(Broadcast)机制简要介绍和学习计划中一文中所介绍的应用程序Broadcast的project文件夹下的src/shy/luo/broadcast/CounterService.java文件里:

public class CounterService extends Service implements ICounterService {
...... private final IBinder binder = new CounterBinder(); public class CounterBinder extends Binder {
public CounterService getService() {
return CounterService.this;
}
} @Override
public IBinder onBind(Intent intent) {
return binder;
} ......
}

这里的onBind函数返回一个是CounterBinder类型的Binder对象,它里面实现一个成员函数getService,用于返回CounterService接口。

至此,应用程序绑定服务过程中的第二步CounterService.onBind就完毕了。

回到ActivityThread.handleBindService函数中,获得了这个CounterBinder对象后,就调用ActivityManagerProxy.publishService来通知MainActivity,CounterService已经连接好了。
        Step 22. ActivityManagerProxy.publishService

这个函数定义在frameworks/base/core/java/android/app/ActivityManagerNative.java文件里:

class ActivityManagerProxy implements IActivityManager
{
...... public void publishService(IBinder token,
Intent intent, IBinder service) throws RemoteException {
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
data.writeInterfaceToken(IActivityManager.descriptor);
data.writeStrongBinder(token);
intent.writeToParcel(data, 0);
data.writeStrongBinder(service);
mRemote.transact(PUBLISH_SERVICE_TRANSACTION, data, reply, 0);
reply.readException();
data.recycle();
reply.recycle();
} ......
}

这里通过Binder驱动程序就进入到ActivityManagerService的publishService函数中去了。

Step 23. ActivityManagerService.publishService

这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件里:

public final class ActivityManagerService extends ActivityManagerNative
implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
...... public void publishService(IBinder token, Intent intent, IBinder service) {
......
synchronized(this) {
......
ServiceRecord r = (ServiceRecord)token;
...... ......
if (r != null) {
Intent.FilterComparison filter
= new Intent.FilterComparison(intent);
IntentBindRecord b = r.bindings.get(filter);
if (b != null && !b.received) {
b.binder = service;
b.requested = true;
b.received = true;
if (r.connections.size() > 0) {
Iterator<ArrayList<ConnectionRecord>> it
= r.connections.values().iterator();
while (it.hasNext()) {
ArrayList<ConnectionRecord> clist = it.next();
for (int i=0; i<clist.size(); i++) {
ConnectionRecord c = clist.get(i);
......
try {
c.conn.connected(r.name, service);
} catch (Exception e) {
......
}
}
}
}
} ......
}
}
} ......
}

这里传进来的參数token是一个ServiceRecord对象,它是在上面的Step 6中创建的,代表CounterService这个Service。在Step 6中,我们以前把一个ConnectionRecord放在ServiceRecord.connections列表中:

    ServiceRecord s = res.record;

    ......

    ConnectionRecord c = new ConnectionRecord(b, activity,
connection, flags, clientLabel, clientIntent); IBinder binder = connection.asBinder();
ArrayList<ConnectionRecord> clist = s.connections.get(binder); if (clist == null) {
clist = new ArrayList<ConnectionRecord>();
s.connections.put(binder, clist);
}

因此,这里能够从r.connections中将这个ConnectionRecord取出来:

    Iterator<ArrayList<ConnectionRecord>> it
= r.connections.values().iterator();
while (it.hasNext()) {
ArrayList<ConnectionRecord> clist = it.next();
for (int i=0; i<clist.size(); i++) {
ConnectionRecord c = clist.get(i);
......
try {
c.conn.connected(r.name, service);
} catch (Exception e) {
......
}
}
}

每个ConnectionRecord里面都有一个成员变量conn,它的类型是IServiceConnection,是一个Binder对象的远程接口,这个Binder对象又是什么呢?这就是我们在Step 
4中创建的LoadedApk.ServiceDispatcher.InnerConnection对象了。因此,这里运行c.conn.connected函数后就会进入到LoadedApk.ServiceDispatcher.InnerConnection.connected函数中去了。

Step 24. InnerConnection.connected

这个函数定义在frameworks/base/core/java/android/app/LoadedApk.java文件里:

final class LoadedApk {
...... static final class ServiceDispatcher {
...... private static class InnerConnection extends IServiceConnection.Stub {
...... public void connected(ComponentName name, IBinder service) throws RemoteException {
LoadedApk.ServiceDispatcher sd = mDispatcher.get();
if (sd != null) {
sd.connected(name, service);
}
}
......
} ......
} ......
}

这里它将操作转发给ServiceDispatcher.connected函数。

Step 25. ServiceDispatcher.connected

这个函数定义在frameworks/base/core/java/android/app/LoadedApk.java文件里:

final class LoadedApk {
...... static final class ServiceDispatcher {
...... public void connected(ComponentName name, IBinder service) {
if (mActivityThread != null) {
mActivityThread.post(new RunConnection(name, service, 0));
} else {
......
}
} ......
} ......
}

我们在前面Step 4中说到,这里的mActivityThread是一个Handler实例,它是通过ActivityThread.getHandler函数得到的,因此,调用它的post函数后,就会把一个消息放到ActivityThread的消息队列中去了。

Step 26. H.post

因为H类继承于Handler类,因此,这里实际运行的Handler.post函数,这个函数定义在frameworks/base/core/java/android/os/Handler.java文件,这里我们就不看了,有兴趣的读者能够自己研究一下,调用了这个函数之后,这个消息就真正地进入到ActivityThread的消息队列去了,与sendMessage把消息放在消息队列不一样的地方是,post方式发送的消息不是由这个Handler的handleMessage函数来处理的,而是由post的參数Runnable的run函数来处理的。这里传给post的參数是一个RunConnection类型的參数,它继承了Runnable类,因此,终于会调用RunConnection.run函数来处理这个消息。

Step 27. RunConnection.run

这个函数定义在frameworks/base/core/java/android/app/LoadedApk.java文件里:

final class LoadedApk {
...... static final class ServiceDispatcher {
...... private final class RunConnection implements Runnable {
...... public void run() {
if (mCommand == 0) {
doConnected(mName, mService);
} else if (mCommand == 1) {
......
}
} ......
} ......
} ......
}

这里的mCommand值为0,于是就运行ServiceDispatcher.doConnected函数来进一步操作了。

Step 28. ServiceDispatcher.doConnected
        这个函数定义在frameworks/base/core/java/android/app/LoadedApk.java文件里:

final class LoadedApk {
...... static final class ServiceDispatcher {
...... public void doConnected(ComponentName name, IBinder service) {
...... // If there is a new service, it is now connected.
if (service != null) {
mConnection.onServiceConnected(name, service);
}
} ......
} ......
}

这里主要就是运行成员变量mConnection的onServiceConnected函数,这里的mConnection变量的类型的ServiceConnection,它是在前面的Step 4中设置好的,这个ServiceConnection实例是MainActivity类内部创建的,在调用bindService函数时保存在LoadedApk.ServiceDispatcher类中,用它来换取一个IServiceConnection对象,传给ActivityManagerService。

Step 29. ServiceConnection.onServiceConnected

这个函数定义在Android系统中的广播(Broadcast)机制简要介绍和学习计划中一文中所介绍的应用程序Broadcast的project文件夹下的src/shy/luo/broadcast/MainActivity.java文件里:

public class MainActivity extends Activity implements OnClickListener {
...... private ServiceConnection serviceConnection = new ServiceConnection() {
public void onServiceConnected(ComponentName className, IBinder service) {
counterService = ((CounterService.CounterBinder)service).getService(); Log.i(LOG_TAG, "Counter Service Connected");
}
......
}; ......
}

这里传进来的參数service是一个Binder对象,就是前面在Step 21中从CounterService那里得到的ConterBinder对象,因此,这里能够把它强制转换为CounterBinder引用,然后调用它的getService函数。

至此,应用程序绑定服务过程中的第三步MainActivity.ServiceConnection.onServiceConnection就完毕了。

Step 30. CounterBinder.getService

这个函数定义在Android系统中的广播(Broadcast)机制简要介绍和学习计划中一文中所介绍的应用程序Broadcast的project文件夹下的src/shy/luo/broadcast/CounterService.java文件里:

public class CounterService extends Service implements ICounterService {
...... public class CounterBinder extends Binder {
public CounterService getService() {
return CounterService.this;
}
} ......
}

这里就把CounterService接口返回给MainActivity了。

至此,应用程序绑定服务过程中的第四步CounterService.CounterBinder.getService就完毕了。

这样,Android应用程序绑定服务(bindService)的过程的源码分析就完毕了,总结一下这个过程:

1. Step 1 -  Step 14,MainActivity调用bindService函数通知ActivityManagerService,它要启动CounterService这个服务,ActivityManagerService于是在MainActivity所在的进程内部把CounterService启动起来,而且调用它的onCreate函数;

2. Step 15 - Step 21,ActivityManagerService把CounterService启动起来后,继续调用CounterService的onBind函数,要求CounterService返回一个Binder对象给它;

3. Step 22 - Step 29,ActivityManagerService从CounterService处得到这个Binder对象后,就把它传给MainActivity,即把这个Binder对象作为參数传递给MainActivity内部定义的ServiceConnection对象的onServiceConnected函数;

4. Step 30,MainActivity内部定义的ServiceConnection对象的onServiceConnected函数在得到这个Binder对象后,就通过它的getService成同函数获得CounterService接口。

老罗的新浪微博:http://weibo.com/shengyangluo,欢迎关注!

Android应用程序绑定服务(bindService)的过程源码分析的更多相关文章

  1. Android应用程序绑定服务(bindService)的过程源代码分析

    文章转载至CSDN社区罗升阳的安卓之旅,原文地址:http://blog.csdn.net/luoshengyang/article/details/6745181 Android应用程序组件Serv ...

  2. Android应用程序消息处理机制(Looper、Handler)分析

    文章转载至CSDN社区罗升阳的安卓之旅,原文地址:http://blog.csdn.net/luoshengyang/article/details/6817933 Android应用程序是通过消息来 ...

  3. Android服务之PackageManagerService启动源码分析

    了解了Android系统的启动过程的读者应该知道,Android的所有Java服务都是通过SystemServer进程启动的,并且驻留在SystemServer进程中.SystemServer进程在启 ...

  4. Netty入门一:服务端应用搭建 & 启动过程源码分析

    最近周末也没啥事就学学Netty,同时打算写一些博客记录一下(写的过程理解更加深刻了) 本文主要从三个方法来呈现:Netty核心组件简介.Netty服务端创建.Netty启动过程源码分析 如果你对Ne ...

  5. Android系统默认Home应用程序(Launcher)的启动过程源码分析

    在前面一篇文章中,我们分析了Android系统在启动时安装应用程序的过程,这些应用程序安装好之后,还须要有一个Home应用程序来负责把它们在桌面上展示出来,在Android系统中,这个默认的Home应 ...

  6. [Android]从Launcher开始启动App流程源码分析

    以下内容为原创,欢迎转载,转载请注明 来自天天博客:http://www.cnblogs.com/tiantianbyconan/p/5017056.html 从Launcher开始启动App流程源码 ...

  7. [Android]Android系统启动流程源码分析

    以下内容为原创,欢迎转载,转载请注明 来自天天博客:http://www.cnblogs.com/tiantianbyconan/p/5013863.html Android系统启动流程源码分析 首先 ...

  8. 10.4 android输入系统_框架、编写一个万能模拟输入驱动程序、reader/dispatcher线程启动过程源码分析

    1. 输入系统框架 android输入系统官方文档 // 需FQhttp://source.android.com/devices/input/index.html <深入理解Android 卷 ...

  9. Activity启动过程源码分析(Android 8.0)

    Activity启动过程源码分析 本文来Activity的启动流程,一般我们都是通过startActivity或startActivityForResult来启动目标activity,那么我们就由此出 ...

随机推荐

  1. FZU 1686(重复覆盖)

    题目连接:http://acm.hust.edu.cn/vjudge/problem/viewProblem.action?id=31370 题意:用尽量少r*c的小矩形覆盖大矩形n*m中的所有1,将 ...

  2. linux--档案权限与目录配置

    下面是最近学习档案权限与目录配置的一些知识点总结***博客园-邦邦酱好*** Linux最优秀的地方之一,就在于他的多人多任务环境.而为了让各个使用者具有较保密的档案数据,因此档案的权限管理就变的很重 ...

  3. unity3d由于Camera.main.transform报空引用错误的解决方案

    今天在导入character包后,引用了内置的第三人称素材,但是在启动的时候程序报空引用的错误: 引起错误的位置在: 错误原因是因为没有将摄像机的tag设置为maincamera,改为maincame ...

  4. .NET 使用 MySql.Data.dll 动态库操作MySql的帮助类--MySqlHelper

    .NET 使用 MySql.Data.dll 动态库操作MySql的帮助类--MySqlHelper 參考演示样例代码,例如以下所看到的: /// <summary> /// MySql ...

  5. 測试之路3——对照XML文件2

    距离上一篇对照xml文件隔了非常久,并不代表一直做了那么久. 事实上上一次对照xml文件一直出错,事实上我忽略了一个非常easy的问题:我从根文件夹下得到的全部孩子,是这个根下的,而xml文件的组织形 ...

  6. 使IIS Express支持其他网络客户端访问

    今天尝试利用Android客户端Web浏览器访问VS2012 IIS Express调试中的Web应用,发现这个IIS Express仅支持localhost主机名地址访问. 上网搜索找到解决方案,几 ...

  7. 经典排序算法 - 高速排序Quick sort

    经典排序算法 - 高速排序Quick sort 原理,通过一趟扫描将要排序的数据切割成独立的两部分,当中一部分的全部数据都比另外一部分的全部数据都要小,然后再按此方法对这两部分数据分别进行高速排序,整 ...

  8. hadoop版本号变迁

    近期在研究hadoop时,发现hadoop的版本号非常混乱.原来的版本号都说0.X.X開始,后来发现有1.X.X和2.X.X 这样就不太清楚了. 0.20.2版本号曾经(不含该版本号)的配置文件都在d ...

  9. 深入了解回调函数Java

    打回来.我第一次看到Java编程思想,后来Observer模式也适用于一个回调函数的想法.但是,一直没有重视,在处于劣势的最终面试,越来越明白为什么那么多人说Java编程思想,这本书应该是一遍又一遍, ...

  10. C语言简单的菜单选项

    #include <stdio.h> char get_choice(void); char get_first(void); int get_int(void); void count( ...