Binder的示例分析

小編給大家分享一下Binder的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

1、為什么是Binder?

1.1 傳統(tǒng)IPC機制的缺點

大家都知道Android系統(tǒng)是基于Linux內(nèi)核實現(xiàn)的，Linux已經(jīng)提供了多種進程間通信機制，比如：管道、消息隊列、共享內(nèi)存和套接字(Socket)等等，為什么還要再實現(xiàn)一套IPC機制呢?主要是基于兩方面的原因：

1.1.1 性能角度

管道、消息隊列、Socket實現(xiàn)一次進程通信都需要2次內(nèi)存拷貝，效率太低;共享內(nèi)存雖然不需要拷貝內(nèi)存，但管理復(fù)雜;Binder只需要一次內(nèi)存拷貝，從性能角度來看，低于共享內(nèi)存方式，優(yōu)于其它方式。

1.1.2 安全性考慮

傳統(tǒng)的IPC機制沒有安全措施，接收方無法獲得對方可靠的進程ID或用戶ID，完全靠上層的協(xié)議來保護，比如Socket通信的IP地址是客戶端填入的，很可能被惡意程序篡改。Android作為面向終端用戶的開源平臺，應(yīng)用市場中有海量的應(yīng)用供用戶選擇，因此安全性極為重要。Android系統(tǒng)為每個已安裝的App都分配了用戶ID(UID)，UID是鑒別進程身份的重要標識，通過UID可以進行一系列的權(quán)限校驗。另一方面  ，傳統(tǒng)IPC的接入點是開放的，任何程序都可以根據(jù)協(xié)議進行訪問，無法阻止惡意程序的訪問，Android需要一種基于C/S架構(gòu)的IPC機制，Server端需要能夠?qū)lient的請求進行身份校驗，來保證數(shù)據(jù)的安全性。

1.2 Linux的一些基本知識

要知道Binder是如何只用一次內(nèi)存拷貝即實現(xiàn)跨進程通信的，首先需要弄清楚為什么傳統(tǒng)IPC機制為什么需要兩次內(nèi)存拷貝，這就需要先了解一些操作系統(tǒng)的基礎(chǔ)知識。

1.2.1 進程隔離

先來看一下維基百科對“進程隔離”的定義：

進程隔離是為保護操作系統(tǒng)中進程互不干擾而設(shè)計的一組不同硬件和軟件的技術(shù)。這個技術(shù)是為了避免進程A寫入進程B的情況發(fā)生。  進程的隔離實現(xiàn)，使用了虛擬地址空間。進程A的虛擬地址和進程B的虛擬地址不同，這樣就防止進程A將數(shù)據(jù)信息寫入進程B。

也就是說，進程之間的數(shù)據(jù)是不共享的，A進程無法直接訪問B進程的數(shù)據(jù)，以此來保證數(shù)據(jù)的安全性。在進程隔離的操作系統(tǒng)中，進程之間的交互必須通過IPC機制。

進程隔離的實現(xiàn)使用了虛擬地址空間，什么是虛擬地址空間呢?首先需要了解操作系統(tǒng)中的虛擬內(nèi)存概念，它是一種提高編程效率和提高物理內(nèi)存利用效率的一種技術(shù)。簡單來說，就是應(yīng)用程序看到了都一片連續(xù)完整的內(nèi)存地址空間，而實際上這些地壇空間是映射到碎片化的物理內(nèi)存中的，這個映射的過程對應(yīng)用程序來說是透明的。這個概念很重要，對于虛擬內(nèi)存更深入的理解可以參考這篇文章：Linux  虛擬內(nèi)存和物理內(nèi)存的理解

1.2.2 進程空間：用戶空間/內(nèi)核空間

