编程语言
首页 > 编程语言> > Service的startService和bindService源码流程,android开发书籍

Service的startService和bindService源码流程,android开发书籍

作者:互联网

// 6

if ((app=mAm.startProcessLocked(procName, r.appInfo, true, intentFlags,

hostingType, r.name, false, isolated, false)) == null) {

String msg = "Unable to launch app "

Slog.w(TAG, msg);

bringDownServiceLocked®;

return msg;

}

}

return null;

}

注释1:从ServiceRecord中获取 processName赋值给 procName

注释2:根据 procName和Service的uid来传入到 AMS的 getProcessRecordLocked()中,查询是否存在一个与Service对应的ProcessRecord类型对象。

如果不存在,则在注释5、6中调用 AMS的 startProcessLocked()来创建一个引用程序进程。

如果存在,则在注释3、4中调用 realStartServiceLocked()来启动一个Service。

private final void realStartServiceLocked(ServiceRecord r,

ProcessRecord app, boolean execInFg) throws RemoteException {

try {

//1

app.thread.scheduleCreateService(r, r.serviceInfo,

mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),

app.repProcState);

r.postNotification();

created = true;

} catch (DeadObjectException e) {

Slog.w(TAG, "Application dead when creating service " + r);

mAm.appDiedLocked(app);

throw e;

} finally {

}

}

这里也有一个Real方法。app.thread.scheduleCreateService即调用调用主线程的 scheduleCreateService()的方法。

我们知道 app.thread就是 IApplicationThread,通过AIDL,这时候的代码从 SystemServer进程到了 应用程序的进程中。

// ActivityThread.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);

}

这里创建了一个 CreateServiceData类,把Service的信息都封装了进去,设置一个 H.CREATE_SERVICE字段,sendMessage出去。

到了 ApplicationThread这里,免不了要使用Handler来将线程切换到主线程去。我们直接来看看 H是怎么处理这个信息的吧

// ActivityThread.java

public void handleMessage(Message msg) {

switch (msg.what) {

case CREATE_SERVICE:

Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, ("serviceCreate: " + String.valueOf(msg.obj)));

//1

handleCreateService((CreateServiceData)msg.obj);

Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);

break;

}

}

到了主线程中,调用 handleCreateService():

private void handleCreateService(CreateServiceData data) {

// 获取要启动S
ervice的应用程序的 LoadedApk

LoadedApk packageInfo = getPackageInfoNoCheck(

data.info.applicationInfo, data.compatInfo);

Service service = null;

try {

java.lang.ClassLoader cl = packageInfo.getClassLoader();

//1

service = (Service) cl.loadClass(data.info.name).newInstance();

} catch (Exception e) {

}

try {

if (localLOGV) Slog.v(TAG, "Creating service " + data.info.name);

//创建上下文环境

ContextImpl context = ContextImpl.createAppContext(this, packageInfo);

context.setOuterContext(service);

Application app = packageInfo.makeApplication(false, mInstrumentation);

//2

service.attach(context, this, data.info.name, data.token, app,

ActivityManager.getService());

//3

service.onCreate();

//4

mServices.put(data.token, service);

} catch (Exception e) {

}

}

这里的代码和创建Activity时的非常相似。

注释1:通过LoadedApk的getClassLoader()来获取一个类加载器。然后根据 CreateServiceData 来创建一个 Service实例。

注释2:通过 service.attach()来初始化一个service

注释3:调用这个 service的 onCreate()方法。这里 service就启动了。

注释4:最后,把这个service放到 ActivityThread的成员变量 mServices中,它是一个 ArrayMap

至此,一个Service的完整的创建启动流程就over了。

下面来讲解绑定一个Service。

2.Service的绑定流程

===============================================================================

因为Service的开启方法有 startService() , 也有 bindService()

