### 四大組件的工作過程 #### 一、集思廣益 首先這里轉載一些網友的看過本章后的總結和歸納，便于大家理解。 下面這2位通過UML的格式來直觀地展示了組件的工作過程，[看云網友的總結](http://www.hmoore.net/kancloud/art-of-android-development-reading-notes/90454)，[amurocrash同學的總結](http://blog.csdn.net/amurocrash/article/details/48858353)，這位同學的總結很透徹，另外，CSDN的網友同樣寫出了自己的歸納總結[總結一](http://blog.csdn.net/qy274770068/article/details/50931853)、[總結二](http://blog.csdn.net/zizidemenghanxiao/article/details/50639025)。 #### 二、具體闡述 ##### 一、Activity的工作過程 現附上網友總結的UML圖，作為一個大致的了解  1. startActivity：startActivity方法有好幾種重載方式，但是它們最終都會調用startActivityForResult方法。 在Activity.java文件中： ~~~ @Override public void startActivity(Intent intent, Bundle options) { if (options != null) { startActivityForResult(intent, -1, options); } else { // Note we want to go through this call for compatibility with // applications that may have overridden the method. startActivityForResult(intent, -1); } } ~~~ * * * * * **只需要關注mParent == null這部分邏輯，ActivityGroup最開始被用來在一個界面中嵌入多個Activity，** **但是其在API13中已經被廢棄了，系統推薦采用Fragment來代替ActivityGroup。** * * * * * ~~~ public void startActivityForResult(Intent intent, int requestCode, Bundle options) { /* * mParent代表的是ActivityGroup， * ActivityGroup最開始被用來在一個界面中嵌入多個Activity， * 但是其在API13中已經被廢棄了，系統推薦采用Fragment來代替ActivityGroup。 * */ if (mParent == null) { /* * mMainThread.getApplicationThread()這個參數，它的類型是ApplicationThread， * ApplicationThread是ActivityThread的一個內部類， * 在后面的分析中可以發現，ApplicationThread和ActivityThread在Activity的啟動過程中發揮著很重要的作用。 * */ Instrumentation.ActivityResult ar = // 所以說Activity的啟動過程轉移到了Instrumentation中的execStartActivity方法： mInstrumentation.execStartActivity (this, mMainThread.getApplicationThread (), mToken, this, intent, requestCode, options); if (ar != null) { mMainThread.sendActivityResult ( mToken, mEmbeddedID, requestCode, ar.getResultCode (), ar.getResultData ()); } if (requestCode >= 0) { mStartedActivity = true; } final View decor = mWindow != null ? mWindow.peekDecorView () : null; if (decor != null) { decor.cancelPendingInputEvents (); } } else { if (options != null) { mParent.startActivityFromChild (this, intent, requestCode, options); } else { mParent.startActivityFromChild (this, intent, requestCode); } } } ~~~ * * * * * **ApplicationThread是ActivityThread的一個內部類，它繼承自ApplicationThreadNative，而ApplicationThreadNative繼承自Binder并實現了IApplicationThread接口，ApplicationThreadNative的作用其實就和系統為AIDL文件生成的類是一樣的。** * * * * * Instrumentation的execStartActivity方法： ~~~ public ActivityResult execStartActivity( Context who, IBinder contextThread, IBinder token, Activity target, Intent intent, int requestCode, Bundle options) { IApplicationThread whoThread = (IApplicationThread) contextThread; if (mActivityMonitors != null) { synchronized (mSync) { final int N = mActivityMonitors.size(); for (int i=0; i<N; i++) { final ActivityMonitor am = mActivityMonitors.get(i); if (am.match(who, null, intent)) { am.mHits++; if (am.isBlocking()) { return requestCode >= 0 ? am.getResult() : null; } break; } } } } try { intent.migrateExtraStreamToClipData(); intent.prepareToLeaveProcess(); /* * 所以啟動Activity的真正實現由ActivityManagerNative.getDefault().startActivity方法來完成。 * * ActivityManagerService繼承自ActivityManagerNative， * 而ActivityManagerNative繼承自Binder并實現了IActivityManager這個Binder接口， * 因此ActivityManagerService也是一個Binder，它是IActivityManager的具體實現。 * * 由于ActivityManagerNative.getDefault()其實是一個IActivityManager類型的Binder對象， * 因此它的具體實現是ActivityManagerService（AMS）。 * 所以說Activity的啟動過程又轉移到了ActivityManagerService中， * 然后再去看ActivityManagerService的startActivity方法。 * */ int result = ActivityManagerNative.getDefault() .startActivity(whoThread, who.getBasePackageName(), intent, intent.resolveTypeIfNeeded(who.getContentResolver()), token, target != null ? target.mEmbeddedID : null, requestCode, 0, null, null, options); // 檢查啟動Activity的結果： checkStartActivityResult(result, intent); } catch (RemoteException e) { } } ~~~ **checkStartActivityResult(result,intent);我們去看看這個方法的源碼：可以看出這個方法的作用就是檢查啟動Activity的結果，當無法正確地啟動一個Activity時，這個方法就會拋出異常信息，** ~~~ static void checkStartActivityResult(int res, Object intent) { if (res >= ActivityManager.START_SUCCESS) { return; } switch (res) { case ActivityManager.START_INTENT_NOT_RESOLVED: case ActivityManager.START_CLASS_NOT_FOUND: if (intent instanceof Intent && ((Intent)intent).getComponent() != null) /* * 這個異常錯誤拋出最常見了。 * 如果沒有在AndroidManifest中注冊Activity，就會拋出此異常。 * */ throw new ActivityNotFoundException( "Unable to find explicit activity class " + ((Intent)intent).getComponent().toShortString() + "; have you declared this activity in your AndroidManifest.xml?"); throw new ActivityNotFoundException( "No Activity found to handle " + intent); case ActivityManager.START_PERMISSION_DENIED: throw new SecurityException("Not allowed to start activity " + intent); case ActivityManager.START_FORWARD_AND_REQUEST_CONFLICT: throw new AndroidRuntimeException( "FORWARD_RESULT_FLAG used while also requesting a result"); case ActivityManager.START_NOT_ACTIVITY: throw new IllegalArgumentException( "PendingIntent is not an activity"); default: throw new AndroidRuntimeException("Unknown error code " + res + " when starting " + intent); } } ~~~ ActivityManagerNative.getDefault實際上就是ActivityManagerService，因此Activity的啟動過程轉移到了ActivityManagerService(AMS)中。 ~~~ /* * 在Instrumentation的execStartActivity中用ActivityManagerNative的getDefault來獲取一個IActivityManager的對象， * 而且這個IActivityManager的對象其實是一個Binder對象，它的具體實現是ActivityManagerService。 * */ static public IActivityManager getDefault() { return gDefault.get(); } /* * 在ActivityManagernative中，ActivityManagerService這個Binder對象采用單例模式對外提供， * Singleton是一個單例的封裝類， * 第一次調用它的get方法時它會通過create方法來初始化ActivityManagerService這個Binder對象， * 在后續的調用中則直接返回之前創建的對象。 * */ private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() { protected IActivityManager create() { IBinder b = ServiceManager.getService("activity"); if (false) { Log.v("ActivityManager", "default service binder = " + b); } /* * 將Binder對象轉換成對應IActivityManager的AIDL接口對象： * */ IActivityManager am = asInterface(b); if (false) { Log.v("ActivityManager", "default service = " + am); } return am; } }; ~~~ ActivityManagerService的startActivity方法： ~~~ @Override public final int startActivity(IApplicationThread caller, String callingPackage, Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode, int startFlags, String profileFile, ParcelFileDescriptor profileFd, Bundle options) { /* * Activity的啟動過程又轉移到了startActivityAsUser方法中，再進去看看： * */ return startActivityAsUser(caller, callingPackage, intent, resolvedType, resultTo, resultWho, requestCode, startFlags, profileFile, profileFd, options, UserHandle.getCallingUserId()); } ~~~ startActivityAsUser方法，在ActivityManagerService.java文件中。 ~~~ @Override public final int startActivityAsUser(IApplicationThread caller, String callingPackage, Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode, int startFlags, String profileFile, ParcelFileDescriptor profileFd, Bundle options, int userId) { enforceNotIsolatedCaller("startActivity"); userId = handleIncomingUser(Binder.getCallingPid(), Binder.getCallingUid(), userId, false, true, "startActivity", null); // TODO: Switch to user app stacks here. return mStackSupervisor.startActivityMayWait(caller, -1, callingPackage, intent, resolvedType, resultTo, resultWho, requestCode, startFlags, profileFile, profileFd, null, null, options, userId); } ~~~  * * * * * > 從上圖可以看出AMS中轉移到ActivityStackSupervisor的startActivityMayWait方法。 然后Activity的啟動在ActivityStackSupervisor與ActivityStack之間的傳遞，最終由ApplicationThread的scheduleLaunchActivity方法來啟動Activity。發送一個啟動Activity的消息交給Handler處理，Handler的名字叫H。 > 最終Activity的啟動過程由ActivityThread的handleLaunchActivity方法實現，最后調用performLaunchActivity方法。 * * * * * ActivityStackSupervisor的realStartActivityLocked方法中有如下一段代碼： ~~~ /* * 這個app.thread的類型為IApplicationThread， * IApplicationThread繼承了IInterface接口，所以它是一個Binder類型的接口。 * 從IApplicationThread聲明的接口方法可以看出，它的內部包含了大量啟動、停止Activity的接口， * 此外還包含了啟動和停止服務的接口， 從接口方法的命名可以知道， *IApplicationThread這個Binder接口的實現者完成了大量和Activity以及Service啟動和停止相關的功能。 *而IApplicationThread的實現者就是ActivityThread中的內部類ApplicationThread。 *所以，繞來繞去，是用ApplicationThread中的scheduleLaunchActivity來啟動Activity的。 */ app.thread.scheduleLaunchActivity(new Intent(r.intent), r.appToken, System.identityHashCode(r), r.info, new Configuration( mService.mConfiguration), r.compat, app.repProcState, r.icicle, results, newIntents, !andResume, mService.isNextTransitionForward(), profileFile, profileFd, profileAutoStop); ~~~ IApplicationThread * * * * * ApplicationThread繼承了ApplicationThreadNative，而ApplicationThreadNative則繼承了Binder并實現了IApplicationThread接口。 所以，這個ApplicationThreadNative就是IApplicationThread的實現者。由于ApplicationThreadNative被系統定義為抽象類，所以ApplicationThread就成了IApplicationThread最終的實現者。繞來繞去，是用ApplicationThread中的scheduleLaunchActivity來啟動Activity的。 * * * * * 在ApplicationThread中，scheduleLaunchActivity的實現很簡單，就是發送一個啟動Activity的消息交由Handler處理。這個Handler的名字很簡潔，H。 Handler H對消息的處理： ~~~ public void handleMessage(Message msg) { if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what)); switch (msg.what) { /* * 啟動Activity： * */ case LAUNCH_ACTIVITY: { Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityStart"); ActivityClientRecord r = (ActivityClientRecord)msg.obj; r.packageInfo = getPackageInfoNoCheck( r.activityInfo.applicationInfo, r.compatInfo); /* * 又轉到這里了： * */ handleLaunchActivity(r, null); Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); } break; ... } ~~~ 從handler對“LAUNCH_ACTIVITY”這個消息的處理可以知道，Activity的啟動過程由ActivityThread的 handleLaunchActivity這個方法實現， handleLaunchActivity方法： ~~~ private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent) { // If we are getting ready to gc after going to the background, well // we are back active so skip it. unscheduleGcIdler(); if (r.profileFd != null) { mProfiler.setProfiler(r.profileFile, r.profileFd); mProfiler.startProfiling(); mProfiler.autoStopProfiler = r.autoStopProfiler; } // Make sure we are running with the most recent config. handleConfigurationChanged(null, null); if (localLOGV) Slog.v( TAG, "Handling launch of " + r); /* * 啟動Activity終極大Boss在此！！！！ * */ Activity a = performLaunchActivity(r, customIntent); if (a != null) { r.createdConfig = new Configuration(mConfiguration); Bundle oldState = r.state; /* * 調用Activity的onResume方法： * */ handleResumeActivity(r.token, false, r.isForward, !r.activity.mFinished && !r.startsNotResumed); if (!r.activity.mFinished && r.startsNotResumed) { // The activity manager actually wants this one to start out // paused, because it needs to be visible but isn't in the // foreground. We accomplish this by going through the // normal startup (because activities expect to go through // onResume() the first time they run, before their window // is displayed), and then pausing it. However, in this case // we do -not- need to do the full pause cycle (of freezing // and such) because the activity manager assumes it can just // retain the current state it has. try { r.activity.mCalled = false; mInstrumentation.callActivityOnPause(r.activity); // We need to keep around the original state, in case // we need to be created again. But we only do this // for pre-Honeycomb apps, which always save their state // when pausing, so we can not have them save their state // when restarting from a paused state. For HC and later, // we want to (and can) let the state be saved as the normal // part of stopping the activity. if (r.isPreHoneycomb()) { r.state = oldState; } if (!r.activity.mCalled) { throw new SuperNotCalledException( "Activity " + r.intent.getComponent().toShortString() + " did not call through to super.onPause()"); } } catch (SuperNotCalledException e) { throw e; } catch (Exception e) { if (!mInstrumentation.onException(r.activity, e)) { throw new RuntimeException( "Unable to pause activity " + r.intent.getComponent().toShortString() + ": " + e.toString(), e); } } r.paused = true; } } else { // If there was an error, for any reason, tell the activity // manager to stop us. try { ActivityManagerNative.getDefault() .finishActivity(r.token, Activity.RESULT_CANCELED, null); } catch (RemoteException ex) { // Ignore } } } ~~~ performLaunchActivity方法最終完成了Activity對象的創建和啟動過程，且ActivityThread通過handleResumeActivity方法來調用被啟動的activity的onResume()這一生命周期方法。 performLaunchActivity主要完成以下幾件事 **1. 從ActivityClientRecord中獲取待啟動的Activity的組件信息：** ~~~ ActivityInfo aInfo = r.activityInfo; if (r.packageInfo == null) { r.packageInfo = getPackageInfo(aInfo.applicationInfo, r.compatInfo, Context.CONTEXT_INCLUDE_CODE); } ComponentName component = r.intent.getComponent(); if (component == null) { component = r.intent.resolveActivity( mInitialApplication.getPackageManager()); r.intent.setComponent(component); } if (r.activityInfo.targetActivity != null) { component = new ComponentName(r.activityInfo.packageName, r.activityInfo.targetActivity); } ~~~ **2. 通過Instrumentation的newActivity方法使用類加載器創建Activity對象。** ~~~ Activity activity = null; try { java.lang.ClassLoader cl = r.packageInfo.getClassLoader(); /* * 通過類加載器創建Activity的實例對象： * */ activity = mInstrumentation.newActivity( cl, component.getClassName(), r.intent); StrictMode.incrementExpectedActivityCount(activity.getClass()); r.intent.setExtrasClassLoader(cl); if (r.state != null) { r.state.setClassLoader(cl); } } catch (Exception e) { if (!mInstrumentation.onException(activity, e)) { throw new RuntimeException( "Unable to instantiate activity " + component + ": " + e.toString(), e); } } ~~~ **3. 通過LoadedApk的makeApplication方法來嘗試創建Application對象，而且一個應用只能有一個Application對象。** **4. 創建ContextImpl對象并通過Activity的attach方法來完成一些重要數據的初始化。** **5. 調用Activity的onCreate方法：** 完整代碼如下： ~~~ private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) { // System.out.println("##### [" + System.currentTimeMillis() + "] ActivityThread.performLaunchActivity(" + r + ")"); /* * 第一步：從ActivityClientRecord中獲取待啟動的Activity的組件信息： * */ ActivityInfo aInfo = r.activityInfo; if (r.packageInfo == null) { r.packageInfo = getPackageInfo(aInfo.applicationInfo, r.compatInfo, Context.CONTEXT_INCLUDE_CODE); } ComponentName component = r.intent.getComponent(); if (component == null) { component = r.intent.resolveActivity( mInitialApplication.getPackageManager()); r.intent.setComponent(component); } if (r.activityInfo.targetActivity != null) { component = new ComponentName(r.activityInfo.packageName, r.activityInfo.targetActivity); } /* * 第二步：通過Instrumentation的newActivity方法使用類加載器創建Activity對象。 * */ Activity activity = null; try { java.lang.ClassLoader cl = r.packageInfo.getClassLoader(); /* * 通過類加載器創建Activity的實例對象： * */ activity = mInstrumentation.newActivity( cl, component.getClassName(), r.intent); StrictMode.incrementExpectedActivityCount(activity.getClass()); r.intent.setExtrasClassLoader(cl); if (r.state != null) { r.state.setClassLoader(cl); } } catch (Exception e) { if (!mInstrumentation.onException(activity, e)) { throw new RuntimeException( "Unable to instantiate activity " + component + ": " + e.toString(), e); } } /* * 第三步：通過LoadedApk的makeApplication方法來嘗試創建Application對象， * 而且一個應用只能有一個Application對象。 * Application對象的創建也是通過Instrumentation來完成的，這個過程和Activity對象的創建一樣， * 都是通過類加載器來實現的。 * Application創建完畢后，系統會通過Instrumentation的callApplicationOnCreate來調用Application的onCreate方法。 * */ try { Application app = r.packageInfo.makeApplication(false, mInstrumentation); if (localLOGV) Slog.v(TAG, "Performing launch of " + r); if (localLOGV) Slog.v( TAG, r + ": app=" + app + ", appName=" + app.getPackageName() + ", pkg=" + r.packageInfo.getPackageName() + ", comp=" + r.intent.getComponent().toShortString() + ", dir=" + r.packageInfo.getAppDir()); if (activity != null) { /* * 第四步：創建ContextImpl對象并通過Activity的attach方法來完成一些重要數據的初始化。 * 這里有一堆Activity運行過程中所依賴的上下文環境變量， * 并通過Activity的attach方法來將這些環境變量與Activity相關聯： * （2）ContextImpl是一個很重要的數據結構，它是Context的具體實現， * Context中改的大部分邏輯都是由ContextImpl來完成的。 * ContextImpl是通過Activity的attach方法來和Activity建立關聯的。 * （3）此外，在attach方法中Activity還會完成Window的創建并建立自己和Window的關聯， * 這樣當Window接收到外部輸入事件后就可以將事件傳遞給Activity。 * */ Context appContext = createBaseContextForActivity(r, activity); CharSequence title = r.activityInfo.loadLabel(appContext.getPackageManager()); Configuration config = new Configuration(mCompatConfiguration); if (DEBUG_CONFIGURATION) Slog.v(TAG, "Launching activity " + r.activityInfo.name + " with config " + config); activity.attach(appContext, this, getInstrumentation(), r.token, r.ident, app, r.intent, r.activityInfo, title, r.parent, r.embeddedID, r.lastNonConfigurationInstances, config); if (customIntent != null) { activity.mIntent = customIntent; } r.lastNonConfigurationInstances = null; activity.mStartedActivity = false; int theme = r.activityInfo.getThemeResource(); if (theme != 0) { activity.setTheme(theme); } activity.mCalled = false; /* * 第五步：調用Activity的onCreate方法： * 到此為止，Activity也就完成了整個啟動過程， * 呵呵噠。 * */ mInstrumentation.callActivityOnCreate(activity, r.state); if (!activity.mCalled) { throw new SuperNotCalledException( "Activity " + r.intent.getComponent().toShortString() + " did not call through to super.onCreate()"); } r.activity = activity; r.stopped = true; if (!r.activity.mFinished) { activity.performStart(); r.stopped = false; } if (!r.activity.mFinished) { if (r.state != null) { mInstrumentation.callActivityOnRestoreInstanceState(activity, r.state); } } if (!r.activity.mFinished) { activity.mCalled = false; mInstrumentation.callActivityOnPostCreate(activity, r.state); if (!activity.mCalled) { throw new SuperNotCalledException( "Activity " + r.intent.getComponent().toShortString() + " did not call through to super.onPostCreate()"); } } } r.paused = true; mActivities.put(r.token, r); } catch (SuperNotCalledException e) { throw e; } catch (Exception e) { if (!mInstrumentation.onException(activity, e)) { throw new RuntimeException( "Unable to start activity " + component + ": " + e.toString(), e); } } return activity; } ~~~ 以上歸納幾點 1. ActivityManagerService（AMS）是Binder，ApplicationThread是Binder。 2. 一個應用只有一個Application對象，它的創建也是通過Instrumentation來完成的，這個過程和Activity對象的創建過程一樣，都是通過類加載器來實現的。 3. ContextImpl是Context的具體實現，ContextImpl是通過Activity的attach方法來和Activity建立關聯的，在attach方法中Activity還會完成Window的創建并建立自己和Window的關聯，這樣當window接收到外部輸入事件后就可以將事件傳遞給Activity。 ##### 二、Service的工作過程 1. 啟動狀態  2. 綁定狀態  ##### 三、BroadcastReceiver 的工作過程 1. 注冊（動態注冊）  2. 發送和接收  ##### 四、ContentProvider的工作過程