OpenHarmony 中存在很多的服務，一般來說可以使得 A 應用調用 B 服務的方法，就像在自己進程中調用一樣，這里具體的實現(xiàn)實際通過 binder 驅動實現(xiàn)。

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

服務的一般編碼模式

使用 proxy - stub 架構編程，大致可以分為以下三個步驟：

設計接口類，繼承至 IRemoteBroker，接口方法一般設計為虛方法。

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

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

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

源碼剖析

我們通過閱讀源碼，解開其神秘的面紗。我們現(xià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 驅動中數(shù)據(jù)傳輸?shù)念悾^承自 Parcelable 。而繼承RefBase 可以理解為智能指針的控制塊。

OpenHarmony 中這里并沒有直接使用 C++ 標準庫中的智能指針，而是使用 sptr 和 refbase 兩個類共同構建，也就是裸指針和控制塊相關信息。使用后者的方式，更加解耦。符合復雜架構設計理念。

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ū)分標識。

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)模板模式)編程，使得父類可以調用子類的方法。繼承自 peerhold (其實就是包括一個 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 對象復雜一些，也使用 crtp 編程。會繼承 IPCObjectStub(也是 iremoteObject 對象)。

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

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

proxy 的構造繼承 peerhold，peerhold 類中的iremoteObject 對象和 IPCObjectStub 這個是什么關系呢?

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

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

原文標題：剖析鴻蒙經(jīng)典的proxy - stub架構

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

審核編輯：湯梓紅