Mojo簡介

Mojo 是一個運行時庫的集合，提供與平臺無關(guān)的通用 IPC 原語抽象、消息 IDL 格式以及具有針對多種目標語言的代碼生成的綁定庫，以便于跨任意進程間和進程內(nèi)邊界傳遞消息。
Mojo 分為清晰分離的層，子組件的基本層次結(jié)構(gòu)如下：

分析Mojo之前，我們的思考

筆者在閱讀源碼前，喜歡會去思考，“如果讓我來設計一個類似的功能的模塊，我會怎么設計？”。然后對比文檔去思考為什么會出現(xiàn)思路的差異，這種方式可以讓我快速掌握一個開源庫的設計精髓。
這次也是一樣，我們想想，如果是我們自己設計Mojo，這會是什么樣的架構(gòu)和過程。

1. 首先，Mojo是跨平臺的，那么必然有一層platform的平臺差異屏蔽層；
2. 其次，跨進程通信在不同平臺上的最佳實現(xiàn)方案可能不一樣，例如有的平臺是管道，有的平臺是共享內(nèi)存，具體如何選擇取決于不同平臺的性能差異，因此，我必須將跨平臺通信細節(jié)進行抽象，提取出一些概念，用于描述通信的應用層細節(jié)。
3. 之后，兩個進程之間的通信之前，需要先建立連接，因此必然也需要定義一組規(guī)則和概念，來描述連接的應用層細節(jié)。
4. 為了增加通信的靈活性，我們可以定義一組觀察者或者過濾器的規(guī)則，可以實現(xiàn)對數(shù)據(jù)流的監(jiān)測和量化，也能實現(xiàn)更靈活的擴展。因此我們需要定義一組規(guī)則和概念來實現(xiàn)這個目標。
5. 為了讓跨平臺通信框架更加易于使用，我們需要提供一套序列化和反序列化的框架，這樣可以讓通信以自定義結(jié)構(gòu)體的形式進行，而非數(shù)據(jù)流。
6. 如果存在大量的通信消息，那么我們需要解決不同進程共享頭文件，使用自定義結(jié)構(gòu)體的形式；另外，Mojo除了跨平臺，還需要夸語言，那么，我們必然不能使用某種語言的結(jié)構(gòu)體定義形式（例如C的結(jié)構(gòu)體或者JavaScript友好的Json），而是需要定義一種新的規(guī)則，通過工具自動生成不同語言友好的結(jié)構(gòu)體源碼。

上面的5和6本質(zhì)上可以看作是同一個問題，并且我首先想到的是protobuffer庫可以實現(xiàn)這兩個問題的解法。

帶著我們自己的設計思路，再去看看Mojo的設計方案。

的Mojo方案：

源碼目錄體積一覽：

源碼重要文件一覽（排除test源文件，按大小排序，top的文件如下圖）：

一般來說，體積大的源文件表示的功能都比較核心，因此這些文件里面對應的功能和概念，很大概率是Mojo框架的核心，值得每一項進行標注理解。

Mojo的底層Channel

在Mojo中的源碼中，可以很明顯的發(fā)現(xiàn)關(guān)鍵字Channel是最底層跨進程通信的關(guān)鍵概念，并且能找到平臺相關(guān)的抽象和實現(xiàn)，直接搜索文件名關(guān)鍵字就一覽無余了：

channel.h

看了一眼mojo\core\channel.h可以發(fā)現(xiàn)，抽象基類是mojo::core::Channel, 并且定義了許多核心概念，包括Message（A message to be written to a channel.）、Delegate（ // Delegate methods are called from the I/O task runner with which the Channel
was created (see Channel::Create). 關(guān)鍵回調(diào)OnChannelMessage）等。
不同平臺通過繼承抽象基類mojo::core::Channel實現(xiàn)平臺相關(guān)的讀寫，以mojo\core\channel_win.cc的ChannelWin為例，使用Win32API的ReadFile、WriteFile從base::win::ScopedHandle句柄中讀寫數(shù)據(jù)，這個句柄是構(gòu)造函數(shù)的參數(shù)ConnectionParams（TakeEndpoint().TakePlatformHandle().TakeHandle()）傳入的獲取的。

channel相關(guān)的重點類解析