現(xiàn)在的操作系統(tǒng)都采用虛擬內(nèi)存，對32位的操作系統(tǒng)而言，尋址空間是2的32次方，即4G。操作系統(tǒng)的核心是內(nèi)核，內(nèi)核擁有對底層設(shè)備的所有訪問權(quán)限，因此需要和普通的應(yīng)用程序獨立開來，用戶進程不能直接訪問內(nèi)核進程。操作系統(tǒng)從邏輯上把虛擬地址空間劃分為用戶空間(User  Space)和內(nèi)核空間(Kernel  Space)。在32位的Linux操作系統(tǒng)中，將高位的1GB字節(jié)供內(nèi)核使用，稱之為內(nèi)核空間;剩下的3GB字節(jié)供用戶進程使用，稱之為用戶空間。

1.2.3 系統(tǒng)調(diào)用：用戶態(tài)/內(nèi)核態(tài)

因為用戶空間的權(quán)限低于內(nèi)核空間，不可避免用戶空間需要訪問內(nèi)核空間的資源，比如讀寫文件和網(wǎng)絡(luò)訪問，如何實現(xiàn)呢?唯一的方式就是通過操作系統(tǒng)提供的系統(tǒng)調(diào)用接口，通過系統(tǒng)調(diào)用接口，用戶程序可以在內(nèi)核的控制下實現(xiàn)對內(nèi)核資源的有限訪問，這樣既能滿足應(yīng)用程序的資源請求，也能保障系統(tǒng)安全和穩(wěn)定。

當(dāng)用戶進程執(zhí)行自己的代碼時，進程當(dāng)前就處于用戶運行態(tài)(用戶態(tài))，此時處理器執(zhí)行用戶代碼，權(quán)限較低;當(dāng)用戶進程通過系統(tǒng)調(diào)用執(zhí)行內(nèi)核代碼時，進程就暫時進入了內(nèi)核運行態(tài)(內(nèi)核態(tài))，此時處理器權(quán)限***，可以執(zhí)行特權(quán)指令。

1.2.4 內(nèi)核模塊/驅(qū)動

前面說了用戶空間可以通過系統(tǒng)調(diào)用訪問內(nèi)核空間，那用戶空間之間(進程間)怎么通信呢?傳統(tǒng)的IPC機制都是通過內(nèi)核來支持的，Binder也一樣，有一個運行在內(nèi)核中的Binder驅(qū)動程序負責(zé)進程之間Binder的通信。

驅(qū)動程序一般指的是設(shè)備驅(qū)動程序(Device Driver)，是一種可以使計算機和設(shè)備通信的特殊程序。相當(dāng)于硬件的接口，操作系統(tǒng)只有通過這個接口。

Binder驅(qū)動是一種虛擬的字符設(shè)備，注冊在/dev/binder中，其定義了一套Binder通信協(xié)議，負責(zé)建立進程間的Binder通信，提供了數(shù)據(jù)包在進程之間傳遞的一系列底層支持。應(yīng)用進程訪問Binder驅(qū)動也是通過系統(tǒng)調(diào)用實現(xiàn)的。

1.3 傳統(tǒng)IPC機制的通信原理

了解了上面的基礎(chǔ)知識后，我們來看看傳統(tǒng)IPC機制是如何實現(xiàn)，通常是下面兩個步驟(共享內(nèi)存機制除外)：

1. 發(fā)送方進程通過系統(tǒng)調(diào)用(copy_from_user)將要發(fā)送的數(shù)據(jù)存拷貝到內(nèi)核緩存區(qū)中。

2. 接收方開辟一段內(nèi)存空間，內(nèi)核通過系統(tǒng)調(diào)用(copy_to_user)將內(nèi)核緩存區(qū)中的數(shù)據(jù)拷貝到接收方的內(nèi)存緩存區(qū)。

這種傳統(tǒng)IPC機制存在2個問題：

1. 需要進行2次數(shù)據(jù)拷貝，第1次是從發(fā)送方用戶空間拷貝到內(nèi)核緩存區(qū)，第2次是從內(nèi)核緩存區(qū)拷貝到接收方用戶空間。

2. 接收方進程不知道事先要分配多大的空間來接收數(shù)據(jù)，可能存在空間上的浪費。

2、Binder的基本原理

