binder 瞭解

一直以來，自覺得對binder有所瞭解，也曾暗暗佩服本身怎麼這麼厲害。直到一次須要用到 binder 進行通訊，信心百倍的提出使用 service 中 binder 或者 messager 來獲取，可是原來已經使用來 contentprovider ，再使用 service 就存在延遲和重複等等問題，在想着使用 aidl (思索着仍是脫離不了 service )、 contentobserver 這個到不錯，可是由於須要雙向通訊，總不能每一個進程在單獨配一個獨自的contentprovider 、再有就是使用廣播來進行了，可是太依賴系統處理，實時性等都沒法保證。

這時候有同事提出可使用各個進程把 binder 傳到 contentprovider，這樣在 cp 中就能夠經過 binder 調用相關回調方法實現通訊，而各個進程訪問 cp 便可。

第一反應，可行。但是轉念一想，adil 的 stub 就只是建立一個 binder 對象、實例，傳遞到 cp 那邊不就只是把這個對象傳過去了嗎，cp 對調用這個對象方法還能夠在回到原進程？？？少了一個關鍵步驟啊。那就是 binder 註冊哪去了,爲何傳個對象過去，調用方法還能夠回到原進程，不是就是在當前進程了嗎？

由此我提出了強烈的質疑。binder機制分爲client，server，binder 驅動，ServcieManager。ServiceManager 實質上就是 server ,來進行統一管理。那咱們本身把 binder 傳遞過去沒有意義啊。

實踐出真知。咱們實驗下來發現是可行的。由此我反思到本身 對 binder 理解仍是停留在表層啊。仔細看 messager 實際上也是差很少的狀況。當時爲這個狀況反覆查了很久的資料，終於肯定 binder 驅動是關鍵，它負責來 binder 對象本地和遠端代理的關聯。Binder 實體在 Binder 驅動中的傳輸，會被特殊處理，若是傳遞到其它進程會成爲代理對象，其它進程便可調用對象方法。不通過 ams 只要能經過 跨進程傳遞對象過去便可實現。這麼看來 ServiceManager 是起到註冊管理顯式 binder 的做用，這樣能夠根據名字來作到返回對應的 binder 對象。

在期間其實生出了一個想法，若是能夠存儲到文件裏，而後在另外進程讀出來不是就能夠實現本身的跨進程的目的了嗎。但是很遺憾，表象上的傳遞只是表面，實際上它在內核層還作了很多的事情，好比 binder 支持傳遞文件描述符，ParcelFileDescriptor ，可是其實是在內核爲新的進程又申請了一個文件描述符來關聯到文件。

binder 作爲 android 底層的跨進程通訊基礎，是有不少細節須要注意。可能這也是編碼的魅力吧。每每簡單的東西下有複雜的實現，可是理解後有以爲簡單，再往下又複雜。所謂的精通等等也只是創建在某個角度，某個層面。因此咱們更應該鍛鍊本身的思惟，有不斷更新的架構的思惟才能保證本身永不落伍