ActivityThread的理解和APP的啓動過程

ActivityThread的理解和APP的啓動過程

    ActivityThread
        ActivityThread的初始化
        主線程Looper的初始化
        主線程Handler的初始化
        ApplicationThread及Activity的建立和啓動
    APP的啓動
        系統的啓動過程
        APP的啓動過程
        APP啓動過程的部分代碼思考
    總結

ActivityThread

ActivityThread就是咱們常說的主線程或UI線程，ActivityThread的main方法是整個APP的入口，本篇深刻學習下ActivityThread，順便了解下APP和Activity的啓動過程。
ActivityThread的初始化

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的初始化很類似，但仍是有如下幾個區別

    普通線程的Prepare()默認quitAllowed參數爲true，表示容許退出，而主線程也就是ActivityThread的Looper參數爲false，不容許退出。這裏的quitAllowed參數，最終會傳遞給MessageQueue，當調用MessageQueue的quit方法時，會判斷這個參數，若是是主線程，也就是quitAllowed參數爲false時，會拋出異常。

        Looper的退時會判斷quitAllowed
        void quit(boolean safe) {
            if (!mQuitAllowed) {
                throw new IllegalStateException("Main thread not allowed to quit.");
            }
            synchronized (this) {
                ...
            }
        }
    

    咱們注意到主線程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)) {
            ...
        }
    }

    

    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中的方法，用於建立Application
        public 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;
        }
     

    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用於啓動一個Activity
                app.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進程

    系統中的全部常常進程都是由Zygote進程fork出來的
    SystemServer進程是系統進程，不少系統服務，例如ActivityManagerService、PackageManagerService、WindowManagerService…都是存在該進程被建立後啓動
    ActivityManagerServices（AMS）：是一個服務端對象，負責全部的Activity的生命週期，AMS經過Binder與Activity通訊，而AMS與Zygote之間是經過Socket通訊
    ActivityThread：本篇的主角，UI線程/主線程，它的main()方法是APP的真正入口
    ApplicationThread：一個實現了IBinder接口的ActivityThread內部類，用於ActivityThread和AMS的所在進程間通訊
    Instrumentation：能夠理解爲ActivityThread的一個工具類，在ActivityThread中初始化，一個進程只存在一個Instrumentation對象，在每一個Activity初始化時，會經過Activity的Attach方法，將該引用傳遞給Activity。Activity全部生命週期的方法都有該類來執行

APP的啓動過程

APP的啓動，咱們使用一張圖來講明這個啓動過程，順便也總結下上面所說的ActivityThread的main方法執行到Activity的建立之間的流程。圖是從網上盜的…

    點擊桌面APP圖標時，Launcher的startActivity()方法，經過Binder通訊，調用system_server進程中AMS服務的startActivity方法，發起啓動請求
    system_server進程接收到請求後，向Zygote進程發送建立進程的請求
    Zygote進程fork出App進程，並執行ActivityThread的main方法，建立ActivityThread線程，初始化MainLooper，主線程Handler，同時初始化ApplicationThread用於和AMS通訊交互
    App進程，經過Binder向sytem_server進程發起attachApplication請求，這裏實際上就是APP進程經過Binder調用sytem_server進程中AMS的attachApplication方法，上面咱們已經分析過，AMS的attachApplication方法的做用是將ApplicationThread對象與AMS綁定
    system_server進程在收到attachApplication的請求，進行一些準備工做後，再經過binder IPC向App進程發送handleBindApplication請求（初始化Application並調用onCreate方法）和scheduleLaunchActivity請求（建立啓動Activity）
    App進程的binder線程（ApplicationThread）在收到請求後，經過handler向主線程發送BIND_APPLICATION和LAUNCH_ACTIVITY消息，這裏注意的是AMS和主線程並不直接通訊，而是AMS和主線程的內部類ApplicationThread經過Binder通訊，ApplicationThread再和主線程經過Handler消息交互。 ( 這裏猜想這樣的設計意圖多是爲了統一管理主線程與AMS的通訊，而且不向AMS暴露主線程中的其餘公開方法，大神能夠來解析下)
    主線程在收到Message後，建立Application並調用onCreate方法，再經過反射機制建立目標Activity，並回調Activity.onCreate()等方法
    到此，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 {
            這裏是反射建立Activity
            java.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實例，由於咱們知道一個常識：

    APP中有幾個進程，Application會被建立幾回
    新進程中全部變量和單例會失效，由於新進程有一塊新的內存區域

那麼這兩點的關係就是，由於新進程中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…等等，看源碼真的能漲知識 >…< 。