【源码解析】Service的onStartCommand返回值
站长
· 阅读数 3
一、引言
Service作为四大组件之一，在平时的开发中使用的频率仅次于Activity。但是，我们生成一个Service时，一般是不会重写它的onStartCommand方法的。 究竟这个方法的返回值有什么意义，Android系统为什么要给我们提供这样的一个方法呢？下面我们还是从源码中寻找答案。
二、源码分析
在之前【源码解析】Service的工作过程 的文章中我们分析过了Service的工作过程，知道Service的创建会走到ActiveService的realStartServiceLocked方法，我们就从该方法入手：
private final void realStartServiceLocked(ServiceRecord r,
ProcessRecord app, boolean execInFg) throws RemoteException {
...省略
boolean created = false;
try {
...省略
mAm.notifyPackageUse(r.serviceInfo.packageName,
PackageManager.NOTIFY_PACKAGE_USE_SERVICE);
app.forceProcessStateUpTo(ActivityManager.PROCESS_STATE_SERVICE);
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 {
...省略
}
if (r.whitelistManager) {
app.whitelistManager = true;
}
requestServiceBindingsLocked(r, execInFg);
updateServiceClientActivitiesLocked(app, null, true);
if (r.startRequested && r.callStart && r.pendingStarts.size() == 0) {
r.pendingStarts.add(new ServiceRecord.StartItem(r, false, r.makeNextStartId(),
null, null, 0));
}
sendServiceArgsLocked(r, execInFg, true);
...省略
}
该方法通过app.thread.scheduleCreateService（app.thread是ActivityThread对象）创建了Service，然后调用了ActiveService的sendServiceArgsLocked方法，代码如下：
private final void sendServiceArgsLocked(ServiceRecord r, boolean execInFg,
boolean oomAdjusted) throws TransactionTooLargeException {
final int N = r.pendingStarts.size();
if (N == 0) {
return;
}
ArrayList<ServiceStartArgs> args = new ArrayList<>();
...省略
ParceledListSlice<ServiceStartArgs> slice = new ParceledListSlice<>(args);
slice.setInlineCountLimit(4);
Exception caughtException = null;
try {
r.app.thread.scheduleServiceArgs(r, slice);
} catch (TransactionTooLargeException e) {
...省略
} catch (RemoteException e) {
...省略
} catch (Exception e) {
...省略
}
...省略
}
sendServiceArgsLocked方法最终调用了r.app.thread.scheduleServiceArgs方法，也就是ActivityThread的scheduleServiceArgs方法，代码如下：
public final void scheduleServiceArgs(IBinder token, ParceledListSlice args) {
List<ServiceStartArgs> list = args.getList();
for (int i = 0; i < list.size(); i++) {
ServiceStartArgs ssa = list.get(i);
ServiceArgsData s = new ServiceArgsData();
s.token = token;
s.taskRemoved = ssa.taskRemoved;
s.startId = ssa.startId;
s.flags = ssa.flags;
s.args = ssa.args;
sendMessage(H.SERVICE_ARGS, s);
}
}
scheduleServiceArgs方法通过消息发送机制，发送一个标志位为H.SERVICE_ARGS的消息给到ActivityThread的内部类H处理，ActivityThread内部类H对于H.SERVICE_ARGS的处理逻辑是：
case SERVICE_ARGS:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, ("serviceStart: " + String.valueOf(msg.obj)));
handleServiceArgs((ServiceArgsData)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
break;
在handleMessage中对于SERVICE_ARGS的情况，调用了handleServiceArgs方法，handleServiceArgs的代码如下：
private void handleServiceArgs(ServiceArgsData data) {
Service s = mServices.get(data.token);
if (s != null) {
try {
if (data.args != null) {
data.args.setExtrasClassLoader(s.getClassLoader());
data.args.prepareToEnterProcess();
}
int res;
if (!data.taskRemoved) {
res = s.onStartCommand(data.args, data.flags, data.startId);
} else {
s.onTaskRemoved(data.args);
res = Service.START_TASK_REMOVED_COMPLETE;
}
QueuedWork.waitToFinish();
try {
ActivityManager.getService().serviceDoneExecuting(
data.token, SERVICE_DONE_EXECUTING_START, data.startId, res);
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
ensureJitEnabled();
} catch (Exception e) {
if (!mInstrumentation.onException(s, e)) {
throw new RuntimeException(
"Unable to start service " + s
+ " with " + data.args + ": " + e.toString(), e);
}
}
}
}
在上面的方法中显式的调用了Service的onStartCommand方法，得到一个整型返回值res，而我们本文需要分析的就是这个返回值。可以看到这个返回值res最终是作为了ActivityManager.getService().serviceDoneExecuting方法的参数，而ActivityManager.getService()就是ActivityManagerService对象，其中的serviceDoneExecuting方法如下所示：
public void serviceDoneExecuting(IBinder token, int type, int startId, int res) {
synchronized(this) {
if (!(token instanceof ServiceRecord)) {
Slog.e(TAG, "serviceDoneExecuting: Invalid service token=" + token);
throw new IllegalArgumentException("Invalid service token");
}
mServices.serviceDoneExecutingLocked((ServiceRecord)token, type, startId, res);
}
}
在serviceDoneExecuting方法中又调用了ActiveServices的serviceDoneExecutingLocked方法，如下所示：
void serviceDoneExecutingLocked(ServiceRecord r, int type, int startId, int res) {
boolean inDestroying = mDestroyingServices.contains(r);
if (r != null) {
if (type == ActivityThread.SERVICE_DONE_EXECUTING_START) {
// This is a call from a service start... take care of
// book-keeping.
r.callStart = true;
switch (res) {
case Service.START_STICKY_COMPATIBILITY:
case Service.START_STICKY: {
// We are done with the associated start arguments.
r.findDeliveredStart(startId, true);
// Don't stop if killed.
r.stopIfKilled = false;
break;
}
case Service.START_NOT_STICKY: {
// We are done with the associated start arguments.
r.findDeliveredStart(startId, true);
if (r.getLastStartId() == startId) {
// There is no more work, and this service
// doesn't want to hang around if killed.
r.stopIfKilled = true;
}
break;
}
case Service.START_REDELIVER_INTENT: {
// We'll keep this item until they explicitly
// call stop for it, but keep track of the fact
// that it was delivered.
ServiceRecord.StartItem si = r.findDeliveredStart(startId, false);
if (si != null) {
si.deliveryCount = 0;
si.doneExecutingCount++;
// Don't stop if killed.
r.stopIfKilled = true;
}
break;
}
case Service.START_TASK_REMOVED_COMPLETE: {
// Special processing for onTaskRemoved(). Don't
// impact normal onStartCommand() processing.
r.findDeliveredStart(startId, true);
break;
}
default:
throw new IllegalArgumentException(
"Unknown service start result: " + res);
}
if (res == Service.START_STICKY_COMPATIBILITY) {
r.callStart = false;
}
}
...省略
final long origId = Binder.clearCallingIdentity();
serviceDoneExecutingLocked(r, inDestroying, inDestroying);
Binder.restoreCallingIdentity(origId);
} else {
Slog.w(TAG, "Done executing unknown service from pid "
+ Binder.getCallingPid());
}
}
在serviceDoneExecutingLocked方法中，对于参数res的值做了不同的处理：
- START_STICKY_COMPATIBILITY 调用了ServiceRecord的findDeliveredStart方法将当前的Intent去掉，并将stopIfKilled置为false。 查看START_STICKY_COMPATIBILITY注释，说明如下：
其功能和START_STICKY一样，是START_STICKY的兼容版本，但是不保证onStartCommand方法会被调用。
- START_STICKY 调用了ServiceRecord的findDeliveredStart方法将当前的Intent去掉，并将stopIfKilled置为false。 查看START_STICKY注释，说明如下：
在Service启动后，如果该Service被系统杀死了，系统会重新创建该Service，onStartCommand方法会被调用，但是传给Service的intent为null。这种模式适合在用Service播放在后台播放音乐的场景。
- START_NOT_STICKY 调用了ServiceRecord的findDeliveredStart方法将当前的Intent去掉，并将stopIfKilled置为true。 查看START_NOT_STICKY注释，说明如下：
在Service启动后，如果该Service被系统杀死了，系统不会重新创建该Service。除非开发者明确地使用startService的方式启动该Service。这种模式适用在使用Service存储一些数据的操作，在系统杀死Service时，操作停止也可以接受的场景。
- START_REDELIVER_INTENT 调用了ServiceRecord的findDeliveredStart方法，但不去掉当前Intent，并将stopIfKilled置为true。 查看START_REDELIVER_INTENT注释，说明如下：
在Service启动后，如果该Service被系统杀死了，系统会重新创建该Service，onStartCommand方法会调用，并且将上次的Intent通过onStartCommand方法传递进来。除非开发者明确使用stopSelf方法停止该Service，否则其不会停止。
在对参数res的值做了不同的处理后，调用了serviceDoneExecutingLocked方法，全局搜索了一下ServiceRecord的stopIfKilled值的引用，只有ActiveService的killServicesLocked方法对其进行了引用，代码如下：
final void killServicesLocked(ProcessRecord app, boolean allowRestart) {
...省略
for (int i=app.services.size()-1; i>=0; i--) {
ServiceRecord sr = app.services.valueAt(i);
// Unless the process is persistent, this process record is going away,
// so make sure the service is cleaned out of it.
if (!app.persistent) {
app.services.removeAt(i);
}
// Sanity check: if the service listed for the app is not one
// we actually are maintaining, just let it drop.
final ServiceRecord curRec = smap.mServicesByName.get(sr.name);
if (curRec != sr) {
if (curRec != null) {
Slog.wtf(TAG, "Service " + sr + " in process " + app
+ " not same as in map: " + curRec);
}
continue;
}
// Any services running in the application may need to be placed
// back in the pending list.
if (allowRestart && sr.crashCount >= mAm.mConstants.BOUND_SERVICE_MAX_CRASH_RETRY
&& (sr.serviceInfo.applicationInfo.flags
&ApplicationInfo.FLAG_PERSISTENT) == 0) {
Slog.w(TAG, "Service crashed " + sr.crashCount
+ " times, stopping: " + sr);
EventLog.writeEvent(EventLogTags.AM_SERVICE_CRASHED_TOO_MUCH,
sr.userId, sr.crashCount, sr.shortName, app.pid);
bringDownServiceLocked(sr);
} else if (!allowRestart
|| !mAm.mUserController.isUserRunningLocked(sr.userId, 0)) {
bringDownServiceLocked(sr);
} else {
boolean canceled = scheduleServiceRestartLocked(sr, true);
// Should the service remain running? Note that in the
// extreme case of so many attempts to deliver a command
// that it failed we also will stop it here.
if (sr.startRequested && (sr.stopIfKilled || canceled)) {
if (sr.pendingStarts.size() == 0) {
sr.startRequested = false;
if (sr.tracker != null) {
sr.tracker.setStarted(false, mAm.mProcessStats.getMemFactorLocked(),
SystemClock.uptimeMillis());
}
if (!sr.hasAutoCreateConnections()) {
// Whoops, no reason to restart!
bringDownServiceLocked(sr);
}
}
}
}
}
if (!allowRestart) {
app.services.clear();
// Make sure there are no more restarting services for this process.
for (int i=mRestartingServices.size()-1; i>=0; i--) {
ServiceRecord r = mRestartingServices.get(i);
if (r.processName.equals(app.processName) &&
r.serviceInfo.applicationInfo.uid == app.info.uid) {
mRestartingServices.remove(i);
clearRestartingIfNeededLocked(r);
}
}
for (int i=mPendingServices.size()-1; i>=0; i--) {
ServiceRecord r = mPendingServices.get(i);
if (r.processName.equals(app.processName) &&
r.serviceInfo.applicationInfo.uid == app.info.uid) {
mPendingServices.remove(i);
}
}
}
// Make sure we have no more records on the stopping list.
int i = mDestroyingServices.size();
while (i > 0) {
i--;
ServiceRecord sr = mDestroyingServices.get(i);
if (sr.app == app) {
sr.forceClearTracker();
mDestroyingServices.remove(i);
if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "killServices remove destroying " + sr);
}
}
app.executingServices.clear();
}
killServicesLocked方法对于ServiceRecord的stopIfKilled的逻辑看不懂，和Service中的注释对不上。后面有时间继续研究，如果有小伙伴知道的话，也请赐教，万分感谢！
三、总结
本文从源码的角度并结合源码注释解析了Service的onStartCommand的返回值，分析了不同的返回值对Service的重建有不同的效果。 针对该结论，写了一个小Demo进行验证。文章传送门：【Demo验证】Service的onStartCommand返回值
转载自:https://juejin.cn/post/6844903943936409613