2.1 Binder底層原理

傳統(tǒng)IPC機制需要拷貝2次內(nèi)存，Binder是如何只用1次內(nèi)存拷貝就實現(xiàn)進程間通信的呢?前面我們已經(jīng)了解到，Linux是使用的是虛擬內(nèi)存尋址方式，用戶空間的虛擬內(nèi)存地址是映射到物理內(nèi)存中的，對虛擬內(nèi)存的讀寫實際上是對物理內(nèi)存的讀寫，這個過程就是內(nèi)存映射，這個內(nèi)存映射過程是通過系統(tǒng)調(diào)用mmap()來實現(xiàn)的。

Binder借助了內(nèi)存映射的方法，在內(nèi)核空間和接收方用戶空間的數(shù)據(jù)緩存區(qū)之間做了一層內(nèi)存映射。這樣一來，從發(fā)送方用戶空間拷貝到內(nèi)核空間緩存區(qū)的數(shù)據(jù)，就相當(dāng)于直接拷貝到了接收方用戶空間的數(shù)據(jù)緩存區(qū)，從而減少了一次數(shù)據(jù)拷貝。

2.2 Binder通信模型

Binder是基于C/S架構(gòu)的，對于通信雙方來說，發(fā)起請求的進程屬于Client，接收請求的進程屬于Server，由于存在進程隔離，雙方不能直接通信，Binder是如何實現(xiàn)的呢?

寫給 Android 應(yīng)用工程師的 Binder  原理剖析中舉的網(wǎng)絡(luò)通信例子很貼切，Binder的通信過程與網(wǎng)絡(luò)請求類似，網(wǎng)絡(luò)通信過程可以簡化為4個角色：Client、Server、DNS服務(wù)器和路由器。一次完整的網(wǎng)絡(luò)通信大體過程如下：

a、Client輸入Server的域名

b、DNS解析域名

通過域名是無法直接找到相應(yīng)Server的，必須先通過DNS服務(wù)器將Server的域名轉(zhuǎn)化為具體的IP地址。

c、通過路由器將請求發(fā)送至Server

Client通過DNS服務(wù)器解析到Server的IP地址后，也還不能直接向Server發(fā)起請求，需要經(jīng)過路由器的層層中轉(zhuǎn)才還到達Server。

d、Server返回數(shù)據(jù)

Server接收到請求并處理后，再通過路由器將數(shù)據(jù)返回給Client。

在Binder機制中，也定義了4個角色：Client、Server、Binder驅(qū)動和ServiceManager。

Binder驅(qū)動：類似網(wǎng)絡(luò)通信中的路由器，負責(zé)將Client的請求轉(zhuǎn)發(fā)到具體的Server中執(zhí)行，并將Server返回的數(shù)據(jù)傳回給Client。

ServiceManager：類似網(wǎng)絡(luò)通信中的DNS服務(wù)器，負責(zé)將Client請求的Binder描述符轉(zhuǎn)化為具體的Server地址，以便Binder驅(qū)動能夠轉(zhuǎn)發(fā)給具體的Server。Server如需提供Binder服務(wù)，需要向ServiceManager注冊。

具體的通信過程是這樣的：

a、Server向ServiceManager注冊

Server通過Binder驅(qū)動向ServiceManager注冊，聲明可以對外提供服務(wù)。ServiceManager中會保留一份映射表：名字為zhangsan的Server對應(yīng)的Binder引用是0x12345。

b、Client向ServiceManager請求Server的Binder引用

Client想要請求Server的數(shù)據(jù)時，需要先通過Binder驅(qū)動向ServiceManager請求Server的Binder引用：我要向名字為zhangsan的Server通信，請告訴我Server的Binder引用。

c、向具體的Server發(fā)送請求

Client拿到這個Binder引用后，就可以通過Binder驅(qū)動和Server進行通信了。

d、Server返回結(jié)果

Server響應(yīng)請求后，需要再次通過Binder驅(qū)動將結(jié)果返回給Client。