• PlatformChannel
  是一個封裝了兩個交織在一起的端點的類或結(jié)構(gòu)，這些端點屬于特定平臺的基本通信原語，比如在Windows上是管道，在Unix系統(tǒng)上是域套接字，在macOS上是Mach端口對。其中一個端點被指定為“本地”端點，由創(chuàng)建它的進程保留；另一個端點被指定為“遠程”端點，應當傳遞給外部的進程。

• PlatformChannel 可以用來在兩個進程之間啟動Mojo IPC（一種進程間通信機制）。通常情況下另一個進程是當前進程的子進程，PlatformChannel
  提供輔助方法來將端點以這種方式傳遞給子進程；但這種設置在所有平臺上并不是強制性的。
  如果需要一個允許客戶端通過名稱來連接的通道（比如一個命名管道或者套接字服務器，這種類型僅在Windows和POSIX系統(tǒng)上被支持），那么可以參考
  NamedPlatformChannel。

• PlatformChannelServer 這個類負責持有一個 PlatformChannelServerEndpoint 實例，并監(jiān)聽一個單一的來自客戶端的連接請求。這個類不是線程安全的，必須在運行I/O消息泵（Message Pump）的線程上使用。

• PlatformChannelServer 和PlatformChannel 對比： 簡而言之，PlatformChannel 負責創(chuàng)建和管理進程間通信的通道，而 PlatformChannelServer
  則是在服務端監(jiān)聽和接受這些通道上的連接請求。PlatformChannel 可以看作是連接的“管道”，而 PlatformChannelServer 是“水龍頭”，控制著連接的開啟。

• PlatformHandle平臺句柄類，它帶有一些額外的類型信息，用來表明它是一個通道端點（channel endpoint）。也就是說，它是一種句柄，可以被用來作為 MOJO_INVITATION_TRANSPORT_TYPE_CHANNEL
  發(fā)送或接收邀請到一個遠程的 PlatformChannelEndpoint。

結(jié)合調(diào)用堆棧：

Channel的創(chuàng)建：

Channel的發(fā)送消息：

通過調(diào)用堆棧可以發(fā)現(xiàn)，Channel的概念幾乎是Mojo最底層的概念了，往上走有Router、InterfaceEndpointClient、Message、ChannelMojo概念等。以下是從最底層到更高層的一些核心概念及其作用的介紹：

1. Channel:
   Channel 是 Mojo IPC 系統(tǒng)中最底層的抽象。它代表了一個底層的通信通道，負責在兩個進程之間傳輸原始的字節(jié)數(shù)據(jù)。Channel 封裝了操作系統(tǒng)級別的 IPC 機制（如套接字或共享內(nèi)存），以便在不同的平臺上提供一致的 API。它負責序列化和反序列化消息，保證數(shù)據(jù)的完整性，并處理底層的傳輸細節(jié)。

2. Router:
   Router 位于 Channel 之上，是一個稍高層次的抽象。它負責將發(fā)出的消息路由到正確的 Channel，并從 Channel 接收消息。Router 還管理消息的生命周期，確保消息按照正確的順序發(fā)送和接收，并可能處理流控制和重試邏輯。

3. InterfaceEndpointClient:
   InterfaceEndpointClient 是 Mojo IPC 中的一個組件，它代表了 Mojo 接口的端點。它與 Router 配合，以便在 Mojo 接口上發(fā)送和接收消息。通常，每個 Mojo 接口都有一個或多個方法，這些方法對應于可以通過該端點發(fā)送的消息類型。InterfaceEndpointClient 會序列化這些方法調(diào)用為消息，并將它們傳遞給 Router 進行傳輸。

4. Message:
   Message 是代表 IPC 系統(tǒng)中傳遞的一個消息實體。它通常包含要傳輸?shù)臄?shù)據(jù)（例如，方法調(diào)用的參數(shù)），以及可能的元數(shù)據(jù)（例如，消息類型或優(yōu)先級）。在 Mojo IPC 中，Message 是發(fā)送和接收的基本單位，由 Router 和 Channel 處理。

5. ChannelMojo:
   ChannelMojo 是 Channel 的一個具體實現(xiàn)，它利用 Mojo 系統(tǒng)的底層管道（如 MessagePipe）來傳輸數(shù)據(jù)。ChannelMojo 提供了一個適應 Mojo 管道特性的 Channel 接口，使得上層的 Router 和 InterfaceEndpointClient 能夠通過 Mojo 管道發(fā)送和接收消息。

