OpenHarmony 中存在很多的服務(wù)，一般來說可以使得 A 應(yīng)用調(diào)用 B 服務(wù)的方法，就像在自己進(jìn)程中調(diào)用一樣，這里具體的實(shí)現(xiàn)實(shí)際通過 binder 驅(qū)動(dòng)實(shí)現(xiàn)。

binder 驅(qū)動(dòng)通過 mmap 將內(nèi)核態(tài)代碼映射到用戶態(tài)，直接讀寫數(shù)據(jù)這樣就完成了跨進(jìn)程的調(diào)用。不過這不是該篇內(nèi)容的重點(diǎn)，本片主要講一下 proxy - stub 的設(shè)計(jì)模式。

服務(wù)的一般編碼模式

使用 proxy - stub 架構(gòu)編程，大致可以分為以下三個(gè)步驟：

設(shè)計(jì)接口類，繼承至 IRemoteBroker，接口方法一般設(shè)計(jì)為虛方法。

設(shè)計(jì) proxy 類，繼承至 IRemoteProxy，并且實(shí)現(xiàn) sendRequest 方法和自身虛方法。

設(shè)計(jì) stub 類，繼承至 IRemoteStub ，并且實(shí)現(xiàn) OnRemote 方法和自身虛方法。

這樣我們就可以在調(diào)用是調(diào)用 proxy 類的接口方法就像調(diào)用 stub 類的接口方法一樣了。

源碼剖析

我們通過閱讀源碼，解開其神秘的面紗。我們現(xiàn)在關(guān)注幾個(gè)重點(diǎn)的類。

IRemoteObject：

classIRemoteObject:publicvirtualParcelable,publicvirtualRefBase{
public:
enum{
IF_PROT_DEFAULT,/*Invokerfamily.*/
IF_PROT_BINDER=IF_PROT_DEFAULT,
IF_PROT_DATABUS,
};
enum{
DATABUS_TYPE,
};
classDeathRecipient:publicRefBase{
public:
enum{
ADD_DEATH_RECIPIENT,
REMOVE_DEATH_RECIPIENT,
NOTICE_DEATH_RECIPIENT,
TEST_SERVICE_DEATH_RECIPIENT,
TEST_DEVICE_DEATH_RECIPIENT,
};
virtualvoidOnRemoteDied(constwptr&object)=0;
};

virtualint32_tGetObjectRefCount()=0;

virtualintSendRequest(uint32_tcode,MessageParcel&data,MessageParcel&reply,MessageOption&option)=0;

virtualboolIsProxyObject()const;

virtualboolCheckObjectLegality()const;

virtualboolAddDeathRecipient(constsptr&recipient)=0;

virtualboolRemoveDeathRecipient(constsptr&recipient)=0;

virtualboolMarshalling(Parcel&parcel)constoverride;

staticIRemoteObject*Unmarshalling(Parcel&parcel);

staticboolMarshalling(Parcel&parcel,constsptr&object);

virtualsptrAsInterface();

virtualintDump(intfd,conststd::vector<std::u16string>&args)=0;

conststd::u16stringdescriptor_;

std::u16stringGetObjectDescriptor()const;

protected:
explicitIRemoteObject(std::u16stringdescriptor=nullptr);
};

這就是真正在 binder 驅(qū)動(dòng)中數(shù)據(jù)傳輸?shù)念?，繼承自 Parcelable 。而繼承RefBase 可以理解為智能指針的控制塊。

OpenHarmony 中這里并沒有直接使用 C++ 標(biāo)準(zhǔn)庫中的智能指針，而是使用 sptr 和 refbase 兩個(gè)類共同構(gòu)建，也就是裸指針和控制塊相關(guān)信息。使用后者的方式，更加解耦。符合復(fù)雜架構(gòu)設(shè)計(jì)理念。

IRemoteBroker：

classIRemoteBroker:publicvirtualRefBase{
public:
IRemoteBroker()=default;
virtual~IRemoteBroker()override=default;
virtualsptrAsObject()=0;
staticinlinesptrAsImplement(constsptr&object)
{
returnnullptr;
}
};

#defineDECLARE_INTERFACE_DESCRIPTOR(DESCRIPTOR)
staticinlineconststd::u16stringmetaDescriptor_={DESCRIPTOR};
staticinlineconststd::u16string&GetDescriptor()
{
returnmetaDescriptor_;
}

一般的接口類，通過 metaDescriptor_ 作為表示區(qū)分標(biāo)識。

IRemoteProxy：

namespaceOHOS{
template<typenameINTERFACE>classIRemoteProxy:publicPeerHolder,publicINTERFACE{
public:
explicitIRemoteProxy(constsptr&object);
~IRemoteProxy()override=default;

protected:
sptrAsObject()override;
};

template<typenameINTERFACE>
IRemoteProxy::IRemoteProxy(constsptr&object):PeerHolder(object)
{
}

template<typenameINTERFACE>sptrIRemoteProxy::AsObject()
{
returnRemote();
}
}//namespaceOHOS

IRemoteProxy 使用 c++ 的 crtp (奇特重現(xiàn)模板模式)編程，使得父類可以調(diào)用子類的方法。繼承自 peerhold (其實(shí)就是包括一個(gè) IRemoteObject 對象)。

IRemoteStub：

namespaceOHOS{
template<typenameINTERFACE>classIRemoteStub:publicIPCObjectStub,publicINTERFACE{
public:
IRemoteStub();
virtual~IRemoteStub()=default;
sptrAsObject()override;
sptrAsInterface()override;
};

template<typenameINTERFACE>IRemoteStub::IRemoteStub():IPCObjectStub(INTERFACE::GetDescriptor()){}

template<typenameINTERFACE>sptrIRemoteStub::AsInterface()
{
returnthis;
}

template<typenameINTERFACE>sptrIRemoteStub::AsObject()
{
returnthis;
}
}//namespaceOHOS

stub 對象較于 proxy 對象復(fù)雜一些，也使用 crtp 編程。會繼承 IPCObjectStub(也是 iremoteObject 對象)。

看到這里，可能有人疑惑，為什么 proxy 調(diào)用，會直接調(diào)用到 stub 這端呢?

其實(shí)奧秘就在于 stub 繼承的 IPCObjectStub(繼承 iremoteObject)對象，就是這個(gè) iremoteObject 對象。

proxy 的構(gòu)造繼承 peerhold，peerhold 類中的iremoteObject 對象和 IPCObjectStub 這個(gè)是什么關(guān)系呢?

其實(shí) peerhold 是 IPCObjectStub 的引用對象，實(shí)際類型是 IPCObjectProxy。

這兩者在 ipc 框架中，IPCObjectProxy 實(shí)際使用 sendrequest，IPCObjectStub 便會調(diào)用 OnremoteRequest。如果有興趣，我們下次可以分析 IPC 框架具體是如何實(shí)現(xiàn)的。

原文標(biāo)題：剖析鴻蒙經(jīng)典的proxy - stub架構(gòu)

文章出處：【微信公眾號：HarmonyOS技術(shù)社區(qū)】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

審核編輯：湯梓紅