詳解Android中的ActivityThread和APP啟動過程
ActivityThread即Android的主線程，也就是UI線程，ActivityThread的main方法是一個APP的真正入口，MainLooper在它的main方法中被創建。
//ActivityThread的main方法public static void main(String[] args) { ... Looper.prepareMainLooper(); ActivityThread thread = new ActivityThread(); //在attach方法中會完成Application對象的初始化，然后調用Application的onCreate()方法 thread.attach(false); if (sMainThreadHandler == null) {sMainThreadHandler = thread.getHandler(); } ... Looper.loop(); throw new RuntimeException('Main thread loop unexpectedly exited');}
接下來從主線程Looper的初始化和ApplicationThread及Activity的創建啟動兩方面，通過源碼了解學習下大致的流程。
主線程Looper的初始化Looper.prepareMainLooper();相關的代碼如下
//主線程Looper的初始化public static void prepareMainLooper() { prepare(false); synchronized (Looper.class) {if (sMainLooper != null) { throw new IllegalStateException('The main Looper has already been prepared.');}sMainLooper = myLooper(); }}//普通線程Looper的初始化public static void prepare() { prepare(true);}private static void prepare(boolean quitAllowed) { if (sThreadLocal.get() != null) {throw new RuntimeException('Only one Looper may be created per thread'); } sThreadLocal.set(new Looper(quitAllowed));}
看過Handler源碼就知道，主線程Looper的初始化和普通線程Looper的初始化很相似，但還是有以下幾個區別
1.普通線程的Prepare()默認quitAllowed參數為true，表示允許退出，而主線程也就是ActivityThread的Looper參數為false，不允許退出。這里的quitAllowed參數，最終會傳遞給MessageQueue，當調用MessageQueue的quit方法時，會判斷這個參數，如果是主線程，也就是quitAllowed參數為false時，會拋出異常。
//Looper的退時會判斷quitAllowedvoid quit(boolean safe) { if (!mQuitAllowed) {throw new IllegalStateException('Main thread not allowed to quit.'); } synchronized (this) {... }}
2.我們注意到主線程Looper初始化之后，賦值給了成員變量sMainLooper，這個成員的作用就是向其他線程提供主線程的Looper對象。這下我們就應該知道為什么Looper.getMainLooper()方法能獲取主線程的Looper對象了
public static Looper getMainLooper() { synchronized (Looper.class) {return sMainLooper; }}主線程Handler的初始化
在ActivityThread的main方法中我們注意到一行代碼：
ActivityThread thread = new ActivityThread();thread.attach(false);if (sMainThreadHandler == null) { sMainThreadHandler = thread.getHandler();}
見名知意，這是獲取主線程的Handler，那么主線程的Handler是在什么時候初始化的呢？
//與之相關的代碼如下：//ActivityThread的成員變量final H mH = new H();final Handler getHandler() { return mH;}
從以上代碼中可以看到，主線程的Handler作為ActivityThread的成員變量，是在ActivityThread的main方法被執行，ActivityThread被創建時而初始化，而接下來要說的ApplicationThread中的方法執行以及Activity的創建都依賴于主線程Handler。至此我們也就明白了，主線程（ActivityThread）的初始化是在它的main方法中，主線程的Handler以及MainLooper的初始化時機都是在ActivityThread創建的時候。
ApplicationThread及Activity的創建和啟動以上的代碼和流程，就是對 MainLooper 和 ActivityThread 的初始化，我們接下來看一下 ActivityThread 的初始化及其對應的 attach 方法，在thread.attach方法中，ActivityManagerService通過attachApplication方法，將ApplicationThread對象綁定到ActivityManagerService，ApplicationThread是ActivityThread的私有內部類，實現了IBinder接口，用于ActivityThread和ActivityManagerService的所在進程間通信。
//ActivityThread的attach方法：private void attach(boolean system) { ... if (!system) {final IActivityManager mgr = ActivityManager.getService();try { mgr.attachApplication(mAppThread);} catch (RemoteException ex) { throw ex.rethrowFromSystemServer();}else{ ...} }}//ActivityManagerService中的方法：public final void attachApplication(IApplicationThread thread) { synchronized (this) {int callingPid = Binder.getCallingPid();final long origId = Binder.clearCallingIdentity();attachApplicationLocked(thread, callingPid);Binder.restoreCallingIdentity(origId); }}
這里的個人理解是：在每個ActivityThread（APP）被創建的時候，都需要向ActivityManagerService綁定（或者說是向遠程服務AMS注冊自己），用于AMS管理ActivityThread中的所有四大組件的生命周期。
上述AMS的代碼中attachApplicationLocked方法比較復雜，主要功能有兩個，詳見注釋，這里忽略了很多代碼細節，具體的流程可以看源碼
//AMS中的方法，主要功能有以下兩步private final boolean attachApplicationLocked(IApplicationThread thread, int pid) { ... //主要用于創建Application，用調用onCreate方法 thread.bindApplication(...); ... //主要用于創建Activity if (mStackSupervisor.attachApplicationLocked(app)) {... }}
1.thread.bindApplication：主要用于創建Application，這里的thread對象是ApplicationThread在AMS中的代理對象，所以這里的bindApplication方法最終會調用ApplicationThread.bindApplication()方法，該方法會向ActivityThread的消息對應發送BIND_APPLICATION的消息，消息的處理最終會調用Application.onCreate()方法，這也說明Application.onCreate()方法的執行時機比任何Activity.onCreate()方法都早。
//ActivityThread中的bindApplication方法public final void bindApplication(...) { ... // 該消息的處理，會調用handleBindApplication方法 sendMessage(H.BIND_APPLICATION, data);}//ActivityThread中的handleBindApplication方法private void handleBindApplication(AppBindData data) { ... try {Application app = data.info.makeApplication(data.restrictedBackupMode, null);mInitialApplication = app;...try { mInstrumentation.callApplicationOnCreate(app);} catch (Exception e) {} } finally { }} //LoadedApk中的方法，用于創建Applicationpublic Application makeApplication(boolean forceDefaultAppClass, Instrumentation instrumentation) { //如果存在Application的實例，則直接返回，這也說明Application是個單例 if (mApplication != null) {return mApplication; } Application app = null; //...這里通過反射初始化Application if (instrumentation != null) {try { //調用Application的onCreate方法 instrumentation.callApplicationOnCreate(app);} catch (Exception e) {} } return app;}
2.mStackSupervisor.attachApplicationLocked(app)：用于創建Activity，mStackSupervisor是AMS的成員變量，為Activity堆棧管理輔助類實例，該方法最終會調用ApplicationThread類的scheduleLaunchActivity方法，該方法也是類似于第一步，向ActivityThread的消息隊列發送創建Activity的消息，最終在ActivityThread中完成創建Activity的操作。
boolean attachApplicationLocked(ProcessRecord app) throws RemoteException { ... if (realStartActivityLocked(hr, app, true, true)) {... } ...}final boolean realStartActivityLocked(ActivityRecord r, ProcessRecord app, boolean andResume, boolean checkConfig) throws RemoteException { ... try {//調用ApplicationThread的scheduleLaunchActivity用于啟動一個Activityapp.thread.scheduleLaunchActivity(...); } catch (RemoteException e) { }}
ApplicationThread的scheduleLaunchActivity方法會向ActivityThread發送LAUNCH_ACTIVITY信息，用于啟動一個Activity，該消息的處理會調用ActivityThread的handleLaunchActivity方法，最終啟動一個Activity
以上就是從ActivityThread的main方法執行到Activity的創建之間的流程，至于ActivityThread的main方法執行時機，以及執行前的流程和Activity的具體創建過程，可以接著看APP的啟動過程
APP的啟動系統的啟動過程在學習APP的啟動之前先簡單了解下系統的啟動，有助于我們更好的學習APP的啟動。系統的啟動過程很復雜，這里簡單化，只關心大致流程和涉及到的一些名詞以及相關類的作用
APP的啟動可以簡單總結為一下幾個流程：
加載BootLoader --> 初始化內核 --> 啟動init進程 --> init進程fork出Zygote進程 --> Zygote進程fork出SystemServer進程
APP的啟動，我們使用一張圖來說明這個啟動過程，順便也總結下上面所說的ActivityThread的main方法執行到Activity的創建之間的流程。
1.點擊桌面APP圖標時，Launcher的startActivity()方法，通過Binder通信，調用system_server進程中AMS服務的startActivity方法，發起啟動請求
2.system_server進程接收到請求后，向Zygote進程發送創建進程的請求
3.Zygote進程fork出App進程，并執行ActivityThread的main方法，創建ActivityThread線程，初始化MainLooper，主線程Handler，同時初始化ApplicationThread用于和AMS通信交互
4.App進程，通過Binder向sytem_server進程發起attachApplication請求，這里實際上就是APP進程通過Binder調用sytem_server進程中AMS的attachApplication方法，上面我們已經分析過，AMS的attachApplication方法的作用是將ApplicationThread對象與AMS綁定
5.system_server進程在收到attachApplication的請求，進行一些準備工作后，再通過binder IPC向App進程發送handleBindApplication請求（初始化Application并調用onCreate方法）和scheduleLaunchActivity請求（創建啟動Activity）
6.App進程的binder線程（ApplicationThread）在收到請求后，通過handler向主線程發送BIND_APPLICATION和LAUNCH_ACTIVITY消息，這里注意的是AMS和主線程并不直接通信，而是AMS和主線程的內部類ApplicationThread通過Binder通信，ApplicationThread再和主線程通過Handler消息交互。 ( 這里猜測這樣的設計意圖可能是為了統一管理主線程與AMS的通信，并且不向AMS暴露主線程中的其他公開方法)
7.主線程在收到Message后，創建Application并調用onCreate方法，再通過反射機制創建目標Activity，并回調Activity.onCreate()等方法
8.到此，App便正式啟動，開始進入Activity生命周期，執行完onCreate/onStart/onResume方法，UI渲染后顯示APP主界面
APP啟動過程的部分代碼思考在上面學習APP的啟動過程中，看源碼的同時注意到一個代碼，就是主線程Handler在接收到LAUNCH_ACTIVITY創建Activity的消息后，創建Activity的部分代碼如下：
//主線程Handler接收到創建Activity的消息LAUNCH_ACTIVITY后，最終會調用performLaunchActivity方法//performLaunchActivity方法會通過反射去創建一個Activity，然后會調用Activity的各個生命周期方法private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) { ... ContextImpl appContext = createBaseContextForActivity(r); Activity activity = null; try {//這里是反射創建Activityjava.lang.ClassLoader cl = appContext.getClassLoader();activity = mInstrumentation.newActivity(cl, component.getClassName(), r.intent);StrictMode.incrementExpectedActivityCount(activity.getClass());r.intent.setExtrasClassLoader(cl);r.intent.prepareToEnterProcess();if (r.state != null) { r.state.setClassLoader(cl);} } try {//這里注意，又調用了一次Application的創建方法，但是前面分析過，Application是個單例，所以這里的實際上是獲取Application實例，但是這里為什么會再次調用創建Application的方法呢？Application app = r.packageInfo.makeApplication(false, mInstrumentation);... } ... return activity;}
在上面的代碼中，簡單注釋了一下在Activity的創建方法中，會再次調用Application的創建方法（第一次調用是在接收到BIND_APPLICATION消息的時候），個人覺得這里再次調用Application的創建方法，除了獲取已經存在的Application實例這種情況，另外一種情況還有可能是要創建的這個Activity屬于另外一個進程，當去啟動這個新進程中的Activity時，會先去創建新進程和Application實例，因為我們知道一個常識：
1.APP中有幾個進程，Application會被創建幾次
2.新進程中所有變量和單例會失效，因為新進程有一塊新的內存區域
那么這兩點的關系就是，因為新進程中Application實例會為空，所以會再次去創建Application實例，這也就是第一點中我們所說的常識：APP中有幾個進程，Application會被創建幾次
//創建Application的方法public Application makeApplication(boolean forceDefaultAppClass, Instrumentation instrumentation) { //如果存在Application的實例，則直接返回，這也說明Application是個單例 if (mApplication != null) {return mApplication; } Application app = null; //...創建Application return app;}
那么依次類推，Service作為四大組件之一，類似于Activity的創建和啟動，創建Service的方法中會不會也調用了創建Application的方法（makeApplication方法），答案是肯定的！和Activity的創建類似，當我們調用startService的時候，也是通過Binder向AMS發送創建Service的請求，AMS準備后再向APP進程發送scheduleCreateService的請求，然后主線程handle收到CREATE_SERVICE的消息，調用handleCreateService創建Service的方法。在創建Service的方法handleCreateService中也調用了創建Application的方法，具體代碼看源碼吧。所以我們也徹底明白了為什么APP中有幾個進程，Application會被創建幾次，以及Application為什么是個單例。
總結APP的啟動過程很復雜，代碼錯綜交橫，這里分析了大概流程，學習這部分的過程中還是有很多收獲，例如知道了AMS與主線程的關系，主線程main方法中就是APP的入口，Binder通信機制和handler消息機制在這個過程中的重要作用，Application的創建時機以及Application為什么是單例，為什么有幾個進程就創建幾個Application…等等 。
以上就是詳解Android中的ActivityThread和APP啟動過程的詳細內容，更多關于Android ActivityThread APP啟動過程的資料請關注好吧啦網其它相關文章！
相關文章：
網公網安備