一 . 理論基礎(chǔ)
在Android中，由于Binder通信機制的存在，進程遷移使用的非常非常頻繁，Android四大組件都可以進行進程間數(shù)據(jù)通訊。
對于Binder Service端：
（1） 定義AIDL文件來公開服務(wù)的接口（比如 scheduleLauncherActivity，bindapplication，shceduleReceiver或者mic，打開camera，點燈等等） （2）編譯AIDL生成對應(yīng)的接口interface的java文件 （3）實現(xiàn)自定義Android系統(tǒng) Service的java類，該類要求繼承（2）步中的interface的stub子類（eg：public static abstract class Stub extends android.os.Binder implements android.os.ILedService） 這樣該自定義服務(wù)變具備的 1. 硬件操控功能（實現(xiàn)了interface） 2.進程間通訊功能 （因為繼承了Binder） （4）.將該service添加到SystemServer （ eg：ServiceManager.addService("lcled", new LedService());）對于Binder Client端
（1）通過ServiceManager.getService("lcled")獲取遠程服務(wù)的Binder,也即是遠程Stub。（如Binder Service端(3)所示這個Stub需要實現(xiàn)功能接口Ixxx，又要繼承Binder類） （注意系統(tǒng)中首先要有ILedService 1. 可以利用mmm命令自編androdid系統(tǒng)生成相應(yīng)的class.jar，然后以jar的形式導(dǎo)入android studio并在PRoject Structure設(shè)置Dependency 然后在APP中import android.os.ILedService; 2 . 可以仿造應(yīng)用層，拷貝Service第一步aidl文件來生成相應(yīng)的java接口類 ) （2）利用ILedService.Stub.asInterface(第（1）步的Binder) ;轉(zhuǎn)成了對應(yīng)硬件功能接口的代理Proxy。因為該Proxy在aidl生成java接口類時，作為Stub的內(nèi)部類已經(jīng)實現(xiàn)了外部 父類接口，那么便可以利用Proxy擁有的成員方法訪問遠程服務(wù)，這樣實現(xiàn)了ipC通訊總結(jié)： AIDL只是一個類似Webservie的功能清單接口，繼承了它的類便可以擁有對應(yīng)的服務(wù)功能。
真正實現(xiàn)夸進程通訊的是Binder，也就是該AIDL內(nèi)部的Stub類。（類似具體的SOAP了）服務(wù)的主調(diào)方獲取該Stub，然后利用該Stub內(nèi)部的代理Proxy調(diào)用功能接口。二. 開始分析Activity的啟動過程
主要涉及兩個方向的IPC通訊，分別對應(yīng)不同的功能的Binder實現(xiàn)類當APP代碼中調(diào)用startActivity時， startActivitForResult mInstrumentation.execStartActivity（this,mainThread.getApplicationThread（），x，x，x，x，x） { IApplicationThread whoThread =（ IApplicationThread ） mainThread.getApplicationThread（） //這里的 IApplicationThread 就是一個AIDL生成的功能接口類
ActivityMannagerNative.getDefault().startActivity（whoThread，x，x，x，x，x......） }*Note** :至此出現(xiàn)了第一個IPC通訊，ActivityMannagerNative（ ActivityManagerNative extends Binder implements IActivityManager因此這個 ActivityManagerNative對應(yīng)是AIDL中的Stub）
APP端作為Binder的Client 在 ActivityMannagerNative.java的ActivityMannagerNative.getDefault()方法中
IBinder b = ServiceManager.getService("activity"); （這里獲取的是ActivityMannagerService這個Binder） if (false) { Log.v("ActivityManager", "default service binder = " + b); } IActivityManager am = asInterface(b); if (false) { Log.v("ActivityManager", "default service = " + am); } return am;我猜測這里返回了ActivityMannagerProxy，注意這個ActivityMannagerProxy肯定是ActivityMannagerNative的內(nèi)部類，并且肯定實現(xiàn)了IActivityManager，看代碼果不其然那么繼續(xù)可以猜測ActivityMannagerService肯定繼承了ActivityMannagerNative，看源碼可以得到證實。（這里的ActivityMannagerService是具體實現(xiàn)IActivityManager接口功能java類，相當于繼承AIDL中內(nèi)部stub的Ledservice這些具體功能類，見理論基礎(chǔ)第（3）步）這樣通過IPC，代碼從APP的進程切換到AMS進程system_process繼續(xù)執(zhí)行現(xiàn)在到AMS的startActivity
startActivity（IApplicationThread caller，x，x，x.....） startActivityAsUser（IApplicationThread caller，x，x，x.....） mStackSupervisor.startActivityMayWait（IApplicationThread caller，x，x，x.....） startActivityLocked startActivityUncheckedLocked resumeTopActivityLocked resumeTopActivityLockedInnerLocked startSpecificActivityLocked realStartActivityLocked { app.thread.scheduleLaunchActivity（new Intent（r.intent），x，x，x.....） }Note： 這里的app.thread類型為 IApplicationThread，分析源碼發(fā)現(xiàn)其繼承了IInterface接口，因此也是一個Binder， 而其實app.thread就是ActivityThread.ApplicationThread,這個Binder是ActivityThread與AMS進程通信的時候傳過去的參數(shù),也就是上面IApplicationThread whoThread 至此，第二個Binder出現(xiàn)了，只不過這次是以client binder出現(xiàn)，而APP的主線程ActivityThread的內(nèi)部類ApplicationThread才是這里的stub，那么可以猜測ApplicationThread一定繼承了Binder并且是實現(xiàn)了IApplicationThread，觀察源碼在ActivtyThread中有內(nèi)部類 ApplicationThread extends ApplicationThreadNative而 public abstract class ApplicationThreadNative extends Binder implements IApplicationThread { ，//真是果不其然
總結(jié)，app調(diào)用了startActivity后，先從ActivityThread主線程通過第一個Binder（ActivityMannagerService）切入系統(tǒng)system_process調(diào)用AMS功能。而后又通過第一次RPC遠程調(diào)用傳過去的Binder（ApplicationThread）切換回了APP的進程，繼續(xù)執(zhí)行。而真正啟動Activiy的功能代碼肯定還是在主線程ActivitThread的內(nèi)部類ApplicationThread中。
最終得到應(yīng)用APP啟動的一個過程：
系統(tǒng)得到啟動某個APP的命令后，主動去啟動Action為android.intent.action.MAIN. category ="android.intent.category.LAUNCHER"的Activity接著通過Binder ActivityMannagerService 將該請求發(fā)給在System_process執(zhí)行一些處理后，通過 ApplicationThread 這個Binder返回APP所在進程，然后在進程的主線程ActivityThread中通過給主線程的Handle發(fā)消息調(diào)用其handleLanucherActivity方法，這里會 一. （1）獲取新Activity組件信息。 （2）利用類加載器ClassLoader創(chuàng)建新Activity （3）通過LoadedApl的makeApplicaotion方法創(chuàng)建Application（已經(jīng)存在則直接返回） （4）創(chuàng)建contextimpl并attach到新的activity （5）將activity與window關(guān)聯(lián) （6）mInstrumentation.callActivityOnCreate方法調(diào)用activity的onCreate方法 二. handleResumeActivity，最終調(diào)用activity的onResume方法
新聞熱點
疑難解答
