【原】三步掌握 Android 中的 AIDL

codingSmart 2021-10-22

展開全文

第一步創(chuàng)建 aidl 接口文件

AndroidStudio 中直接右鍵創(chuàng)建，或者自己一步步建目錄嘍。

創(chuàng)建完成后會(huì)生成一個(gè) XXX.aidl接口文件，我們需要根據(jù)需求在這個(gè)接口類中添加接口。

在看接口怎么寫前，先記住以下三點(diǎn)：

支持的參數(shù)類型

八種基本數(shù)據(jù)類型；
String、CharSequence；
List、Map，它們中的數(shù)據(jù)類型也應(yīng)該是AIDL支持的；
實(shí)現(xiàn)Parcelabel的引用類型。

自定義引用類型使用

如果要使用自定義的數(shù)據(jù)類型，需要先為它也生成一個(gè)aidl文件，里面內(nèi)容只需兩行：

AIDL的包名;

parcelable 類名;

例如：

package com.coorchice.coorchicelibone;

parcelable Role;

接著就可以創(chuàng)建對(duì)應(yīng)的java數(shù)據(jù)類了，然后實(shí)現(xiàn)Parcelable接口，注意包名需要和aidl一模一樣！如果你對(duì)自定義類型使用了in或者inout標(biāo)識(shí)符的話，你必須再給自定義類實(shí)現(xiàn) readFromParcel()方法。比如：

public void readFromParcel(Parcel in) {
  name = in.readString();
  skill = in.readString();
}

然后在定義 aidl 接口時(shí)，一定要記得手動(dòng)寫一下自定義引用類的import！

參數(shù)修飾符

in: 表示參數(shù)數(shù)據(jù)只能由客戶端傳遞到服務(wù)端，基本類型就默認(rèn)只支持in修飾符。
out：表示參數(shù)數(shù)據(jù)只能由服務(wù)端傳遞到客戶端。即服務(wù)端如果修改了參數(shù)對(duì)象的值，那么客戶端的值也會(huì)變化，但是服務(wù)端無法讀取到客戶端對(duì)象的值。
inout：表示參數(shù)數(shù)據(jù)能夠雙向傳遞。

定義服務(wù)接口

現(xiàn)在，我們可以開始定義服務(wù)接口了！這里定義的服務(wù)接口就是后面我們需要在客戶端調(diào)用的。

CoorChice 定義了3個(gè)接口，接著編譯一下。然后編譯器會(huì)自動(dòng)根據(jù)我們定義的接口生成對(duì)應(yīng)的類。

注意：自定義的類必須加in、out、inout等標(biāo)識(shí)符，否則會(huì)報(bào)錯(cuò)！

編譯后生成的類解析

編譯之后編譯器自動(dòng)幫我們生成了一個(gè)服務(wù)接口類名.Stub的抽象類，它繼承自 Binder，然后實(shí)現(xiàn)了我們定義的服務(wù)接口（注意我們的服務(wù)接口實(shí)現(xiàn)了IInterface接口）。嗯，重點(diǎn)是它是一個(gè)Binder！它就是我們用來進(jìn)行 Binder 通訊的！

其實(shí)，Android 的 AIDL 就是讓編譯器幫助我們生成一個(gè)實(shí)現(xiàn)了我們接口的 Binder，以幫助我們簡化開發(fā)。當(dāng)然，如果你了解原理的話，也可以自己寫。

下面我們一步一步來看看這編譯器生成的類都有些什么？

1. 服務(wù)接口實(shí)現(xiàn)IInterface

public interface AIDLDemo extends android.os.IInterface
{
    ...
}

編譯器根據(jù)我們寫的服務(wù)接口，重新生成了一個(gè)接口，唯一的區(qū)別就是新的接口繼承了IInterface接口。這個(gè)接口是干什么的呢？

public interface IInterface
{
    public IBinder asBinder();
}

可以看到，它只有一個(gè)接口方法。這個(gè)方法用來定義將實(shí)現(xiàn)接口的類應(yīng)該具備返回一個(gè)與之相關(guān)聯(lián)的Binder的功能，以提供通訊能力。一般實(shí)現(xiàn)這個(gè)方法的類自己本身就會(huì)去繼承Binder。

這樣的設(shè)計(jì)使得Binder機(jī)制不用關(guān)心具體的接口是什么，只要是IInterface就行。事實(shí)上相當(dāng)于是我們?cè)?code>IInterface接口的基礎(chǔ)上擴(kuò)展了接口功能，本質(zhì)上還是一個(gè)IInterface，所以Binder能夠認(rèn)出它。

2. 繼承Binder，實(shí)現(xiàn)服務(wù)接口

要進(jìn)行 Binder 通訊，我們自然需要一個(gè) Binder；要實(shí)現(xiàn)我們定義的服務(wù)接口功能，自然就需要實(shí)現(xiàn)服務(wù)接口。那么需要滿足這兩個(gè)條件怎么辦？很簡單，繼承 Binder，然后實(shí)現(xiàn)服務(wù)接口就行。