Service的绑定过程分成3个部分

  1. ContextImpl到AMS的调用过程

  2. AMS调用 bindService() 到 publishService() 过程

  3. AMS到 ServiceConnection的过程

2.1 ContextImpl到AMS的调用过程


我们先来看一下时序图:

在这里插入图片描述

在代码中调用 context.bindService(),就是调用 mBase.bindService()

从之前我们学过, mBase就是 ContextImpl。我们来看看它的 bindService()

// ContextImpl.java

@Override

public boolean bindService(Intent service, ServiceConnection conn,

int flags) {

warnIfCallingFromSystemProcess();

return bindServiceCommon(service, conn, flags, mMainThread.getHandler(),

Process.myUserHandle());

}

这个方法传入了 IntentServiceConntection(Service连接的回调),和 flags,然后这个方法里面带上了 主线程的Handler,传入到 bindServiceCommom里面去:

// 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) {

//1

sd = mPackageInfo.getServiceDispatcher(conn, getOuterContext(), handler, flags);

} else {

throw new RuntimeException(“Not supported in system context”);

}

validateServiceIntent(service);

try {

// 2

int res = ActivityManager.getService().bindService(

mMainThread.getApplicationThread(), getActivityToken(), service,

service.resolveTypeIfNeeded(getContentResolver()),

sd, flags, getOpPackageName(), user.getIdentifier());

if (res < 0) {

throw new SecurityException(

"Not allowed to bind to service " + service);

}

return res != 0;

} catch (RemoteException e) {

throw e.rethrowFromSystemServer();

}

}

在注释1中,通过 LoadedApk.getServiceDispatcher()将传进来的 ServiceConnection封装成一个 IServiceConnection对象。

也就是说 ServiceConnection也是实现了Binder的。

注释2中:调用 ActivityManager.getSerive()IActivityManager.bindSerive(),这里代码进入到 AMS层。

2.2 AMS调用 bindService() 到 publishService() 过程


先来看看时序图:

在这里插入图片描述

我们来看看 AMS的 bindService()

// ActivityManagerService

public int bindService(IApplicationThread caller, IBinder token, Intent service,

String resolvedType, IServiceConnection connection, int flags, String callingPackage,

int userId) throws TransactionTooLargeException {

synchronized(this) {

return mServices.bindServiceLocked(caller, token, service,

resolvedType, connection, flags, callingPackage, userId);

}

}

省略号中的代码都是异常判断处理。

synchronized中调用了 ActiveService.bindServiceLocked()

// ActivityManagerService.java