可以看到，Client、Server、ServiceManager之間的通信都是通過Binder驅(qū)動作為橋梁的，可見Binder驅(qū)動的重要性。也許你還有一點疑問，ServiceManager和Binder驅(qū)動屬于兩個不同的進程，它們是為Client和Server之間的進程間通信服務(wù)的，也就是說Client和Server之間的進程間通信依賴ServiceManager和Binder驅(qū)動之間的進程間通信，這就像是：“蛋生雞，雞生蛋，但***個蛋得通過一只雞孵出來”。Binder機制是如何創(chuàng)造***只下蛋的雞呢?

1. 當(dāng)Android系統(tǒng)啟動后，會創(chuàng)建一個名稱為servicemanager的進程，這個進程通過一個約定的命令BINDERSETCONTEXT_MGR向Binder驅(qū)動注冊，申請成為為ServiceManager，Binder驅(qū)動會自動為ServiceManager創(chuàng)建一個Binder實體(***只下蛋的雞);

2. 并且這個Binder實體的引用在所有的Client中都為0，也就說各個Client通過這個0號引用就可以和ServiceManager進行通信。Server通過0號引用向ServiceManager進行注冊，Client通過0號引用就可以獲取到要通信的Server的Binder引用。

Android Binder設(shè)計與實現(xiàn) - 設(shè)計篇中對Client、Server、Binder驅(qū)動和ServiceManager有更詳細的介紹。

2.3 Binder的代理機制

通過上面的分析，我們已經(jīng)知道了Binder的基本通信過程：Client向SerivceManger獲取到Server的Binder引用，Client通過Binder引用向Server發(fā)起具體請求。Client通過這個Binder引用具體是如何調(diào)用Server方法的呢?

比如一個Server提供add方法，Client實際請求add的流程是這樣的：Client先通過Binder驅(qū)動向ServiceManager獲取Server的Binder引用，這個引用就是一個Java  Object，這個Object有一個add方法;Cient拿到這個Object后就可以直接請求add方法了。

實際上Client拿到的Object并不是Server真正的Binder實體，Binder驅(qū)動做了一層對象轉(zhuǎn)換，將這個Object包裝成了一個代理對象ProxyObject，這個ProxyObject和真正的Binder實體有相同的方法簽名，Client通過這個ProxyObject請求add方法時，Binder驅(qū)動會自動將請求轉(zhuǎn)發(fā)到具體的Binder實體中執(zhí)行，這就是Binder的代理機制。由于ProxyObject和真正的Binder實體有相同的方法簽名，其實Client并不需要關(guān)心是ProxyObject還是真實的Object。

為了方便描述，下面將Server真正的Binder實體稱為Binder本地對象;將Client中的Binder引用，即ProxyObject，稱之為Binder代理對象。

2.4 對Binder概念的重新理解

經(jīng)過上面的分析，我們已經(jīng)大體清楚了Binder機制的基本通信原理，現(xiàn)在回過頭來重新梳理下對Binder機制的認識：

總體來說，Binder是基于C/S結(jié)構(gòu)的一種面向?qū)ο蟮腎PC機制。包含：Client、Server、Binder驅(qū)動和ServiceManager四大組成部分。各組成部分中的Binder含義都有所有不同：

• 對于Client

Binder是Server本地對象的一個引用，這個引用實際上是一個代理對象，Client通過這個代理對象來間接訪問Server的本地對象;

• 對于Server

Binder是提供具體實現(xiàn)的本地對象，需向ServiceManager注冊;

• 對于Binder驅(qū)動

它是連接Client來Server的橋梁，負責(zé)將代理對象轉(zhuǎn)化為本地對象，并將Server的執(zhí)行結(jié)果返回給Client。

• 對于ServiceManager

它保存了Server Binder字符名稱和Binder引用的映射，Client通過它來找到Server的Binder引用。