這些概念共同構(gòu)成了 Mojo IPC 系統(tǒng)的框架，其中每個層次都建立在下一個層次之上，提供了逐步更高級別的抽象和功能。開發(fā)者可以根據(jù)需要選擇在哪個層次上與 IPC 系統(tǒng)交互，從直接使用 Channel 的字節(jié)級操作，到通過 InterfaceEndpointClient 的接口級調(diào)用。

Mojo的Node

在源碼一覽中，我們發(fā)現(xiàn)node.cc是最大的源文件，我們以此為線索展開對Node的理解和閱讀，Node相關(guān)文件有：

Node.h中，NodeChannel是一個核心，注釋只有一句：Wraps a Channel to send and receive Node control messages.：

// Wraps a Channel to send and receive Node control messages.
class MOJO_SYSTEM_IMPL_EXPORT NodeChannel: public base::RefCountedDeleteOnSequence<NodeChannel>,public Channel::Delegate {public:// .... 略

由此可見，Channel 是一種底層概念，用于抽象化和平滑處理不同平臺之間的差異，而 Node 概念則在 Channel 的基礎上進行了進一步的封裝和抽象化。NodeChannel用于定義 Mojo 中與連接、廣播、中介（Broker）、消息傳輸以及錯誤處理相關(guān)的實現(xiàn)細節(jié)。如果用計算機網(wǎng)絡的術(shù)語進行類比，那么 Channel 類似于網(wǎng)絡協(xié)議棧中的 IP 層，它提供了尋址和路由的能力；而 NodeChannel則相當于應用層的協(xié)議，例如 UDP，它在更高層次上處理數(shù)據(jù)的傳輸和相關(guān)邏輯。

那么，可以預見，Mojo的應用層概念將圍繞Node為核心展開。

從上面代碼中我們發(fā)現(xiàn)，NodeChannel中有個重要的嵌入類：Delegate。Delegate的概念在chromium廣泛存在，其實可以理解為Delegate就是一組回調(diào)，在宿主對象處理邏輯的關(guān)鍵節(jié)點時，通過Delegate回調(diào)轉(zhuǎn)移執(zhí)行緒，以實現(xiàn)行為的定制和擴展的能力。 通過了解Delegate回調(diào)的函數(shù)組成，可以快速了解宿主類的主要功能和關(guān)鍵流程，是閱讀源碼的重要技巧。例如NodeChannel的Delegate的類定義如下：

 class Delegate {public:virtual ~Delegate() = default;virtual void OnAcceptInvitee(const ports::NodeName& from_node,const ports::NodeName& inviter_name,const ports::NodeName& token) = 0;virtual void OnAcceptInvitation(const ports::NodeName& from_node,const ports::NodeName& token,const ports::NodeName& invitee_name) = 0;virtual void OnAddBrokerClient(const ports::NodeName& from_node,const ports::NodeName& client_name,base::ProcessHandle process_handle) = 0;virtual void OnBrokerClientAdded(const ports::NodeName& from_node,const ports::NodeName& client_name,PlatformHandle broker_channel) = 0;virtual void OnAcceptBrokerClient(const ports::NodeName& from_node,const ports::NodeName& broker_name,PlatformHandle broker_channel,const uint64_t broker_capabilities) = 0;virtual void OnEventMessage(const ports::NodeName& from_node,Channel::MessagePtr message) = 0;virtual void OnRequestPortMerge(const ports::NodeName& from_node,const ports::PortName& connector_port_name,const std::string& token) = 0;virtual void OnRequestIntroduction(const ports::NodeName& from_node,const ports::NodeName& name) = 0;virtual void OnIntroduce(const ports::NodeName& from_node,const ports::NodeName& name,PlatformHandle channel_handle,const uint64_t remote_capabilities) = 0;virtual void OnBroadcast(const ports::NodeName& from_node,Channel::MessagePtr message) = 0;
#if BUILDFLAG(IS_WIN)virtual void OnRelayEventMessage(const ports::NodeName& from_node,base::ProcessHandle from_process,const ports::NodeName& destination,Channel::MessagePtr message) = 0;virtual void OnEventMessageFromRelay(const ports::NodeName& from_node,const ports::NodeName& source_node,Channel::MessagePtr message) = 0;
#endifvirtual void OnAcceptPeer(const ports::NodeName& from_node,const ports::NodeName& token,const ports::NodeName& peer_name,const ports::PortName& port_name) = 0;virtual void OnChannelError(const ports::NodeName& node,NodeChannel* channel) = 0;};

通過這個代理類，就能很直觀地理解NodeChannel的功能和作用。

mojo的Port

在閱讀NodeChannel類的時候，有一個關(guān)鍵字出現(xiàn)了多次，那就是port。在Mojo中，port是一個命名空間，也是一個重要概念，port這個類的頭文件注釋如下：

在 Mojo IPC 系統(tǒng)中，“Port”本質(zhì)上是一個地址的循環(huán)列表中的一個節(jié)點。為了本文檔的目的，這樣的列表將被稱為“路由”（route）。路由是所有 Node 事件流通的基本媒介，因此是所有 Mojo 消息傳遞的骨干。
每個 Port 都由一個節(jié)點（參見 node.h）內(nèi)的 128 位地址唯一標識。Port 本身并不真正“做”任何事情：它是一系列狀態(tài)的命名集合，而擁有它的 Node 管理所有事件的產(chǎn)生、傳輸、路由和處理邏輯。有關(guān) Port 如何被用來傳輸任意用戶消息以及其他 Ports 的更多細節(jié)，請參見 Node。
Ports 可以處于幾種狀態(tài)（見下面的 State），這些狀態(tài)決定了它們?nèi)绾雾憫运鼈優(yōu)槟繕说南到y(tǒng)事件。在最簡單和最常見的情況下，Ports 最初是作為一對糾纏在一起的狀態(tài)（即由兩個 Ports 組成的簡單循環(huán)）創(chuàng)建的，都處于 kReceiving 狀態(tài)。我們這里將這些 Ports 標為 |A| 和 |B|，它們可以使用 Node::CreatePortPair() 創(chuàng)建：