int bindServiceLocked(IApplicationThread caller, IBinder token, Intent service,

String resolvedType, final IServiceConnection connection, int flags,

String callingPackage, final int userId) throws TransactionTooLargeException {

try {

//1

AppBindRecord b = s.retrieveAppBindingLocked(service, callerApp);

if ((flags&Context.BIND_AUTO_CREATE) != 0) {

s.lastActivity = SystemClock.uptimeMillis();

//2

if (bringUpServiceLocked(s, service.getFlags(), callerFg, false,

permissionsReviewRequired) != null) {

return 0;

}

}

//3

if (s.app != null && b.intent.received) {

try {

//4

c.conn.connected(s.name, b.intent.binder, false);

} …

if (b.intent.apps.size() == 1 && b.intent.doRebind) {

//5

requestServiceBindingLocked(s, b.intent, callerFg, true);

}

} else if (!b.intent.requested) {

//6

requestServiceBindingLocked(s, b.intent, callerFg, false);

}

}

这个方法里面出现了几个 Record,我们来看一下他们分别描述什么:

用来描述一个 Service

描述一个进程

描述应用程序进程和 Service建立的一次通信

应用程序进程通过Intent绑定Service时,会通过AppBindRecord来维护Service与应用程序进程之间的关联。

其内部会创建并存储了 谁绑定的Service(ProcessRecord)、被绑定的Service(AppBindRecord)、绑定Service的 Intent(IntentBindRecord)和所有绑定通信记录的信息(ArraySet<ConnectionRecord>

用于描述绑定Service的Intent

注:不同的应用进程也可能会创建相同的Intent来绑定同一个Serivce。比如说一些公共的、常用的Service。

注释1:调用了 ServiceRecord.retrieveAppBindingLocked(),获取一个service的 AppBindRecord对象。我们在前面关于AppBindRecord的介绍可以看到,它内部会创建 IntentBindRecord并赋值。

注释2:如果传进来的flags == BIND_AUTO_CREATE就会调用了 bringUpServiceLocked(),其内部会调用 realStartServiceLocked(),这个方法我们学习Service的启动流程的时候学到过,其为与服务端的最后一个方法,它会通过Binder最终到 ActivityThread去,然后调用 Service.onCreate()。这也就是说在Service的绑定流程中也会去启动Serivce。

注释3: s.app != nul表示Service已经运行。其中s是ServiceRecord, app是ProcessRecord。 b.intent.received表示当前应用进程已经接收到绑定Service时返回的Binder,这样应用程序就可以通过Binder来获取要绑定的Service的访问接口。

注释4:调用c.conn的 connected,其中 c.conn就是我们一开始封装好的 IServiceConenction,它的具体实现类为 ServiceDispatcher.InnerConnection,其中ServiceDispatcher是 LoadedApk的内部类,InnerConnection的 connected方法会调用H的post()向主线程发送消息。

注释5:如果当前应用程序进程是第一个与Service进行绑定的,并且Service已经调用过 onUnBind(),则就会调用 requestServiceBindingLocked(...,true),最后的参数 rebind是true

注释6:如果应用程序进程的Client端没有发送过绑定Service的请求,则也会调用 requestServiceBindingLocked(...,flase)。最后的rebind是flase

我们来看下注释5的 requestServiceBindingLocked()

// ActivesServices.java

private final boolean requestServiceBindingLocked(ServiceRecord r, IntentBindRecord i,

boolean execInFg, boolean rebind) throws TransactionTooLargeException {

//1

if ((!i.requested || rebind) && i.apps.size() > 0) {

try {

bumpServiceExecutingLocked(r, execInFg, “bind”);

r.app.forceProcessStateUpTo(ActivityManager.PROCESS_STATE_SERVICE);

//2

r.app.thread.scheduleBindService(r, i.intent.getIntent(), rebind,

r.app.repProcState);

if (!rebind) {

i.requested = true;

}

i.hasBound = true;

i.doRebind = false;

} catch (TransactionTooLargeException e) {

}

}

return true;

}

注释1中的 i.requested表示 是否发送过绑定Service的请求,从bindServiceLocked可以得知已经发送过绑定了,因此 !i.requested == false。从 bindServiceLocked中我们得知 rebind为true。所以这里是可以继续走下去的。

i.apps.size() 中,i指的是 IntenBindRecord,AMS会为每个绑定的Service的Intent分配一个IntentBindRecord对象。我们来看一下IntentBindRecord的代码:

// ActiveServices.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>();

}

不同的应用程序进程可能使用同一个Intent来绑定Service,所以我们看到 apps用来存储这些进程。

之前说过 i.apps.size() > 0就是说明已经有Intent绑定了Serivice了。下面来验证 i.apps.size()>0为true。我们回到 bindServiceLocked()的注释1代码处,即 retrieveAppBindingLocked()

// ServiceRecord.java

public AppBindRecord retrieveAppBindingLocked(Intent intent,

ProcessRecord app) {

Intent.FilterComparison filter = new Intent.FilterComparison(intent);

IntentBindRecord i = bindings.get(filter);

if (i == null) {

//1

i = new IntentBindRecord(this, filter);

bindings.put(filter, i);

}

//2

AppBindRecord a = i.apps.get(app);

if (a != null) {

return a;

}

//3

a = new AppBindRecord(this, i, app);

i.apps.put(app, a);

return a;

}

注释1:创建了 IntentBindRecord

注释2:根据ProcessRecord获取了 AppBindRecord,如果其不为null就会返回。

如果为null就在注释3中,创建一个新的 AppBindRecord,并将其put到 apps中,key为 ProcessRecord。

这里代码也就表明, i.apps.size() > 0是为true的。 这样也就会调用上述 requestServiceBindingLocked(...,true)中,注释2 的代码。

r.app.thread 是 IApplicationThread,所以 它执行的 scheduleBindService()肯定就是通过调用 H类来切换线程到ActivityThread中。

因为这里很熟悉,我们直接看ActivityThread最终会执行什么代码:

// ActivityThread.java

public void handleMessage(Message msg) {

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;

}

}