Binder驅(qū)動中保留了Binder代理對象和Binder本地對象的具體結(jié)構(gòu)，由于我們只關(guān)心Binder的基本通信機制，底層實現(xiàn)不做過多介紹，想具體了解的同學(xué)可以參考Android  Binder設(shè)計與實現(xiàn) - 設(shè)計篇。

3、通過代碼來理解Binder

上面的介紹比較抽象，現(xiàn)在我們通過具體實例來理解Binder。

• 通過AIDL實例來了解Binder的用法

• 通過手動編碼實現(xiàn)ActivityManagerService

3.1 通過AIDL實例來了解Binder的用法

實現(xiàn)Binder通信的最常用方法就是通過aidl，aidl接口定義了Client和Server進行通信的接口，對aidl不了解的同學(xué)請參考官方文檔Android  接口定義語言 (AIDL)。

3.1.1 與Binder相關(guān)的幾個類的職責(zé)

在具體分析之前，我們需要先了解與Binder相關(guān)的幾個類的職責(zé)：

• IBinder

跨進程通信的Base接口，它聲明了跨進程通信需要實現(xiàn)的一系列抽象方法，實現(xiàn)了這個接口就說明可以進行跨進程通信，Client和Server都要實現(xiàn)此接口。

• IInterface

這也是一個Base接口，用來表示Server提供了哪些能力，是Client和Server通信的協(xié)議。

• Binder

提供Binder服務(wù)的本地對象的基類，它實現(xiàn)了IBinder接口，所有本地對象都要繼承這個類。

• BinderProxy

在Binder.java這個文件中還定義了一個BinderProxy類，這個類表示Binder代理對象它同樣實現(xiàn)了IBinder接口，不過它的很多實現(xiàn)都交由native層處理。Client中拿到的實際上是這個代理對象。

• Stub

這個類在編譯aidl文件后自動生成，它繼承自Binder，表示它是一個Binder本地對象;它是一個抽象類，實現(xiàn)了IInterface接口，表明它的子類需要實現(xiàn)Server將要提供的具體能力(即aidl文件中聲明的方法)。

• Proxy

它實現(xiàn)了IInterface接口，說明它是Binder通信過程的一部分;它實現(xiàn)了aidl中聲明的方法，但最終還是交由其中的mRemote成員來處理，說明它是一個代理對象，mRemote成員實際上就是BinderProxy。

3.1.2 AIDL實例

首先定義一個aidl文件，這個接口中聲明了一個getPid方法：

// IRemoteService.aidl package com.rush.demo.aidltest;  interface IRemoteService {     int getPid(); }

下面是編譯IRemoteService.aild后生成的java類：

// IRemoteService.java package com.rush.demo.aidltest;  public interface IRemoteService extends android.os.IInterface {     public static abstract class Stub extends android.os.Binder implements com.rush.demo.aidltest.IRemoteService {         //Binder描述符         private static final java.lang.String DESCRIPTOR = "com.rush.demo.aidltest.IRemoteService";          public Stub() {             this.attachInterface(this, DESCRIPTOR);         }          public static com.rush.demo.aidltest.IRemoteService asInterface(android.os.IBinder obj) {             if ((obj == null)) {                 return null;             }             android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);             if (((iin != null) && (iin instanceof com.rush.demo.aidltest.IRemoteService))) {                 return ((com.rush.demo.aidltest.IRemoteService) iin);             }             return new com.rush.demo.aidltest.IRemoteService.Stub.Proxy(obj);         }          @Override         public android.os.IBinder asBinder() {             return this;         }          @Override         public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException {             switch (code) {                 case INTERFACE_TRANSACTION: {                     reply.writeString(DESCRIPTOR);                     return true;                 }                 case TRANSACTION_getPid: {                     data.enforceInterface(DESCRIPTOR);                     java.lang.String _arg0;                     _arg0 = data.readString();                     int _result = this.getPid(_arg0);                     reply.writeNoException();                     reply.writeInt(_result);                     return true;                 }             }             return super.onTransact(code, data, reply, flags);         }          private static class Proxy implements com.rush.demo.aidltest.IRemoteService {             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;             }              @Override             public int getPid(java.lang.String name) throws android.os.RemoteException {                 android.os.Parcel _data = android.os.Parcel.obtain();                 android.os.Parcel _reply = android.os.Parcel.obtain();                 int _result;                 try {                     _data.writeInterfaceToken(DESCRIPTOR);                     _data.writeString(name);                     mRemote.transact(Stub.TRANSACTION_getPid, _data, _reply, 0);                     _reply.readException();                     _result = _reply.readInt();                 } finally {                     _reply.recycle();                     _data.recycle();                 }                 return _result;             }          static final int TRANSACTION_getPid = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0);     }      public int getPid(java.lang.String name) throws android.os.RemoteException; }