    +-----+          +-----+|     |--------->|     ||  A  |          |  B  ||     |<---------|     |+-----+          +-----+

|A| 通過 |peer_node_name| 和 |peer_port_name| 引用 |B|，同時 |B| 反過來引用
|A|。請注意，一個 Node 永遠不會知道是誰向給定的 Port 發(fā)送事件；它只知道必須從給定的 Port 路由事件到哪里。
為了方便文檔描述，我們將路由中的一個接收端 Port 稱為另一個的“共軛”（conjugate）。一個接收端 Port 的共軛在初始創(chuàng)建時也是它的對端，但由于代理，這種關(guān)系可能隨著時間而改變。 對這個數(shù)據(jù)結(jié)構(gòu)的所有訪問必須通過獲取 |lock_|來進行保護，這只能通過 PortLocker 實現(xiàn)。PortLocker 確保在單個線程上重疊的 Port 鎖獲取總是以全局一致的順序進行。

通過頭文件注釋，感覺似懂非懂，看看Port這個類的主要成員和方法吧：

Port 類是 Mojo IPC 系統(tǒng)中的一個核心組件，它代表了消息傳遞路徑上的一個節(jié)點。這個類繼承自
base::RefCountedThreadSafe<Port>，允許它在多個線程中安全地共享和管理其生命周期。以下是 Port
類的主要功能和特性：

• State 枚舉：定義了 Port 可能處于的狀態(tài)，包括 kUninitialized（未初始化）、kReceiving（接收中）、kBuffering（緩沖中）、kProxying（代理中）和
  kClosed（已關(guān)閉）。
• state 成員變量：存儲當前 Port 的狀態(tài)。
• peer_node_name 和 peer_port_name 成員變量：指定了事件應該從該 Port 路由到哪個節(jié)點和端口的地址。
• prev_node_name 和 prev_port_name 成員變量：跟蹤當前發(fā)送消息到這個 Port 的上一個端口，用于驗證發(fā)送方節(jié)點是否有權(quán)限發(fā)送消息到這個端口，同時保持接收消息的順序。
• pending_merge_peer 成員變量：標記這個端口是否準備合并。
• 一系列的序列號成員變量（next_control_sequence_num_to_send、next_sequence_num_to_send
  等）：用于跟蹤控制和用戶消息事件的序列號。
• message_queue 成員變量：存儲該 Port 接收到的用戶消息隊列。此隊列只為 kBuffering 或 kReceiving 狀態(tài)的 Port 提供服務。
• control_message_queue 成員變量：在 Port 處于 kBuffering 狀態(tài)時，暫存即將發(fā)送的控制消息。
• send_on_proxy_removal 成員變量：在某些邊緣情況下，如果這個（代理中的）Port 被銷毀，它可能需要記得路由一個特殊的事件。
• user_data 成員變量：附加到 Port 的任意用戶數(shù)據(jù)。在 Mojo 中，這通常用于存儲通知有關(guān) Port 狀態(tài)變化的觀察者接口。
• remove_proxy_on_last_message 和 peer_closed 成員變量：標志位，用于指示 Port 的一些狀態(tài)，如代理何時可以移除，以及它的對端 Port 是否已關(guān)閉。
• Port 構(gòu)造函數(shù)：用于初始化 Port，設置初始的序列號。
• AssertLockAcquired 方法：用于調(diào)試中檢查是否已獲取 Port 的鎖。
• IsNextEvent 方法：檢查給定的事件是否應該根據(jù)序列號和發(fā)送方節(jié)點接下來處理。
• NextEvent 方法：獲取下一個要處理的緩沖事件。
• BufferEvent 方法：將事件緩存以供后續(xù)處理。>
• TakePendingMessages 方法：清空等待節(jié)點驗證的事件隊列，并返回所有用戶事件。
• 私有析構(gòu)函數(shù) ~Port：確保 Port 只能通過引用計數(shù)安全地銷毀。
• 私有成員 lock_：用于確保對 Port 數(shù)據(jù)結(jié)構(gòu)的線程安全訪問。
• PortLocker 友元類：用于確保在單個線程上以全局一致的順序獲取重疊的 Port 鎖。
  該類的設計允許它在 Mojo IPC 系統(tǒng)中作為消息的發(fā)送和接收點，管理消息的順序和狀態(tài)，并確保消息在正確的路徑上流動。

結(jié)合其他源碼，發(fā)現(xiàn)Port和Dispatcher相關(guān)邏輯結(jié)合緊密，另外，Port存儲了Event的序號等數(shù)據(jù)信息，支持插入事件，并且許多數(shù)據(jù)成員用于Node.cc中實現(xiàn)消息處理，可見Port這個類做的事情確實很難和已有的概念類比出來，也難怪通過這個類的注釋難以一下理解其作用。簡而言之，Port這個類即負責一部分事件排序和派發(fā)相關(guān)的邏輯處理，也承載了一個尋址的功能。

在 Mojo IPC 系統(tǒng)中，Node 通常代表了一個獨立的參與者，如一個進程，它是消息傳遞路徑上的一個物理節(jié)點。Node 可以是消息的最初發(fā)送者或最終接收者。相比之下，Port 是 Node 內(nèi)部的邏輯上的虛擬節(jié)點，它負責管理消息的復雜路由、轉(zhuǎn)發(fā)以及過濾等操作。每個 Port 都由其所屬的 Node 管理，并且可以與其他 Node 中的 Port 形成連接，從而構(gòu)成消息傳遞的網(wǎng)絡。
之所以這樣設計，是為了讓兩個Node之間可以出現(xiàn)多個連接，每個連接就是一對“共軛”的Port。這樣每個連接各自的序號（seq）就不會互相干擾。所以，序號的數(shù)據(jù)就存儲在Port類里，這也就不奇怪了。正因為Port代表了連接，所以數(shù)據(jù)的過濾和代理也必須面向連接進行，因此Port也和相關(guān)的類緊密聯(lián)系。

說實話，如果把Port改名為Connection，也許會更直觀一些。

這里面出現(xiàn)了NodeName和Port Name，也順便看看定義：

struct COMPONENT_EXPORT(MOJO_CORE_PORTS) PortName : Name {constexpr PortName() : Name(0, 0) {}constexpr PortName(uint64_t v1, uint64_t v2) : Name(v1, v2) {}
};
struct COMPONENT_EXPORT(MOJO_CORE_PORTS) NodeName : Name {constexpr NodeName() : Name(0, 0) {}constexpr NodeName(uint64_t v1, uint64_t v2) : Name(v1, v2) {}
};

接下來

接下來，我們繼續(xù)閱讀Mojo模塊的代碼。了解消息的過濾和派發(fā)、序列化和反序列化、Mojom、等功能邏輯。（未完待續(xù)…）