Launcher啟動Acivity（未啟動Activity所在程序）

public abstract class LauncherActivity extends ListActivity {
    @Override
    protected void onListItemClick(ListView l, View v, int position, long id) {
        Intent intent = intentForPosition(position);
        startActivity(intent);
    }
}

已有程序啟動Acivity

無論是那種方式，事件都是從Activity的startActivity(intent)開始的。
這是一張我畫的已有程序啟動Activity的時序圖：

通過這張時序圖我們可以發現Activity的啟動是一件很複雜的東西，這裡面隱藏了很多的細節，涉及到了多次的IPC（程序間通訊），上面的場景可以想象成Activity_A啟動Activity_B,這張時序圖裡包含很多的知識點.

知識點1:

不知道大家有沒有看過我的Binder機制圖解那篇文章，client端持有Proxy代理物件，訪問Server端的本地物件時,Server端是通過Binder執行緒池中的執行緒來處理程序間通訊的,這也是為什麼程式會設計的一個名為H的內部類，因為當ApplicationThreadProxy呼叫ApplicationThread執行相應的pause或者create操作的時候，ApplicationThread這個Binder本地物件實際上是在Binder執行緒中執行的，所以才需要H這個Handler來和ActivityThread主執行緒進行執行緒間通訊，ActivityThread只是一個普通的java類，並不是一個執行緒，但它位於程序中，那ActivityThread的動力是什麼？

ActivityThread 的動力是什麼？

程序

每個app執行時前首先建立一個程序，該程序是由 Zygote fork 出來的，用於承載App上執行的各種 Activity/Service等元件。程序對於上層應用來說是完全透明的，這也是google有意為之，讓App程式都是執行在 Android Runtime。大多數情況一個App就執行在一個程序中，除非在 AndroidManifest.xml 中配置 Android:process 屬性，或通過 native 程式碼 fork 程序。

執行緒

執行緒對應用來說非常常見，比如每次 new Thread().start 都會建立一個新的執行緒。該執行緒與App所在程序之間資源共享，從Linux 角度來說程序與執行緒除了是否共享資源外，並沒有本質的區別，都是一個 task_struct結構體，在CPU看來程序或執行緒無非就是一段可執行的程式碼，CPU 採用 CFS排程演算法，保證每個 task 都儘可能公平的享有 CPU時間片。

其實承載 ActivityThread 的主執行緒就是由 Zygote fork 而建立的程序。

知識點2:
onPause中為什麼不推薦執行耗時操作，我們知道Activity_A啟動Activity_B會先啟動Activity_A生命週期中的onPause回撥函式，然後才執行Activity_B的生命週期中的onCreate回撥函式，從時序圖中我們可以發現H類將pause相關的資訊轉發給了位於主執行緒的ActivityThread，而ActivityThread又呼叫了Instrumentation的callActivityOnPause函式，最終執行Activity的onPause，也就是說這一系列的過程都是在主執行緒執行的，當然不可以進行耗時操作，這是其一，其二隻有當onPause執行完成才會執行activityPaused方法呼叫ActivityManagerProxy執行下一步的操作，也就是說如果onPause邏輯過多，過於耗時將不能很好的啟動Activity_B。

區別
那麼已有程序和Launcher啟動未啟動程序的區別在於ActivityStack.startSpecificActivityLocked函式執行後，會進行要啟動Activity是否有對應程序的判斷，如果有直接執行realStartActivityLocked，如果沒有就需要先建立程序。然後在程序啟動後再執行realStartActivityLocked來啟動Activity。

關於應用程序的建立我將單獨發一篇部落格來說明，然後大家再結合這張時序圖將空白程序建立部分補上。