這個文件中有3個類：

a、IRemoteService

繼承至IInterface接口，聲明了IRemoteService.aidl中聲明的getPid方法，它是Client和Service通信的接口。

b、IRemoteService.Stub

IRemoteService的靜態(tài)抽象內(nèi)部類，繼承自Binder，其子類需要實現(xiàn)IRemoteService接口，表明它是Server的Binder本地對象，需要實現(xiàn)getPid接口。

c、IRemoteService.Stub.Proxy

IRemoteService.Stub的靜態(tài)內(nèi)部類，它并沒有繼承自Binder，而是包含了一個IBinder對象，這個對象其實是BinderProxy，說明它是Server在Client中的本地代理對象。Proxy實現(xiàn)了getPid接口，將參數(shù)序列化后交由mRemote(BinderProxy)處理，實際上就是交給Binder驅(qū)動來完成與遠程Stub的通信。

先來看Stub中的asInterface方法，這個方法通常是Client在bindService成功后，由Client來調(diào)用的，作用是將綁定成功后返回的IBinder對象轉(zhuǎn)換為具體的IInterface接口，Client拿到這個IInterface接口后就可以和自由的調(diào)用Server提供的方法了。

public static com.rush.demo.aidltest.IRemoteService asInterface(android.os.IBinder obj) {     if ((obj == null)) {         return null;     }     android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);     if (((iin != null) && (iin instanceof com.rush.demo.aidltest.IRemoteService))) {         return ((com.rush.demo.aidltest.IRemoteService) iin);     }     return new com.rush.demo.aidltest.IRemoteService.Stub.Proxy(obj); }

asInterface方法中既可能返回Stub本身的IRemoteService對象，也可能創(chuàng)建一個Proxy對象，這是為什么呢?因為Binder雖然是跨進程通信機制，但也可以為本進程服務(wù)，也就是說Client和Server可能在同一個進程，在同一個進程就沒必要通過Binder驅(qū)動來中轉(zhuǎn)了，直接訪問就可以了;如果Client和Server在不同的進程，就需要通過Binder代理對象來中轉(zhuǎn)。也就是說：

1. Client和Server在同一個進程，obj是Binder本地對象(Stub的子類)，asInterface方法返回的就是Binder本地對象;

2. Client和Server在不同的進程，obj實際上是Binder代理對象，asInterface返回一個Proxy對象。

//Binder.java /**  * obj.queryLocalInterface是怎樣去查找是否有本地的IInterface呢，從Binder的代碼中可以看到，只是簡單的比較Binder的描述符和要查找的描述符是否匹配，匹配的話直接返回mOwner，這個mOwner就是Stub構(gòu)造方法中調(diào)用attachInterface方法傳入的this參數(shù)。  */ public IInterface queryLocalInterface(String descriptor) {     if (mDescriptor.equals(descriptor)) {         return mOwner;     }     return null; }  final class BinderProxy implements IBinder {     public IInterface queryLocalInterface(String descriptor) {         return null;     } }  public static abstract class Stub extends android.os.Binder implements com.rush.demo.aidltest.IRemoteService {     // Binder描述符，值為接口類名全稱     private static final java.lang.String DESCRIPTOR = "com.rush.demo.aidltest.IRemoteService";      public Stub() {         //向Binder中綁定owner和descriptor         this.attachInterface(this, DESCRIPTOR);     } }