編譯器為我們生成的類中有一個(gè)內(nèi)部類Stub就是這么干的。事實(shí)上，這樣的設(shè)計(jì)隨處可見。你可以看看 CoorChice 這篇文章《3分鐘看懂Activity啟動(dòng)流程》http://www.jianshu.com/p/9ecea420eb52 中出現(xiàn)的ActivityManagerNative 就是這么干的，雖然它是代理系統(tǒng)的ActivityManagerService，但是模式都是一樣的。

public static abstract class Stub extends android.os.Binder implements com.coorchice.coorchicelibone.AIDLDemo

3. Binder需要綁定服務(wù)接口，定義DESCRIPTOR描述

為了一個(gè)Binder和一個(gè)特定服務(wù)接口綁定，以對(duì)外提供功能，需要給Binder定義一個(gè)DESCRIPTOR描述，表示我這個(gè)Binder是提供特定功能鏈接的，不是隨便可以用的。

通常，DESCRIPTOR描述會(huì)直接使用包名 + 服務(wù)接口。

4. 實(shí)現(xiàn)asInterface()供客戶端調(diào)用

作為一個(gè)服務(wù)提供者，為了能夠給調(diào)用者提供遠(yuǎn)程功能，自然需要能夠提供和遠(yuǎn)程服務(wù)關(guān)聯(lián)的 Binder 來通訊，請(qǐng)求服務(wù)。獲取 Binder 的接口就是 IInterface 中定義的。

先查詢一下獲取到的和遠(yuǎn)程 Service 通訊的 Binde 中是否已經(jīng)添加了功能接口的實(shí)現(xiàn)，如果沒有則創(chuàng)建代理，通過代理間接的操作 Binder 和遠(yuǎn)程 Service 通訊，實(shí)現(xiàn)功能。

思考：既然我們已經(jīng)獲取到了能夠直接和遠(yuǎn)程 Service 通訊的Binder，為什么不直接操作它去向遠(yuǎn)程 Service 請(qǐng)求服務(wù)呢？

確實(shí)，我們可以直接操作 Binder 向遠(yuǎn)程 Service 請(qǐng)求服務(wù)，但這過程中有很多繁瑣的操作，還有一些 code碼的區(qū)別，如果不封裝隔離的話，隨著功能的擴(kuò)展，我們將很難再去維護(hù)這段通訊邏輯。還有就是通過這種方式統(tǒng)一的管理通訊邏輯使得它可以隨處使用，而不用沒一個(gè)要用的地方都去寫一遍。

既然是要代理和遠(yuǎn)程服務(wù)通訊，而且通訊的目的是為了請(qǐng)求服務(wù)接口定義的功能，那么很自然就能想到去實(shí)現(xiàn)服務(wù)接口，然后再對(duì)應(yīng)的接口方法中實(shí)現(xiàn)邏輯即可。這樣就可以分開來維護(hù)客戶端和服務(wù)端的對(duì)應(yīng)的每個(gè)功能了。

所以，我們的代理也需要實(shí)現(xiàn)服務(wù)接口，然后在代理中操作遠(yuǎn)程通訊的Binder進(jìn)行通訊。

5. 重寫onTransact()

在Binder通訊中，一個(gè)和遠(yuǎn)程端通訊的Binder::transact()方法，會(huì)觸發(fā)通訊目標(biāo)端執(zhí)行Binder::onTransact()，就是說這個(gè)時(shí)候已經(jīng)收到了通訊發(fā)起端的請(qǐng)求了?？纯催@個(gè)方法的參數(shù)：

public boolean transact(int code, Parcel data, Parcel reply, int flags){}

參數(shù)	解釋
code	用來標(biāo)識(shí)指令，即這次通訊是使用什么功能。需要客戶端和服務(wù)端約定好code碼。
data	來自發(fā)送端的數(shù)據(jù)包。
reply	來自發(fā)送端的接收包，往這個(gè)包中寫數(shù)據(jù)，就相當(dāng)于給發(fā)送端返回?cái)?shù)據(jù)。
flags	特殊操作標(biāo)識(shí)。

對(duì)應(yīng)的我們?cè)诳纯?code>Binder::transact()方法：

public boolean transact(int code, Parcel data, Parcel reply, int flags){}

參數(shù)	解釋
code	用來標(biāo)識(shí)指令，即這次通訊是使用什么功能。需要客戶端和服務(wù)端約定好code碼。
data	發(fā)送給遠(yuǎn)程端的數(shù)據(jù)包。
reply	用于讓遠(yuǎn)程端寫回復(fù)數(shù)據(jù)的數(shù)據(jù)包
flags	特殊操作標(biāo)識(shí)。

可以看出來，兩個(gè)是成對(duì)的操作。Binder::transact()操作是一個(gè)阻塞式的操作，就是說在這個(gè)方法執(zhí)行返回成功后，直接從reply中讀取的數(shù)據(jù)就是遠(yuǎn)程端在Binder::onTransact()中填充的數(shù)據(jù)。

這個(gè)過程可以大概抽象成這個(gè)樣子：

在編譯器自動(dòng)幫我們生成的onTransact()中，會(huì)讀取data中數(shù)據(jù)，然后調(diào)用對(duì)應(yīng)的方法（這個(gè)方法還沒實(shí)現(xiàn)，所以我們可以繼承Stub然后重寫，以實(shí)現(xiàn)在服務(wù)端處理的效果）。比如這個(gè)樣子：