剛開始學習Service的時候以為它是一個執行緒的封裝，也可以執行耗時操作。其實不然，Service是執行在主執行緒的。直接執行耗時操作是會阻塞主執行緒的。長時間就直接ANR了。
我們知道Service可以執行一些後臺任務，是後臺任務不是耗時的任務，後臺和耗時是有區別的喔。
這樣就很容易想到音樂播放器，天氣預報這些應用是要用到Service的。當然如果要在Service中執行耗時操作的話，開個執行緒就可以了。
關於Service的執行狀態有兩種，啟動狀態和繫結狀態，兩種狀態可以一起。
啟動一個Service只需呼叫Context的startService方法，傳進一個Intent即可。看起來好像很簡單的說，那是因為Android為了方便開發者，做了很大程度的封裝。那麼你真的有去學習過Service是怎麼啟動的嗎？Service的onCreate方法回撥前都做了哪些準備工作？
先上一張圖大致瞭解下，灰色背景框起來的是同一個類中的方法，如下圖：
那接下來就從原始碼的角度來分析Service的啟動過程。
當然是從Context的startService方法開始，Context的實現類是ContextImpl，那麼我們就看到ContextImpl的startService方法即可，如下：
|
1 2 3 4 5 |
@Override public ComponentName startService(Intent service) { warnIfCallingFromSystemProcess(); return startServiceCommon(service, mUser); } |
會轉到startServiceCommon方法，那跟進startServiceCommon方法方法瞧瞧。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
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方法即可，如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
@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方法，如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
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方法，
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
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方法。如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
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。那麼事不宜遲跟進去探探吧。如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
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方法。如下：
|
1 2 3 4 5 6 7 8 9 10 |
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訊息即可。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
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探探究竟：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
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, 0, 0); } 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。如下：
|
1 2 |
java.lang.ClassLoader cl = packageInfo.getClassLoader(); service = (Service) cl.loadClass(data.info.name).newInstance(); |
接著呼叫ContextImpl的createAppContext方法建立了一個ContextImpl物件。
之後再呼叫LoadedApk的makeApplication方法來建立Application，這個建立過程如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 |
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 = 0; i < N; i++) { final int id = packageIdentifiers.keyAt(i); if (id == 0x01 || id == 0x7f) { continue; } rewriteRValues(getClassLoader(), packageIdentifiers.valueAt(i), id); } return app; } |
當然Application是隻有一個的，從上述程式碼中也可以看出。
在回來繼續看handleCreateService方法，之後service呼叫了attach方法關聯了ContextImpl和Application等
最後service回撥了onCreate方法，
|
1 2 |
service.onCreate(); mServices.put(data.token, service); |
並將這個service新增進了一個了列表進行管理。
至此service啟動了起來，以上就是service的啟動過程。
你可能還想要知道onStartCommand方法是怎麼被回撥的？可能細心的你發現了在ActiveServices的realStartServiceLocked方法中，那裡還有一個sendServiceArgsLocked方法。是的，那個就是入口。
那麼我們跟進sendServiceArgsLocked方法看看onStartCommand方法是怎麼回撥的。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
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接收。是的，原始碼如下：
|
1 2 3 4 5 6 7 8 9 10 11 |
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); } |
|
1 2 3 4 5 6 7 8 9 10 11 12 |
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方法了，那麼趕緊瞧瞧，原始碼如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
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呀。會有那種感覺，就是這裡沒錯了。當然如果陷入衚衕了也要兜出來。
這樣的分析也能夠摸清整體的過程，對於細節，等我有紮實的功底了在去研究吧。