obj.queryLocalInterface是怎樣去查找是否有本地的IInterface呢，從Binder的代碼中可以看到，只是簡單的比較Binder的描述符和要查找的描述符是否匹配，匹配的話直接返回mOwner，這個mOwner就是Stub構(gòu)造方法中調(diào)用attachInterface方法傳入的this參數(shù)。而BinderProxy的queryLocalInterface方法直接返回null。

Client中通過Binder調(diào)用Server方法有兩種場景：

1、Client和Server在同一個進程

Stub.asInterface方法返回的是Stub對象，即Binder本地對象。也就是說和Binder跨進程通信無關(guān)，直接調(diào)用即可，此時Client調(diào)用方和Server響應(yīng)方在同一個線程中。

2、Client和Server在不同的進程

Stub.asInterface方法返回的是Binder代理對象，需要通過Binder驅(qū)動完成跨進程通信。這種場景下，Client調(diào)用方線程會被掛起(Binder也提供了異步的方式，這里不討論)，等待Server響應(yīng)后返回數(shù)據(jù)。這里要注意的是，Server的響應(yīng)是在Server進程的Binder線程池中處理的，并不是主線程。

接下來分析跨進程場景下，Client調(diào)用getPid方法的具體流程：

1、Client調(diào)用Binder代理對象，Client線程掛起

Client中拿到的IRemoteService引用實際上是Proxy，調(diào)用getPid方法實際上是調(diào)用Proxy的getPid方法，這個方法只是將參數(shù)序列化后，調(diào)用了mRemote成員的transact方法。Stub類中為IRemoteService中的每個方法定義了方法編號，transact方法中傳入getPid方法的編號。此時Client調(diào)用方線程掛起，等待Server響應(yīng)數(shù)據(jù)。

// Stub.Proxy public int getPid(java.lang.String name) throws android.os.RemoteException {     ...     _data.writeInterfaceToken(DESCRIPTOR);     _data.writeString(name);     mRemote.transact(Stub.TRANSACTION_getPid, _data, _reply, 0);     _reply.readException();     _result = _reply.readInt();     ...     return _result; }

2、Binder代理對象將請求派發(fā)給Binder驅(qū)動

Proxy中的mRemote成員實際上是BinderProxy，而BinderProxy中的transact方法最終調(diào)用于transactNative方法，也就是說Client的請求派發(fā)給了Binder驅(qū)動來處理。

3、Binder驅(qū)動將請求派發(fā)給Server

Binder驅(qū)動經(jīng)過一系列的處理后，將請求派發(fā)給了Server，即調(diào)用Server本地Binder對象(Stub)的onTransact方法最終在此方法中完成getPid方法的具體調(diào)用。在onTransact方法中，根據(jù)Proxy中調(diào)用transact時傳入的方法編號來區(qū)別具體要處理的方法。

// Stub public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException {     switch (code) {         ...         case TRANSACTION_getPid: {             data.enforceInterface(DESCRIPTOR);             //獲取方法參數(shù)             java.lang.String _arg0 = data.readString();             //調(diào)用getPid方法，這個方法在Stub的子類，即Server中實現(xiàn)             int _result = this.getPid(_arg0);             reply.writeNoException();             reply.writeInt(_result);             return true;         }     }     return super.onTransact(code, data, reply, flags); }

4、喚醒Client線程，返回結(jié)果

onTransact處理結(jié)束后，將結(jié)果寫入reply并返回至Binder驅(qū)動，驅(qū)動喚醒掛起的Client線程，并將結(jié)果返回。至此，一次跨進程通信完成。

3.2 手動編碼來實現(xiàn)ActivityManagerService

