一 . 理論基礎(chǔ)
在Android中，由于Binder通信機(jī)制的存在，進(jìn)程遷移使用的非常非常頻繁，Android四大組件都可以進(jìn)行進(jìn)程間數(shù)據(jù)通訊。
對(duì)于Binder Service端：
（1） 定義AIDL文件來公開服務(wù)的接口（比如 scheduleLauncherActivity，bindapplication，shceduleReceiver或者mic，打開camera，點(diǎn)燈等等） （2）編譯AIDL生成對(duì)應(yīng)的接口interface的java文件 （3）實(shí)現(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. 硬件操控功能（實(shí)現(xiàn)了interface） 2.進(jìn)程間通訊功能 （因?yàn)槔^承了Binder） （4）.將該service添加到SystemServer （ eg：ServiceManager.addService("lcled", new LedService());）對(duì)于Binder Client端
（1）通過ServiceManager.getService("lcled")獲取遠(yuǎn)程服務(wù)的Binder,也即是遠(yuǎn)程Stub。（如Binder Service端(3)所示這個(gè)Stub需要實(shí)現(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)成了對(duì)應(yīng)硬件功能接口的代理Proxy。因?yàn)樵揚(yáng)roxy在aidl生成java接口類時(shí)，作為Stub的內(nèi)部類已經(jīng)實(shí)現(xiàn)了外部 父類接口，那么便可以利用Proxy擁有的成員方法訪問遠(yuǎn)程服務(wù)，這樣實(shí)現(xiàn)了ipC通訊總結(jié)： AIDL只是一個(gè)類似Webservie的功能清單接口，繼承了它的類便可以擁有對(duì)應(yīng)的服務(wù)功能。
真正實(shí)現(xiàn)夸進(jìn)程通訊的是Binder，也就是該AIDL內(nèi)部的Stub類。（類似具體的SOAP了）服務(wù)的主調(diào)方獲取該Stub，然后利用該Stub內(nèi)部的代理Proxy調(diào)用功能接口。二. 開始分析Activity的啟動(dòng)過程
主要涉及兩個(gè)方向的IPC通訊，分別對(duì)應(yīng)不同的功能的Binder實(shí)現(xiàn)類當(dāng)APP代碼中調(diào)用startActivity時(shí)， startActivitForResult mInstrumentation.execStartActivity（this,mainThread.getApplicationThread（），x，x，x，x，x） { IApplicationThread whoThread =（ IApplicationThread ） mainThread.getApplicationThread（） //這里的 IApplicationThread 就是一個(gè)AIDL生成的功能接口類
ActivityMannagerNative.getDefault().startActivity（whoThread，x，x，x，x，x......） }*Note** :至此出現(xiàn)了第一個(gè)IPC通訊，ActivityMannagerNative（ ActivityManagerNative extends Binder implements IActivityManager因此這個(gè) ActivityManagerNative對(duì)應(yīng)是AIDL中的Stub）
APP端作為Binder的Client 在 ActivityMannagerNative.java的ActivityMannagerNative.getDefault()方法中
IBinder b = ServiceManager.getService("activity"); （這里獲取的是ActivityMannagerService這個(gè)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，注意這個(gè)ActivityMannagerProxy肯定是ActivityMannagerNative的內(nèi)部類，并且肯定實(shí)現(xiàn)了IActivityManager，看代碼果不其然那么繼續(xù)可以猜測ActivityMannagerService肯定繼承了ActivityMannagerNative，看源碼可以得到證實(shí)。（這里的ActivityMannagerService是具體實(shí)現(xiàn)IActivityManager接口功能java類，相當(dāng)于繼承AIDL中內(nèi)部stub的Ledservice這些具體功能類，見理論基礎(chǔ)第（3）步）這樣通過IPC，代碼從APP的進(jìn)程切換到AMS進(jìn)程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接口，因此也是一個(gè)Binder， 而其實(shí)app.thread就是ActivityThread.ApplicationThread,這個(gè)Binder是ActivityThread與AMS進(jìn)程通信的時(shí)候傳過去的參數(shù),也就是上面IApplicationThread whoThread 至此，第二個(gè)Binder出現(xiàn)了，只不過這次是以client binder出現(xiàn)，而APP的主線程ActivityThread的內(nèi)部類ApplicationThread才是這里的stub，那么可以猜測ApplicationThread一定繼承了Binder并且是實(shí)現(xiàn)了IApplicationThread，觀察源碼在ActivtyThread中有內(nèi)部類 ApplicationThread extends ApplicationThreadNative而 public abstract class ApplicationThreadNative extends Binder implements IApplicationThread { ，//真是果不其然
總結(jié)，app調(diào)用了startActivity后，先從ActivityThread主線程通過第一個(gè)Binder（ActivityMannagerService）切入系統(tǒng)system_process調(diào)用AMS功能。而后又通過第一次RPC遠(yuǎn)程調(diào)用傳過去的Binder（ApplicationThread）切換回了APP的進(jìn)程，繼續(xù)執(zhí)行。而真正啟動(dòng)Activiy的功能代碼肯定還是在主線程ActivitThread的內(nèi)部類ApplicationThread中。
最終得到應(yīng)用APP啟動(dòng)的一個(gè)過程：
系統(tǒng)得到啟動(dòng)某個(gè)APP的命令后，主動(dòng)去啟動(dòng)Action為android.intent.action.MAIN. category ="android.intent.category.LAUNCHER"的Activity接著通過Binder ActivityMannagerService 將該請(qǐng)求發(fā)給在System_process執(zhí)行一些處理后，通過 ApplicationThread 這個(gè)Binder返回APP所在進(jìn)程，然后在進(jìn)程的主線程ActivityThread中通過給主線程的Handle發(fā)消息調(diào)用其handleLanucherActivity方法，這里會(huì) 一. （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方法
新聞熱點(diǎn)
疑難解答
圖片精選
網(wǎng)友關(guān)注
