Android程式間通訊（IPC）機制Binder簡要介紹和學習計劃

在Android系統中，每一個應用程式都是由一些Activity和Service組成的，一般Service執行在獨立的程式中，而Activity有可能執行在同一個程式中，也有可能執行在不同的程式中。那麼，不在同一個程式的Activity或者Service是如何通訊的呢？這就是本文中要介紹的Binder程式間通訊機制了。

        我們知道，Android系統是基於Linux核心的，而Linux核心繼承和相容了豐富的Unix系統程式間通訊（IPC）機制。有傳統的管道（Pipe）、訊號（Signal）和跟蹤（Trace），這三項通訊手段只能用於父程式與子程式之間，或者兄弟程式之間；後來又增加了命令管道（Named Pipe），使得程式間通訊不再侷限於父子程式或者兄弟程式之間；為了更好地支援商業應用中的事務處理，在AT&T的Unix系統V中，又增加了三種稱為“System V IPC”的程式間通訊機制，分別是報文佇列（Message）、共享記憶體（Share Memory）和訊號量（Semaphore）；後來BSD Unix對“System V IPC”機制進行了重要的擴充，提供了一種稱為插口（Socket）的程式間通訊機制。若想進一步詳細瞭解這些程式間通訊機制，建議參考Android學習啟動篇一文中提到《Linux核心原始碼情景分析》一書。

        但是，Android系統沒有采用上述提到的各種程式間通訊機制，而是採用Binder機制，難道是因為考慮到了移動裝置硬體效能較差、記憶體較低的特點？不得而知。Binder其實也不是Android提出來的一套新的程式間通訊機制，它是基於來實現的。OpenBinder最先是由開發的，接著也跟著使用。現在OpenBinder的作者就是在Google工作，負責Android平臺的開發工作。

        前面一再提到，Binder是一種程式間通訊機制，它是一種類似於COM和CORBA分散式元件架構，通俗一點，其實是提供遠端過程呼叫（RPC）功能。從英文字面上意思看，Binder具有粘結劑的意思，那麼它把什麼東西粘結在一起呢？在Android系統的Binder機制中，由一系統元件組成，分別是Client、Server、Service Manager和Binder驅動程式，其中Client、Server和Service Manager執行在使用者空間，Binder驅動程式執行核心空間。Binder就是一種把這四個元件粘合在一起的粘結劑了，其中，核心元件便是Binder驅動程式了，Service Manager提供了輔助管理的功能，Client和Server正是在Binder驅動和Service Manager提供的基礎設施上，進行Client-Server之間的通訊。Service Manager和Binder驅動已經在Android平臺中實現好，開發者只要按照規範實現自己的Client和Server元件就可以了。說起來簡單，做起難，對初學者來說，Android系統的Binder機制是最難理解的了，而Binder機制無論從系統開發還是應用開發的角度來看，都是Android系統中最重要的組成，因此，很有必要深入瞭解Binder的工作方式。要深入瞭解Binder的工作方式，最好的方式莫過於是閱讀Binder相關的原始碼了，Linux的鼻祖Linus Torvalds曾經曰過一句名言RTFSC：Read The Fucking Source Code。

        雖說閱讀Binder的原始碼是學習Binder機制的最好的方式，但是也絕不能打無準備之仗，因為Binder的相關原始碼是比較枯燥無味而且比較難以理解的，如果能夠輔予一些理論知識，那就更好了。閒話少說，網上關於Binder機制的資料還是不少的，這裡就不想再詳細寫一遍了，強烈推薦下面兩篇文章：

        Android深入淺出之Binder機制

        

        Android深入淺出之Binder機制一文從情景出發，深入地介紹了Binder在使用者空間的三個元件Client、Server和Service Manager的相互關係，Android Binder設計與實現一文則是詳細地介紹了核心空間的Binder驅動程式的資料結構和設計原理。非常感謝這兩位作者給我們帶來這麼好的Binder學習資料。總結一下，Android系統Binder機制中的四個元件Client、Server、Service Manager和Binder驅動程式的關係如下圖所示：

        

        1. Client、Server和Service Manager實現在使用者空間中，Binder驅動程式實現在核心空間中

        2. Binder驅動程式和Service Manager在Android平臺中已經實現，開發者只需要在使用者空間實現自己的Client和Server

        3. Binder驅動程式提供裝置檔案/dev/binder與使用者空間互動，Client、Server和Service Manager透過open和ioctl檔案操作函式與Binder驅動程式進行通訊

        4. Client和Server之間的程式間通訊透過Binder驅動程式間接實現

        5. Service Manager是一個守護程式，用來管理Server，並向Client提供查詢Server介面的能力

        至此，對Binder機制總算是有了一個感性的認識，但仍然感到不能很好地從上到下貫穿整個IPC通訊過程，於是，打算透過下面四個情景來分析Binder原始碼，以進一步理解Binder機制：

        1. Service Manager是如何成為一個守護程式的？即Service Manager是如何告知Binder驅動程式它是Binder機制的上下文管理者。

        2. Server和Client是如何獲得Service Manager介面的？即defaultServiceManager介面是如何實現的。

        3. Server是如何把自己的服務啟動起來的？Service Manager在Server啟動的過程中是如何為Server提供服務的？即IServiceManager::addService介面是如何實現的。

        4  Service Manager是如何為Client提供服務的？即IServiceManager::getService介面是如何實現的。

        在接下來的四篇文章中，將按照這四個情景來分析Binder原始碼，都將會涉及到使用者空間到核心空間的Binder相關原始碼。這裡為什麼沒有Client和Server是如何進行程式間通訊的情景呢？ 這是因為Service Manager在作為守護程式的同時，它也充當Server角色。因此，只要我們能夠理解第三和第四個情景，也就理解了Binder機制中Client和Server是如何透過Binder驅動程式進行程式間通訊的了。

        為了方便描述Android系統程式間通訊Binder機制的原理和實現，在接下來的四篇文章中，我們都是基於C/C++語言來介紹Binder機制的實現的，但是，我們在Android系統開發應用程式時，都是基於Java語言的，因此，我們會在最後一篇文章中，詳細介紹Android系統程式間通訊Binder機制在應用程式框架層的Java介面實現：

        5. Android系統程式間通訊Binder機制在應用程式框架層的Java介面原始碼分析。

 

原部落格連結：http://blog.csdn.net/luoshengyang/article/details/6618363

本文節選自《Android系統原始碼情景分析》

電子工業出版社出版

羅昇陽 著