前言
本故事純屬虛構，如有不通順的邏輯請輕噴。❤️
《犬夜叉2021》
第一章：我還能找到你嗎，阿籬
犬夜叉和奈落大決戰之后，四魂之玉、食骨之井消失，誰也不知道去了哪，而犬夜叉和阿籬再次被分割到兩個世界。
於是犬夜叉拜托一位研究世界宇宙的法師——積木，來幫助他找到阿籬。
時間轉眼來到了2021年，積木終於發現了這個世界的秘密。。
其實我們所在的整個宇宙叫做Android宇宙，犬夜叉和阿籬所處的兩個世界其實是兩個進程，兩個世界可以通過食骨之井相連接。
所以想讓犬夜叉重新聯系到阿籬，必須再找到當年的食骨之井。
第二章：食骨之井改名Binder井？
“犬夜叉，我終於找到了”
“找到什么了？是阿籬嗎？阿籬找到了？？？？”
“沒有，不過我找到了關鍵的東西——食骨之井”
“在哪，快帶我去”
於是，積木法師帶着犬夜叉來到一間屋子里：
這間屋子門面上寫着《內核屋》三個大字，犬夜叉一個箭步飛了進去，在里面果然找到了當年那個食骨之井，但是又有點不一樣，因為它被改了名，旁邊一個破碎的板子上寫着——Binder井。板子上還同時刻有使用說明：
Binder井
這口井聯系這兩個世界，你看到的也許不是真實的，請慎用！
如需使用，請找到當年遺落的四魂之玉，現在它叫SM之玉（ServiceManager）。
找到SM之玉，心里默念你想聯系的那個世界那個人，如果她在那個世界的SM之玉碎片中留下了地址，那么你就能找到她。
“積木法師，你知道SM之玉嗎，哪里可以找到它”，犬夜叉問到。
第三章：四魂之玉——ServiceManager
“說到SM之玉，還要從宇宙的起源說起，Android宇宙創建初期，誕生了第一個有人的世界（用戶進程），叫做Init世界，而SM之玉就是由這個世界創建的。
SM之玉創建后，啟動了Binder井，成為了他的守護神。
但是它的真身存在於單獨的世界中，無法獲得。為了讓人們能夠使用到它，它特意在每個世界都留下了自己的碎片（代理）。”
“在哪在哪，快告訴我”。
“第0街道（句柄值固定為0）”，積木法師指了一個方向說到。
第四章：阿籬，我想你了
犬夜叉急忙去第0街道找到了SM之玉的碎片，然后回到Binder井旁邊，心里默念道：
“
SM之玉，
求求你幫我找到阿籬吧。
”
忽然，Binder井刮出一陣狂風，一個虛影出現在了犬夜叉的面前。
是阿籬～
“阿籬，你能聽到我說話嗎？”
“犬夜叉，我能聽到，沒想到還能看到你”，阿籬的虛影說到。
“我想你了，阿籬...”
故事End
故事結束了。
再幫大家理一下故事梗概，其實也就是Binder的工作流程：
- 阿籬（服務端） 為了讓犬夜叉（客戶端） 找到她，在四魂之玉（ServiceManager） 上留下了他們世界（進程） 的地址。
- 犬夜叉在第0街道（句柄為0） 找到了四魂之玉碎片（ServiceManager代理）。
- 通過四魂之玉碎片，犬夜叉看到了阿籬的虛影（服務端代理），並通過虛影告訴了阿籬，想她了（通信）。
當然，故事畢竟是故事，並不能完全說清楚。
所以下面就完整看看Binder的工作流程和原理～
代碼實現犬夜叉的需求
首先，我們使用AIDL來實現剛才故事中的場景——讓犬夜叉和阿籬兩個不同進程的人說上話：
//IMsgManager.aidl
interface IMsgManager {
String getMsg();
void tell(in String msg);
}
//阿籬
public class AliWorldService extends Service {
private static final String TAG = "lz1";
@Nullable
@Override
public IBinder onBind(Intent intent) {
return mBinder;
}
private Binder mBinder = new IMsgManager.Stub() {
@Override
public String getMsg() throws RemoteException {
String tellMsg="犬夜叉...是我";
Log.e(TAG, "阿籬：" + tellMsg);
return tellMsg;
}
@Override
public void tell(String msg) throws RemoteException {
Log.e(TAG, "我是阿籬，我收到了你說的:" + msg);
}
};
}
<service
android:name=".binder.AliWorldService"
android:process=":aliworld">
</service>
//犬夜叉
public class QycWorldActivity extends Activity {
private static final String TAG = "lz1";
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_qyc);
Intent i = new Intent(this, AliWorldService.class);
bindService(i, mConnection, Context.BIND_AUTO_CREATE);
}
private ServiceConnection mConnection = new ServiceConnection() {
@Override
public void onServiceConnected(ComponentName name, IBinder service) {
IMsgManager msgManager = IMsgManager.Stub.asInterface(service);
try {
String tellMsg="阿籬，是你嗎";
Log.e(TAG, "犬夜叉：" + tellMsg);
msgManager.tell(tellMsg);
String msg = msgManager.getMsg();
Log.e(TAG, "我是犬夜叉，我收到了你說的：" + msg);
} catch (RemoteException e) {
e.printStackTrace();
}
}
@Override
public void onServiceDisconnected(ComponentName name) {
}
};
@Override
protected void onDestroy() {
super.onDestroy();
unbindService(mConnection);
}
}
運行，打印結果：
E/lz1: 犬夜叉：阿籬，是你嗎
E/lz1: 我是阿籬，我收到了你說的：阿籬，是你嗎
E/lz1: 阿籬：犬夜叉...是我
E/lz1: 我是犬夜叉，我收到了你說的：犬夜叉...是我
AIDL原理
代碼比較簡單，服務器端新建一個Binder對象並傳到onBind方法中，客戶端bindservice之后，獲取到服務端的代理接口，就可以進行方法的調用了。
AIDL其實只是一個幫助我們實現進程間通信的工具，它會根據我們寫的AIDL文件代碼，生成相應的java接口代碼，其內部也是通過Binder實現的。
我們可以通過build——generated——aidl_source_output_dir——debug——out文件路徑找到AIDL為我們生成的接口類。代碼如下：
public interface IMsgManager extends android.os.IInterface {
public static abstract class Stub extends android.os.Binder implements com.example.studynote.binder.IMsgManager {
//1
private static final java.lang.String DESCRIPTOR = "com.example.studynote.binder.IMsgManager";
public Stub() {
this.attachInterface(this, DESCRIPTOR);
}
//2
public static com.example.studynote.binder.IMsgManager asInterface(android.os.IBinder obj) {
if ((obj == null)) {
return null;
}
android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
if (((iin != null) && (iin instanceof com.example.studynote.binder.IMsgManager))) {
return ((com.example.studynote.binder.IMsgManager) iin);
}
return new com.example.studynote.binder.IMsgManager.Stub.Proxy(obj);
}
@Override
public android.os.IBinder asBinder() {
return this;
}
//4
@Override
public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException {
java.lang.String descriptor = DESCRIPTOR;
switch (code) {
case INTERFACE_TRANSACTION: {
reply.writeString(descriptor);
return true;
}
case TRANSACTION_getMsg: {
data.enforceInterface(descriptor);
java.lang.String _result = this.getMsg();
reply.writeNoException();
reply.writeString(_result);
return true;
}
case TRANSACTION_tell: {
data.enforceInterface(descriptor);
java.lang.String _arg0;
_arg0 = data.readString();
this.tell(_arg0);
reply.writeNoException();
return true;
}
default: {
return super.onTransact(code, data, reply, flags);
}
}
}
private static class Proxy implements com.example.studynote.binder.IMsgManager {
private android.os.IBinder mRemote;
Proxy(android.os.IBinder remote) {
mRemote = remote;
}
@Override
public android.os.IBinder asBinder() {
return mRemote;
}
public java.lang.String getInterfaceDescriptor() {
return DESCRIPTOR;
}
//3
@Override
public java.lang.String getMsg() throws android.os.RemoteException {
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
java.lang.String _result;
try {
_data.writeInterfaceToken(DESCRIPTOR);
mRemote.transact(Stub.TRANSACTION_getMsg, _data, _reply, 0);
_reply.readException();
_result = _reply.readString();
} finally {
_reply.recycle();
_data.recycle();
}
return _result;
}
@Override
public void tell(java.lang.String msg) throws android.os.RemoteException {
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
try {
_data.writeInterfaceToken(DESCRIPTOR);
_data.writeString(msg);
mRemote.transact(Stub.TRANSACTION_tell, _data, _reply, 0);
_reply.readException();
} finally {
_reply.recycle();
_data.recycle();
}
}
}
static final int TRANSACTION_getMsg = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0);
static final int TRANSACTION_tell = (android.os.IBinder.FIRST_CALL_TRANSACTION + 1);
}
public java.lang.String getMsg() throws android.os.RemoteException;
public void tell(java.lang.String msg) throws android.os.RemoteException;
}
代碼比較長，我們依次來分析下：
DESCRIPTOR。Binder的唯一標示。
在Stub類的構造方法中，就是通過attachInterface方法將當前的Binder和這個唯一標示進行了綁定。
asInterface()。將服務端的Binder對象轉換成客戶端所需的接口類型對象。
這個方法是客戶端調用的，在這個方法中，會通過queryLocalInterface(DESCRIPTOR)方法，傳入唯一標示，來獲取對應的Binder。
如果是服務端和客戶端在同一個進程，那么就會返回服務端的Binder對象，也就是Stub對象本身，然后就直接調用對象的方法了。
如果在不同進程，也就是我們一般的跨進程情況，就會返回封裝后的Stub.Proxy這個代理對象。
Proxy.getMsg/tell
接着就看看代理類里面的方法，也就是我們在客戶端（Activity）中實際調用的方法。
這其中有兩個比較重要的對象 :_data對象和 _reply對象，都是Parcel類型的，這里會對數據進行一個序列化操作，這樣才能進行跨進程傳輸。
如果方法傳有參數，就會把參數寫到_data對象，然后調用transact方法發起遠程調用請求（RPC），同時當前線程掛起，等待服務端執行完請求。
mRemote.transact(Stub.TRANSACTION_getMsg, _data, _reply, 0);
可以看到，傳入了一個int類型的code——TRANSACTION_getMsg，這個code其實就是為了要確定調用的是哪個方法。
等請求結束后，當前線程繼續，會從_reply對象中取出返回結果。
整個IPC流程就結束了。那服務器到底是在哪里進行任務執行的呢？繼續看onTransact方法。
onTransact
onTransact方法就是服務端要做的事了，運行在服務端的Binder線程池中。
當客戶端發起遠程調用請求后，會通過系統底層封裝，其實也就是內核層的Binder驅動，然后交給服務端的onTransact方法。
在該方法中，首先通過code知曉是哪個方法，然后就執行目標方法，並將序列化結果寫到reply中，RPC過程結束，交給客戶端處理。
case TRANSACTION_getMsg: {
data.enforceInterface(descriptor);
java.lang.String _result = this.getMsg();
reply.writeNoException();
reply.writeString(_result);
return true;
}
最后畫張圖總結下AIDL整個流程：
Binder
經過了上述AIDL的例子，大家是不是對Binder又進一步了解了呢？
在java層面，其實Binder就是一個實現了IBinder接口的類。
真正跨進程的部分還是在客戶端發起遠程調用請求之后，系統底層封裝好，交給服務端的時候。而這個系統底層封裝，其實就是發生在Linux內核中。
而在內核中完成這個通信關鍵功能的還是Binder，這次不是Binder類了，而是Binder驅動。
驅動你可以理解為一種硬件接口，可以幫助操作系統來控制硬件設備。
Binder驅動被添加運行到Linux內核空間，這樣，兩個不同進程就可以通過訪問內核空間來完成數據交換：把數據傳給Binder驅動，然后處理好再交給對方進程,完成跨進程通信。
而剛才通過AIDL的例子我們可以知道，客戶端在請求服務端通信的時候，並不是直接和服務端的某個對象聯系，而是用到了服務端的一個代理對象，通過對這個代理對象操作，然后代理類會把方法對應的code、傳輸的序列化數據、需要返回的序列化數據交給底層，也就是Binder驅動。（這也解釋了為什么犬夜叉看到的是阿籬的虛影，而不是真身😝）
然后Binder驅動把對應的數據交給服務器端，等結果計算好之后，再由Binder驅動把數據返回給客戶端。
ServiceManager
到這里，可能就會有朋友會發現有點不對勁，剛才不是說還有個ServiceManager嗎？這里AIDL通信中咋沒有呢，漏了啊？？
ServiceManager其實是為了管理系統服務而設置的一種機制，每個服務注冊在ServiceManager中，由ServiceManager統一管理，我們可以通過服務名在ServiceManager中查詢對應的服務代理，從而完成調用系統服務的功能。所以ServiceManager有點類似於DNS，可以把服務名稱和具體的服務記錄在案，供客戶端來查找。
在我們這個AIDL的案例中，能直接獲取到服務端的Service，也就直接能獲取到服務端的代理類IMsgManager，所以就無需通過ServiceManager這一層來尋找服務了。
而且ServiceManager本身也運行在一個單獨的進程，所以它本身也是一個服務端，客戶端其實是先通過跨進程獲取到ServiceManager的代理對象，然后通過ServiceManager代理對象再去找到對應的服務。
而ServiceManager就像我們剛才AIDL中的Service一樣，是可以直接找到的，他的句柄永遠是0，是一個“眾所周知”的句柄，所以每個APP程序都可以通過binder機制在自己的進程空間中創建一個ServiceManager代理對象。
（這也解釋了為什么四魂之玉在另外一個世界，其實就在另外一個進程，我們只能通過句柄值為0找到四魂之玉的碎片，其實也就是代理😝）
所以通過ServiceManager查找系統服務並調用方法的過程是進行了兩次跨進程通信。
APP進程——>ServiceManager進程——>系統服務進程（比如AactivityManagerService）
下面我們就拿ActivityManagerService舉例看看怎么通過ServeiceManager獲取到系統服務。
系統服務通信舉例
熟悉APP啟動流程的朋友都知道，startActivityForResult方法會轉到mInstrumentation.execStartActivity方法中，而這里獲取AMS服務的過程就用到了Binder機制:
//mInstrumentation.execStartActivity
int result = ActivityManager.getService()
.startActivity(whoThread, who.getBasePackageName(), intent,
intent.resolveTypeIfNeeded(who.getContentResolver()),
token, target != null ? target.mEmbeddedID : null,
requestCode, 0, null, options);
checkStartActivityResult(result, intent);
public static IActivityManager getService() {
return IActivityManagerSingleton.get();
}
private static final Singleton<IActivityManager> IActivityManagerSingleton =
new Singleton<IActivityManager>() {
@Override
protected IActivityManager create() {
final IBinder b = ServiceManager.getService(Context.ACTIVITY_SERVICE);
final IActivityManager am = IActivityManager.Stub.asInterface(b);
return am;
}
};
主要看這一句：ServiceManager.getService(Context.ACTIVITY_SERVICE)
這不就是ServiceManager嗎，按照我們之前理解的那樣，這里傳入了一個name——Context.ACTIVITY_SERVICE，然后就能獲取到對應服務的代理類，也就是IBinder對象，這里也就是對應的AMS的代理對象——IActivityManager。
然后就可以對AMS進行一系列操作了。
這里的AMS服務其實對應的服務端，而我們調用的一方也就是APP本身的進程，就作為客戶端。
剩下的問題就是，AMS是什么時候注冊到ServiceManager的呢？答案在SystemServer中，之前的文章中說過，AMS的啟動是在SystemServer中完成的，其實啟動的同時也完成了在ServiceManager中的注冊，這里貼下AMS的啟動和注冊服務代碼，不熟悉的朋友可以翻翻SystemServer的源碼或者我之前的文章。
//SystemServer.java
private void startBootstrapServices() {
//...
//啟動AMS
mActivityManagerService = mSystemServiceManager.startService(
ActivityManagerService.Lifecycle.class).getService();
mActivityManagerService.setSystemServiceManager(mSystemServiceManager);
mActivityManagerService.setInstaller(installer);
//為系統進程設置應用程序實例並啟動。
mActivityManagerService.setSystemProcess();
}
public void setSystemProcess() {
try {
ServiceManager.addService(Context.ACTIVITY_SERVICE, this, /* allowIsolated= */ true,
DUMP_FLAG_PRIORITY_CRITICAL | DUMP_FLAG_PRIORITY_NORMAL | DUMP_FLAG_PROTO);
}
}
到此，完整的Binder流程也介紹完了，再補一張Binder機制的流程圖：
總結
所以Binder到底是什么呢？我想你心里已經有了答案，這里借用《Android開發藝術探索》書中的內容總結下，希望大家好好回味下～
直觀的說，Binder是一個類，實現了IBinder接口。
從IPC（進程間通信）角度來說，Binder是Android中一種跨進程通信方式。
還可以理解為一種虛擬的物理設備，它的設備驅動是/dev/binder。
從Android FrameWork角度來說，Binder是ServiceManager連接各種Manager（ActivityManager，WindowManager等等）和響應ManagerService的橋梁。
從Android應用層來說，Binder是客戶端和服務端進行通信的媒介。
Android體系架構
參考
《Android開發藝術探索》
Binder學習指南
Android進程間通信（IPC）機制Binder簡要介紹和學習計划
Android系統的Binder機制之一——Service Manager
拜拜
有一起學習的小伙伴可以關注下❤️ 我的公眾號——碼上積木，每天剖析一個知識點，我們一起積累知識，形成完整體系架構。公眾號回復111可獲得面試題《思考與解答》以往期刊。
