??想了解更多關(guān)于開源的內(nèi)容，請訪問：??

??51CTO 開源基礎(chǔ)軟件社區(qū)??

??https://ost.51cto.com??

原理

1. 物理內(nèi)存中開辟4096字節(jié)內(nèi)存(1m-8k)
    2. 物理內(nèi)存與磁盤內(nèi)存對應(yīng)
    3. mmu將mmap開辟的物理內(nèi)存地址轉(zhuǎn)換成虛擬地址

Binder概述

• 什么是Binder
  Binder最開始是IPC工具，起源于OpenBinder項目，發(fā)展于Android項目，現(xiàn)在已經(jīng)和入LinuxKernel，目前演變成RPC工具，可以使當前進程調(diào)用另一個進程的函數(shù)向自身函數(shù)一樣簡單。

OpenBinder is a system for inter-process communication. It was developed at Be Inc. and then Palm, Inc. and was the basis for the Binder framework now used in the Android operating system developed by Google.

OpenBinder allows processes to present interfaces which may be called by other threads. Each process maintains a thread pool which may be used to service such requests. OpenBinder takes care of reference counting, recursion back into the original thread, and the inter-process communication itself. On the Linux version of OpenBinder, the communication is achieved using ioctls on a given file descriptor, communicating with a kernel driver.

The kernel-side component of the Linux version of OpenBinder was merged into the Linux kernel mainline in kernel version 3.19, which was released on February 8, 2015.

Binder是解決進程間通訊問題的框架

• Binder能干什么
  
  OpenHarmony里的對應(yīng)層次就是：

1. 驅(qū)動：kernel/linux/linux-xxx/drivers/android/binderXXX
2. 服務(wù)：foundation/communication/ipc
3. 框架：各種NAPI里面和對應(yīng)的服務(wù)接口：如foundation/communication/xxx/frameworks/js/napi/xxx和foundation/communication/xxx/services/bluetooth/service/xxx

在OpenHarmony上表現(xiàn)的功能是：

1. 提供客戶端-服務(wù)器（Client-Server）模型，服務(wù)請求方（Client）可獲取提供服務(wù)提供方（Server）的代理 （Proxy），并通過此代理讀寫數(shù)據(jù)來實現(xiàn)進程間的數(shù)據(jù)通信。通常，系統(tǒng)能力（System Ability）Server側(cè)會先注冊到系統(tǒng)能力管理者（System Ability Manager，縮寫SAMgr）中，SAMgr負責管理這些SA并向Client提供相關(guān)的接口。Client要和某個具體的SA通信，必須先從SAMgr中獲取該SA的代理，然后使用代理和SA通信。三方應(yīng)用可以使用FA提供的接口綁定服務(wù)提供方的Ability，獲取代理，進行通信。

在OpenHarmony里的限制是：

1. 單個設(shè)備上跨進程通信時，傳輸?shù)臄?shù)據(jù)量最大約為1MB，過大的數(shù)據(jù)量請使用匿名共享內(nèi)存。
2. 不支持把跨設(shè)備的Proxy對象傳遞回該Proxy對象所指向的Stub對象所在的設(shè)備。

• Binder原理是什么
  
  Binder是C/S架構(gòu)的進程間通訊機制。特點如下：

1. 用戶空間運行：Client，Service和Service Manager；內(nèi)核空間運行：Binder Driver
2. Client，Server和Service Manager通過系統(tǒng)調(diào)用open，mmap和ioctl來訪問設(shè)備文件/dev/binder。從而實現(xiàn)進程間通信
3. 功能詳細如下：

#define BINDER_WRITE_READ   _IOWR('b', 1, struct binder_write_read)
#define BINDER_SET_IDLE_TIMEOUT   _IOW('b', 3, __s64)
#define BINDER_SET_MAX_THREADS    _IOW('b', 5, __u32)
#define BINDER_SET_IDLE_PRIORITY  _IOW('b', 6, __s32)
#define BINDER_SET_CONTEXT_MGR    _IOW('b', 7, __s32)
#define BINDER_THREAD_EXIT    _IOW('b', 8, __s32)
#define BINDER_VERSION      _IOWR('b', 9, struct binder_version)
#define BINDER_GET_NODE_DEBUG_INFO  _IOWR('b', 11, struct binder_node_debug_info)
#define BINDER_FEATURE_SET  _IOWR('b', 30, struct binder_feature_set)
#define BINDER_GET_ACCESS_TOKEN _IOWR('b', 31, struct access_token)

1. 對應(yīng)文件如下

.
├── binder_alloc.c
├── binder_alloc.h
├── binder_alloc_selftest.c
├── binder.c
├── binder_trace.h
├── Kconfig
└── Makefile

