剛開始學習Service的時候以為它是一個線程的封裝,也可以執行耗時操作。其實不然,Service是運作在主線程的。直接執行耗時操作是會阻塞主線程的。長時間就直接ANR了。
我們知道Service可以執行一些背景任務,是背景任務不是耗時的任務,背景和耗時是有差別的喔。
這樣就很容易想到音樂播放器,天氣預報這些應用是要用到Service的。當然如果要在Service中執行耗時操作的話,開個線程就可以了。
關于Service的運作狀态有兩種,啟動狀态和綁定狀态,兩種狀态可以一起。
啟動一個Service隻需調用Context的startService方法,傳進一個Intent即可。看起來好像很簡單的說,那是因為Android為了友善開發者,做了很大程度的封裝。那麼你真的有去學習過Service是怎麼啟動的嗎?Service的onCreate方法回調前都做了哪些準備工作?
先上一張圖大緻了解下,灰色背景框起來的是同一個類中的方法,如下圖:
那接下來就從源碼的角度來分析Service的啟動過程。
當然是從Context的startService方法開始,Context的實作類是ContextImpl,那麼我們就看到ContextImpl的startService方法即可,如下:
@Override
public ComponentName startService(Intent service) {
warnIfCallingFromSystemProcess();
return startServiceCommon(service, mUser);
}
會轉到startServiceCommon方法,那跟進startServiceCommon方法方法瞧瞧。
private ComponentName startServiceCommon(Intent service, UserHandle user) {
try {
validateServiceIntent(service);
service.prepareToLeaveProcess();
ComponentName cn = ActivityManagerNative.getDefault().startService(
mMainThread.getApplicationThread(), service, service.resolveTypeIfNeeded(
getContentResolver()), getOpPackageName(), user.getIdentifier());
//代碼省略
return cn;
} catch (RemoteException e) {
throw new RuntimeException("Failure from system", e);
}
}
可以看到調用了ActivityManagerNative.getDefault()的startService方法來啟動Service,ActivityManagerNative.getDefault()是ActivityManagerService,簡稱AMS。
那麼現在啟動Service的過程就轉移到了ActivityManagerService,我們關注ActivityManagerService的startService方法即可,如下:
@Override
public ComponentName startService(IApplicationThread caller, Intent service,
String resolvedType, String callingPackage, int userId)
throws TransactionTooLargeException {
//代碼省略
synchronized(this) {
final int callingPid = Binder.getCallingPid();
final int callingUid = Binder.getCallingUid();
final long origId = Binder.clearCallingIdentity();
ComponentName res = mServices.startServiceLocked(caller, service,
resolvedType, callingPid, callingUid, callingPackage, userId);
Binder.restoreCallingIdentity(origId);
return res;
}
}
在上述的代碼中,調用了ActiveServices的startServiceLocked方法,那麼現在Service的啟動過程從AMS轉移到了ActiveServices了。
繼續跟進ActiveServices的startServiceLocked方法,如下:
ComponentName startServiceLocked(IApplicationThread caller, Intent service, String resolvedType,
int callingPid, int callingUid, String callingPackage, int userId)
throws TransactionTooLargeException {
//代碼省略
ServiceLookupResult res =
retrieveServiceLocked(service, resolvedType, callingPackage,
callingPid, callingUid, userId, true, callerFg);
//代碼省略
ServiceRecord r = res.record;
//代碼省略
return startServiceInnerLocked(smap, service, r, callerFg, addToStarting);
}
在startServiceLocked方法中又會調用startServiceInnerLocked方法,
我們瞧瞧startServiceInnerLocked方法,
ComponentName startServiceInnerLocked(ServiceMap smap, Intent service, ServiceRecord r,
boolean callerFg, boolean addToStarting) throws TransactionTooLargeException {
ProcessStats.ServiceState stracker = r.getTracker();
if (stracker != null) {
stracker.setStarted(true, mAm.mProcessStats.getMemFactorLocked(), r.lastActivity);
}
r.callStart = false;
synchronized (r.stats.getBatteryStats()) {
r.stats.startRunningLocked();
}
String error = bringUpServiceLocked(r, service.getFlags(), callerFg, false);
//代碼省略
return r.name;
}
startServiceInnerLocked方法内部調用了bringUpServiceLocked方法,此時啟動過程已經快要離開ActiveServices了。繼續看到bringUpServiceLocked方法。如下:
private final String bringUpServiceLocked(ServiceRecord r, int intentFlags, boolean execInFg,
boolean whileRestarting) throws TransactionTooLargeException {
//代碼省略
if (app != null && app.thread != null) {
try {
app.addPackage(r.appInfo.packageName, r.appInfo.versionCode, mAm.mProcessStats);
realStartServiceLocked(r, app, execInFg);
return null;
}
//代碼省略
return null;
}
省略了大部分if判斷,相信眼尖的你一定發現了核心的方法,那就是
realStartServiceLocked,沒錯,看名字就像是真正啟動Service。那麼事不宜遲跟進去探探吧。如下:
private final void realStartServiceLocked(ServiceRecord r,
ProcessRecord app, boolean execInFg) throws RemoteException {
//代碼省略
boolean created = false;
try {
//代碼省略
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;
}
//代碼省略
sendServiceArgsLocked(r, execInFg, true);
//代碼省略
}
找到了。app.thread調用了scheduleCreateService來啟動Service,而app.thread是一個ApplicationThread,也是ActivityThread的内部類。此時已經到了主線程。
那麼我們探探ApplicationThread的scheduleCreateService方法。如下:
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);
}
對待啟動的Service元件資訊進行包裝,然後發送了一個消息。我們關注這個CREATE_SERVICE消息即可。
public void handleMessage(Message msg) {
//代碼省略
case CREATE_SERVICE:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "serviceCreate");
handleCreateService((CreateServiceData)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
break;
//代碼省略
}
在handleMessage方法中接收到這個消息,然後調用了handleCreateService方法,跟進handleCreateService探探究竟:
private void handleCreateService(CreateServiceData data) {
// If we are getting ready to gc after going to the background, well
// we are back active so skip it.
unscheduleGcIdler();
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();
} catch (Exception e) {
if (!mInstrumentation.onException(service, e)) {
throw new RuntimeException(
"Unable to instantiate service " + data.info.name
+ ": " + e.toString(), 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);
service.attach(context, this, data.info.name, data.token, app,
ActivityManagerNative.getDefault());
service.onCreate();
mServices.put(data.token, service);
try {
ActivityManagerNative.getDefault().serviceDoneExecuting(
data.token, SERVICE_DONE_EXECUTING_ANON, , );
} catch (RemoteException e) {
// nothing to do.
}
} catch (Exception e) {
if (!mInstrumentation.onException(service, e)) {
throw new RuntimeException(
"Unable to create service " + data.info.name
+ ": " + e.toString(), e);
}
}
}
終于擊破,這個方法很核心的。一點點分析
首先擷取到一個LoadedApk對象,在通過這個LoadedApk對象擷取到一個類加載器,通過這個類加載器來建立Service。如下:
java.lang.ClassLoader cl = packageInfo.getClassLoader();
service = (Service) cl.loadClass(data.info.name).newInstance();
接着調用ContextImpl的createAppContext方法建立了一個ContextImpl對象。
之後再調用LoadedApk的makeApplication方法來建立Application,這個建立過程如下:
public Application makeApplication(boolean forceDefaultAppClass,
Instrumentation instrumentation) {
if (mApplication != null) {
return mApplication;
}
Application app = null;
String appClass = mApplicationInfo.className;
if (forceDefaultAppClass || (appClass == null)) {
appClass = "android.app.Application";
}
try {
java.lang.ClassLoader cl = getClassLoader();
if (!mPackageName.equals("android")) {
initializeJavaContextClassLoader();
}
ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);
app = mActivityThread.mInstrumentation.newApplication(
cl, appClass, appContext);
appContext.setOuterContext(app);
} catch (Exception e) {
if (!mActivityThread.mInstrumentation.onException(app, e)) {
throw new RuntimeException(
"Unable to instantiate application " + appClass
+ ": " + e.toString(), e);
}
}
mActivityThread.mAllApplications.add(app);
mApplication = app;
if (instrumentation != null) {
try {
instrumentation.callApplicationOnCreate(app);
} catch (Exception e) {
if (!instrumentation.onException(app, e)) {
throw new RuntimeException(
"Unable to create application " + app.getClass().getName()
+ ": " + e.toString(), e);
}
}
}
// Rewrite the R 'constants' for all library apks.
SparseArray<String> packageIdentifiers = getAssets(mActivityThread)
.getAssignedPackageIdentifiers();
final int N = packageIdentifiers.size();
for (int i = ; i < N; i++) {
final int id = packageIdentifiers.keyAt(i);
if (id == || id == ) {
continue;
}
rewriteRValues(getClassLoader(), packageIdentifiers.valueAt(i), id);
}
return app;
}
當然Application是隻有一個的,從上述代碼中也可以看出。
在回來繼續看handleCreateService方法,之後service調用了attach方法關聯了ContextImpl和Application等
最後service回調了onCreate方法,
service.onCreate();
mServices.put(data.token, service);
并将這個service添加進了一個了清單進行管理。
至此service啟動了起來,以上就是service的啟動過程。
你可能還想要知道onStartCommand方法是怎麼被回調的?可能細心的你發現了在ActiveServices的realStartServiceLocked方法中,那裡還有一個sendServiceArgsLocked方法。是的,那個就是入口。
那麼我們跟進sendServiceArgsLocked方法看看onStartCommand方法是怎麼回調的。
private final void sendServiceArgsLocked(ServiceRecord r, boolean execInFg,
boolean oomAdjusted) throws TransactionTooLargeException {
final int N = r.pendingStarts.size();
//代碼省略
try {
//代碼省略
r.app.thread.scheduleServiceArgs(r, si.taskRemoved, si.id, flags, si.intent);
} catch (TransactionTooLargeException e) {
if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "Transaction too large: intent="
+ si.intent);
caughtException = e;
} catch (RemoteException e) {
// Remote process gone... we'll let the normal cleanup take care of this.
if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "Crashed while sending args: " + r);
caughtException = e;
}
//代碼省略
}
可以看到onStartCommand方法回調過程和onCreate方法的是很相似的,都會轉到app.thread。那麼現在就跟進ApplicationThread的scheduleServiceArgs。
你也可能猜到了應該又是封裝一些Service的資訊,然後發送一個消息, handleMessage接收。是的,源碼如下:
public final void scheduleServiceArgs(IBinder token, boolean taskRemoved, int startId,
int flags ,Intent args) {
ServiceArgsData s = new ServiceArgsData();
s.token = token;
s.taskRemoved = taskRemoved;
s.startId = startId;
s.flags = flags;
s.args = args;
sendMessage(H.SERVICE_ARGS, s);
}
public void handleMessage(Message msg) {
//代碼省略
case SERVICE_ARGS:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "serviceStart");
handleServiceArgs((ServiceArgsData)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
break;
//代碼省略
}
咦,真的是這樣。謎底應該就在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 {
ActivityManagerNative.getDefault().serviceDoneExecuting(
data.token, SERVICE_DONE_EXECUTING_START, data.startId, res);
} catch (RemoteException e) {
// nothing to do.
}
ensureJitEnabled();
} catch (Exception e) {
if (!mInstrumentation.onException(s, e)) {
throw new RuntimeException(
"Unable to start service " + s
+ " with " + data.args + ": " + e.toString(), e);
}
}
}
}
可以看到回調了onStartCommand方法。
以上就是Service的啟動過程的源碼分析。
從中,我了解了Service的啟動過程的同時,閱讀源碼的能力也提高了,分析源碼的時候我沒能力把每一個變量,每一個方法都搞懂,我關注的都是一些關鍵的字眼,比如這篇文章就是start呀,service呀。會有那種感覺,就是這裡沒錯了。當然如果陷入胡同了也要兜出來。
這樣的分析也能夠摸清整體的過程,對于細節,等我有紮實的功底了在去研究吧。