private void handleBindService(BindServiceData data) {

//1

Service s = mServices.get(data.token);

if (s != null) {

try {

data.intent.setExtrasClassLoader(s.getClassLoader());

data.intent.prepareToEnterProcess();

try {

//2

if (!data.rebind) {

//3

IBinder binder = s.onBind(data.intent);

//4

ActivityManager.getService().publishService(

data.token, data.intent, binder);

} else {

//5

s.onRebind(data.intent);

ActivityManager.getService().serviceDoneExecuting(

data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);

}

ensureJitEnabled();

} …

} …

}

}

handleBindService()中,我们得知:

注释1:获取要绑定的Service

注释2:BindServiceData这个类的成员变量 rebind的值为false,就会调用注释3的 Service.onBind()方法,到这里Service就绑定成功了。

注释5:否则执行 Service.onRebind(),如果当前应用程序进程第一个与Service绑定,并且Service已经调用过 onUnBind(),则会调用Service的 onReBind()

handleBindService有两个分支,一个是绑定过的Service的情况,一个是未绑定过Service的情况。这里分析没有绑定过的情况。

也就是注释3、注释4的代码。

注释3我们已经了解了,就是调用Service.onBind(),在接下来的注释4中,调用了 ActivityManagerService.publishService(),这相当于又回到AMS中。

2.3 AMS到 ServiceConnection的过程


我们先来看一下从AMS到ServiceConnection的过程的时序图:

在这里插入图片描述

在AMS的publishService里面调用了 ActiveServices.publishServicedLocked(),我们来看看这个方法

// 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–) {

try {

//1

c.conn.connected(r.name, service, false);

} …

}

}

}

serviceDoneExecutingLocked(r, mDestroyingServices.contains®, false);

}

} …

}

这个方法传入一个ServiceRecord,然后会去遍历每个绑定这个Service的Intent,每个就是一个 ConnectionRecord,也就是c

调用 c.conn就是获取到每次遍历的 IServiceConnection,它的作用是解决当前应用程序进程和Service跨进程通信的问题。

具体实现为类ServiceDispatcher.InnerConnection,我们来看看 InnerConnection的connected()

g?,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Jpa2thdGhld29ybGQ=,size_16,color_FFFFFF,t_70)

在AMS的publishService里面调用了 ActiveServices.publishServicedLocked(),我们来看看这个方法

// 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–) {

try {

//1

c.conn.connected(r.name, service, false);

} …

}

}

}

serviceDoneExecutingLocked(r, mDestroyingServices.contains®, false);

}

} …

}

这个方法传入一个ServiceRecord,然后会去遍历每个绑定这个Service的Intent,每个就是一个 ConnectionRecord,也就是c

调用 c.conn就是获取到每次遍历的 IServiceConnection,它的作用是解决当前应用程序进程和Service跨进程通信的问题。

具体实现为类ServiceDispatcher.InnerConnection,我们来看看 InnerConnection的connected()

标签:调用,bindService,service,Service,绑定,注释,源码,Intent
来源: https://blog.csdn.net/m0_66264910/article/details/122544338