通過前面的示例我們已經(jīng)知道，aidl文件只是用來定義C/S交互的接口，Android在編譯時會自動生成相應(yīng)的Java類，生成的類中包含了Stub和Proxy靜態(tài)內(nèi)部類，用來封裝數(shù)據(jù)轉(zhuǎn)換的過程，實際使用時只關(guān)心具體的Java接口類即可。為什么Stub和Proxy是靜態(tài)內(nèi)部類呢?這其實只是為了將三個類放在一個文件中，提高代碼的聚合性。通過上面的分析，我們其實完全可以不通過aidl，手動編碼來實現(xiàn)Binder的通信，下面我們通過編碼來實現(xiàn)ActivityManagerService。

首先定義IActivityManager接口：

public interface IActivityManager extends IInterface {     //binder描述符     String DESCRIPTOR = "android.app.IActivityManager";     //方法編號     int TRANSACTION_startActivity = IBinder.FIRST_CALL_TRANSACTION + 0;     //聲明一個啟動activity的方法，為了簡化，這里只傳入intent參數(shù)     int startActivity(Intent intent) throws RemoteException; }

其次，實現(xiàn)ActivityManagerService側(cè)的本地Binder對象基類：

// 名稱隨意，不一致叫Stub public abstract class ActivityManagerNative extends Binder implements IActivityManager {      public static IActivityManager asInterface(IBinder obj) {         if (obj == null) {             return null;         }         IActivityManager in = (IActivityManager) obj.queryLocalInterface(IActivityManager.DESCRIPTOR);         if (in != null) {             return in;         }         //代理對象，見下面的代碼         return new ActivityManagerProxy(obj);     }      @Override     public IBinder asBinder() {         return this;     }      @Override     protected boolean onTransact(int code, Parcel data, Parcel reply, int flags) throws RemoteException {         switch (code) {             // 獲取binder描述符             case INTERFACE_TRANSACTION:                 reply.writeString(IActivityManager.DESCRIPTOR);                 return true;             // 啟動activity，從data中反序列化出intent參數(shù)后，直接調(diào)用子類startActivity方法啟動activity。             case IActivityManager.TRANSACTION_startActivity:                 data.enforceInterface(IActivityManager.DESCRIPTOR);                 Intent intent = Intent.CREATOR.createFromParcel(data);                 int result = this.startActivity(intent);                 reply.writeNoException();                 reply.writeInt(result);                 return true;         }         return super.onTransact(code, data, reply, flags);     } }

再次，實現(xiàn)Client側(cè)的代理對象：

public class ActivityManagerProxy implements IActivityManager {     private IBinder mRemote;      public ActivityManagerProxy(IBinder remote) {         mRemote = remote;     }      @Override     public IBinder asBinder() {         return mRemote;     }      @Override     public int startActivity(Intent intent) throws RemoteException {         Parcel data = Parcel.obtain();         Parcel reply = Parcel.obtain();         int result;         try {             // 將intent參數(shù)序列化，寫入data中             intent.writeToParcel(data, 0);             // 調(diào)用BinderProxy對象的transact方法，交由Binder驅(qū)動處理。             mRemote.transact(IActivityManager.TRANSACTION_startActivity, data, reply, 0);             reply.readException();             // 等待server執(zhí)行結(jié)束后，讀取執(zhí)行結(jié)果             result = reply.readInt();         } finally {             data.recycle();             reply.recycle();         }         return result;     } }

***，實現(xiàn)Binder本地對象(IActivityManager接口)：

public class ActivityManagerService extends ActivityManagerNative {     @Override     public int startActivity(Intent intent) throws RemoteException {         // 啟動activity         return 0;     } }

簡化版的ActivityManagerService到這里就已經(jīng)實現(xiàn)了，剩下就是Client需要獲取到AMS的代理對象IActivityManager就可以通信了。實際開發(fā)過程中通過aidl文件能夠自動編譯出中間代碼，并不需要我們手動去實現(xiàn)，不過手動編碼能夠加深對Binder機制的理解。在開發(fā)過程中我們也并不會直接使用到AMS，但了解AMS實現(xiàn)原理對熟悉Framework來說必不可少。

以上是“Binder的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注億速云行業(yè)資訊頻道！