1. Binder通信過程介紹

1. Service使用 BINDER_SET_CONTEXT_MGR命令通過Ioctl將自己注冊成為ServiceMannager
2. Client向Binder驅(qū)動發(fā)起獲取服務(wù)的請求，Binder驅(qū)動通過Client需要獲取服務(wù)的名稱，從ServiceManager中獲取對Binder實體的引用，通過獲得到的引用就能實現(xiàn)和Server進程的通信

2. IPC通信過程介紹

1. 首先Binder驅(qū)動在內(nèi)核空間創(chuàng)建一個數(shù)據(jù)接收緩存區(qū)
2. 接著在內(nèi)核空間開辟一塊內(nèi)核緩存區(qū)，建立內(nèi)核緩存區(qū)和內(nèi)核中數(shù)據(jù)接收緩存區(qū)之間的映射關(guān)系，以及內(nèi)核中數(shù)據(jù)接收緩存區(qū)和接收進程用戶空間地址的映射關(guān)系
3. Client通過系統(tǒng)調(diào)用copy_from_user()將數(shù)據(jù)拷貝到內(nèi)核中的內(nèi)核緩存區(qū)，由于內(nèi)核緩存區(qū)和Service的用戶空間存在內(nèi)存映射，所以Service進程的用戶空間也有了此數(shù)據(jù)，這就完成一次跨進程通信

角色說明

1. Client進程：使用服務(wù)的進程
2. Server進程:提供服務(wù)的進程
3. Service Manager進程：管理Service注冊與查詢(將字符形式的Binder名字轉(zhuǎn)化成Client中對該Binder的引用）
4. Binder驅(qū)動：虛擬設(shè)備驅(qū)動，是連接Service進程，Client進程和Service Manager的橋梁，具體作用為：1.傳遞進程間的數(shù)據(jù)，通過內(nèi)存映射。2.實現(xiàn)線程控制：采用Binder的線程池，并由Binder驅(qū)動自身進行管理。

• Binder怎么用
  
  JS側(cè)依賴

import rpc from "@ohos.rpc"
import featureAbility from "@ohos.ability.featureAbility"

Native側(cè)編譯依賴

sdk依賴：

external_deps = [
  "ipc:ipc_core",
]

此外， IPC/RPC依賴的refbase實現(xiàn)在公共基礎(chǔ)庫下，請增加對utils的依賴：

external_deps = [
  "c_utils:utils",
]

JS側(cè)實現(xiàn)跨進程通信基本步驟：

1. 獲取代理

   使用ohos.ability.featureAbility提供的connectAbility方法綁定Ability，在參數(shù)里指定要綁定的Ability所在應(yīng)用的包名、組件名，如果是跨設(shè)備的情況，還需要指定所在設(shè)備的NetworkId。用戶需要在服務(wù)端的onConnect方法里返回一個繼承自ohos.rpc.RemoteObject的對象，此對象會在其onRemoteMessageRequest方法里接收到請求。

2. 發(fā)送請求

   客戶端在connectAbility參數(shù)指定的回調(diào)函數(shù)接收到代理對象后，使用ohos.rpc模塊提供的方法完成RPC通信，其中MessageParcel提供了讀寫各種類型數(shù)據(jù)的方法，IRemoteObject提供了發(fā)送請求的方法，RemoteObject提供了處理請求的方法onRemoteRequest，用戶需要重寫。

Native側(cè)實現(xiàn)跨進程通信的基本步驟：

1. 定義接口類

   接口類繼承IRemoteBroker，定義描述符、業(yè)務(wù)函數(shù)和消息碼。

2. 實現(xiàn)服務(wù)提供端(Stub)

   Stub繼承IRemoteStub(Native)，除了接口類中未實現(xiàn)方法外，還需要實現(xiàn)AsObject方法及OnRemoteRequest方法。

3. 實現(xiàn)服務(wù)請求端(Proxy)

   Proxy繼承IRemoteProxy(Native)，封裝業(yè)務(wù)函數(shù)，調(diào)用SendRequest將請求發(fā)送到Stub。

4. 注冊SA

   服務(wù)提供方所在進程啟動后，申請SA的唯一標識，將Stub注冊到SAMgr。

5. 通過SA的標識和設(shè)備NetworkId，從SAMgr獲取Proxy，通過Proxy實現(xiàn)與Stub的跨進程通信。

??想了解更多關(guān)于開源的內(nèi)容，請訪問：??

??51CTO 開源基礎(chǔ)軟件社區(qū)??

??https://ost.51cto.com??