bindService.png
一，首先从客户端使用binder通信跨进程调用到ActivityManagerService中的bindService方法
首先会调用ActiveServices的bindServiceLocked()方法
synchronized(this) {
return mServices.bindServiceLocked(caller, token, service,
resolvedType, connection, flags, callingPackage, userId);
}
在bindServiceLocked()方法中，调用retrieveServiceLocked方法取出一个ServiceLookUpResult对象
ServiceLookupResult res =
retrieveServiceLocked(service, resolvedType, callingPackage,
Binder.getCallingPid(), Binder.getCallingUid(), userId, true, callerFg);
如果intent中含有BIND_AUTO_CREATE标志位,就自动创建service,调用bringUpService.
if ((flags&Context.BIND_AUTO_CREATE) != 0) {
s.lastActivity = SystemClock.uptimeMillis();
if (bringUpServiceLocked(s, service.getFlags(), callerFg, false) != null) {
return 0;
}
}
在bringUpServiceLocked()函数中：
1>
首先会调用
sendServiceArgsLocked函数
在这里出现一个StartItem的数据结构，这个类记录了一次service的启动过程的相关参数
final ArrayList<StartItem> pendingStarts = new ArrayList<StartItem>();
// start() arguments that haven't yet been delivered.
接着调用
bumpServiceExecutingLocked(r, execInFg, "start");
在这个函数中主要对处于executing状态的service进行判断，看是否已经超时，前台service是20秒，后台servie是200s
之后会执行scheduleServiceArgs()函数,在该函数中跳转到handleServiceArgs函数中
handleServiceArgs((ServiceArgsData)msg.obj);
在handleServiceArgs中主要执行了onStartCommand和onTaskRemoved两个回调函数
res = s.onStartCommand(data.args, data.flags, data.startId);
s.onTaskRemoved(data.args);
通过binder通信回到AMS中执行serviceDoneExecuting()函数
2>
再回到bringUpServieLocked()函数中,判断该service是否处于正在准备restart的状态，或者service处在restart队列就强制把它移除该队列.再判断service是否处于延迟开始状态,
if (!whileRestarting && r.restartDelay > 0) {
// If waiting for a restart, then do nothing.
return null;
}
if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "Bringing up " + r + " " + r.intent);
// We are now bringing the service up, so no longer in the
// restarting state.
if (mRestartingServices.remove(r)) {
r.resetRestartCounter();
clearRestartingIfNeededLocked(r);
}
// Make sure this service is no longer considered delayed, we are starting it now.
if (r.delayed) {
if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE, "REM FR DELAY LIST (bring up): " + r);
getServiceMap(r.userId).mDelayedStartList.remove(r);
r.delayed = false;
}
// Make sure that the user who owns this service is started. If not,
// we don't want to allow it to run.
if (mAm.mStartedUsers.get(r.userId) == null) {
String msg = "Unable to launch app "
+ r.appInfo.packageName + "/"
+ r.appInfo.uid + " for service "
+ r.intent.getIntent() + ": user " + r.userId + " is stopped";
Slog.w(TAG, msg);
bringDownServiceLocked(r);
return msg;
}
3>之后判断该service是否要运行在一个单独的进程中,如果运行在当前进程并且进程已经启动，就直接调用realStartServiceLocked()方法:
realStartServiceLocked(r, app, execInFg);
如果要运行在单独的进程中,会调用startProcessLocked()方法开启一个新的进程.
观察startProcessLocked()方法:
如果service会运行在当前进程中，就会调用getProcessLocked()方法得到一个ProcessRecord对象。
下面代码中有一段逻辑,如果启动service的intent由后台发出，那么一旦判断目前的进程时bad进程就会直接返回一个null值.
badProcess是指在一段时间内发生两次以上crash的进程,AMS中有一个队列来存储这些bad进程,而一旦该进程被restart了，那么它就会从bad队列中去除掉.
if (!isolated) {
app = getProcessRecordLocked(processName, info.uid, keepIfLarge);
checkTime(startTime, "startProcess: after getProcessRecord");
if ((intentFlags & Intent.FLAG_FROM_BACKGROUND) != 0) {
// If we are in the background, then check to see if this process
// is bad. If so, we will just silently fail.
if (mBadProcesses.get(info.processName, info.uid) != null) {
if (DEBUG_PROCESSES) Slog.v(TAG, "Bad process: " + info.uid
+ "/" + info.processName);
return null;
}
} else {
// When the user is explicitly starting a process, then clear its
// crash count so that we won't make it bad until they see at
// least one crash dialog again, and make the process good again
// if it had been bad.
if (DEBUG_PROCESSES) Slog.v(TAG, "Clearing bad process: " + info.uid
+ "/" + info.processName);
mProcessCrashTimes.remove(info.processName, info.uid);
if (mBadProcesses.get(info.processName, info.uid) != null) {
EventLog.writeEvent(EventLogTags.AM_PROC_GOOD,
UserHandle.getUserId(info.uid), info.uid,
info.processName);
mBadProcesses.remove(info.processName, info.uid);
if (app != null) {
app.bad = false;
}
}
}
} else {
// If this is an isolated process, it can't re-use an existing process.
app = null;
}
最终进入到startProcessLocked()方法调用Process.start()方法开启一个新的进程.
checkTime(startTime, "startProcess: asking zygote to start proc");
Process.ProcessStartResult startResult = Process.start(entryPoint,
app.processName, uid, uid, gids, debugFlags, mountExternal,
app.info.targetSdkVersion, app.info.seinfo, requiredAbi, instructionSet,
app.info.dataDir, entryPointArgs);
/ We don't have to do anything more if:
// (1) There is an existing application record; and
// (2) The caller doesn't think it is dead, OR there is no thread
// object attached to it so we know it couldn't have crashed; and
// (3) There is a pid assigned to it, so it is either starting or
// already running.
创建新新进程后，会把service加入到等待启动的队列中
if (!mPendingServices.contains(r)) {
mPendingServices.add(r);
}
当新进程启动后，会调用attachApplicationLocked方法调用ActiveService中的realStartService()方法启动该service,在方法内部继续调用ActivityThread的realstartService()方法,在该方法中主要调用了scheduleCreatService和scheduleBindService方法,在scheduleCreateService中调用了service的onCreate()回调.在scheduleBindService中调用了onBind()回调
app.thread.scheduleCreateService(r, r.serviceInfo,
mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),
app.repProcState);
接着会调用scheduleBindService()方法
当service启动后，再次跨进程通信到service所在进程,调用bindService传入的ServiceConnection对象中的回调方法onConnected(),c.conn.connected()最终会调用到LoadedApk中的InnerConnection中的connected()方法,最终会调用到bindService传入的对象 serviceConnection中的onConnnected()回调.
if (s.app != null && b.intent.received) {
// Service is already running, so we can immediately
// publish the connection.
try {
c.conn.connected(s.name, b.intent.binder);
} catch (Exception e) {
Slog.w(TAG, "Failure sending service " + s.shortName
+ " to connection " + c.conn.asBinder()
+ " (in " + c.binding.client.processName + ")", e);
}
