1.Service Manager組件是用來管理Server並且向Client提供查詢Server遠程接口的功能；
2.Service Manger、Client和Server三者分別是運行在獨立的進程當中，這樣它們之間的通信也屬於進程間通信：也是採用Binder機制，所以Service Manager也在充當Server的角色，然而，它是一種特殊的Server。
ServiceManager：
1.main函數在“frameworks/base/cmds/servicemanager/service_manager.c”
service_manager::main()
1.binder.c :: binder_open (128*1024) : 建立128K內存映射
(1) (binder_state ) bs->fd = open("/dev/binder", O_RDWR) : 通過文件操作函數open來打開/dev/binder設備文件
1.1 : 創建一個struct binder_proc （threads、nodes、 refs_by_desc和refs_by_node）來保存打開設備文件“/dev/binder”的進程上下文，
（2）binder.c ::binder_mmap () : 對打開的設備文件進行內存映射操作，建立128K內存映射:
1.1 進程虛擬地址空間和內核虛擬地址空間來映射同一個物理頁面 : Binder的精髓，同一個物理頁面，一方映射到進 程虛擬地址空間，一方面映射到內核虛擬地址空間，這樣，進程和內核之間就可以減少一次內存拷貝了，提到了進程間通信效率：
（一般的做法是，Client將這塊數據從它的進程空間拷貝到內核空間中，然後內核再將這個數據從內核空間拷貝到Server的進程空間，這樣，Server就可以訪問這個數據了。但是在這種方法中，執行了兩次內存拷貝操作，而採用我們上面提到的方法，只需要把Client進程空間的數據拷貝一次到內核空間，然後Server與內核共享這個數據就可以了，整個過程只需要執行一次內存拷貝，提高了效率）
2.binder.c :: binder_become_context_manager() :通知Binder驅動程序自己是Binder機制的上下文管理者，即守護進程
3.調用binder.c :: binder_loop () 函數進入循環，等待Client來請求
1.一是打開Binder設備文件;
2.告訴Binder驅動程序自己是Binder上下文管理者，即我們前面所說的守護進程;
3.一個無窮循環，充當Server的角色，等待Client的請求