1.簡(jiǎn)單介紹下binder

binder是一種進(jìn)程間通訊的機(jī)制

進(jìn)程間通訊需要了解用戶空間和內(nèi)核空間

每個(gè)進(jìn)程擁有自己的獨(dú)立虛擬機(jī)，系統(tǒng)為他們分配的地址空間都是互相隔離的。 如兩個(gè)進(jìn)程需要進(jìn)行通訊，則需要使用到內(nèi)核空間做載體，內(nèi)核空間是所有進(jìn)程共享的一塊內(nèi)存區(qū)域。 而用戶空間切到內(nèi)核空間需要使用到系統(tǒng)api ioctl進(jìn)行通訊。內(nèi)核獲取用戶的數(shù)據(jù)需要使用copy_from_user，內(nèi)核將數(shù)據(jù)發(fā)送給其他進(jìn)程需要使用copy_to_user，這兩個(gè)方法是有性能開(kāi)銷的，對(duì)于socket就是使用的這種模式，為了減少這部分的開(kāi)銷，內(nèi)核提供了binder，binder只需要一次拷貝就可以實(shí)現(xiàn)進(jìn)程通訊.

主要是使用mmap的原理：

在內(nèi)核空間和用戶空間都開(kāi)辟一塊虛擬內(nèi)存區(qū)域同時(shí)指向一塊物理地址，這樣內(nèi)核需要傳遞數(shù)據(jù)給用戶空間時(shí)，只需要將數(shù)據(jù)拷貝到對(duì)應(yīng)的虛擬內(nèi)存地址中，用戶可以通過(guò)虛擬內(nèi)存映射關(guān)系，獲取到內(nèi)核中的數(shù)據(jù)，實(shí)現(xiàn)了一次拷貝通訊。

binder架構(gòu)上面使用的是C/S架構(gòu)：

binder中有三要素：
客戶端，服務(wù)端和ServiceManager

binder整體過(guò)程：

1.注冊(cè)服務(wù) 2.獲取服務(wù) 3.使用服務(wù)

2.Binder的定向制導(dǎo)，如何找到目標(biāo)Binder，喚起進(jìn)程或者線程?

數(shù)據(jù)結(jié)構(gòu)流程：

1.server注冊(cè)過(guò)程 
      1.server傳入一個(gè)flat_binder_object給內(nèi)核態(tài)。內(nèi)核根據(jù)這個(gè)flat_binder_object創(chuàng)建binder_node節(jié)點(diǎn)，為每個(gè)進(jìn)程服務(wù)，內(nèi)部有個(gè)binder_proc.proc = server進(jìn)程
      2.serviceManager在內(nèi)核態(tài)創(chuàng)建binder_ref引用這個(gè)binder_node，內(nèi)部有一項(xiàng)desc = 1,2,3..，在用戶態(tài)會(huì)創(chuàng)建一個(gè)服務(wù)鏈表{name ="server name",handle = "server handle"}
2.client獲取服務(wù)過(guò)程
      3.client向sm查詢服務(wù)，傳遞name
      4.sm返回handle給驅(qū)動(dòng)程序
      5.驅(qū)動(dòng)程序在sm的binder_ref_desc紅黑樹(shù)中根據(jù)handle找到binder_ref，再根據(jù)binder_ref.node找到binder_node,最后給client創(chuàng)建新的binder_ref指向這個(gè)binder_node，他的desc從1開(kāi)始binder_ref{desc=1,node = binder_node},驅(qū)動(dòng)返回desc給client，即handle總結(jié)：sm中的handle順序是根據(jù)服務(wù)注冊(cè)順序顯示，返回給client中的handle是根據(jù)服務(wù)獲取的順序顯示的
3.client使用handle過(guò)程
      6.：驅(qū)動(dòng)里面根據(jù)handle找到找到binder_ref，根據(jù)binder_ref找到binder_node，根據(jù)binder_node找到進(jìn)程server

注：

flat_binder_object{
    type:是binder實(shí)體還是引用，只有需要注冊(cè)的服務(wù)可以傳binder實(shí)體，其他只能傳handle引用
    flag(聯(lián)合體)
    binder(實(shí)體：處理函數(shù))/handle(引用：服務(wù)的引用)：
    cookie
}

數(shù)據(jù)傳輸過(guò)程(進(jìn)程切換)：

數(shù)據(jù)如何復(fù)制：

3.Binder中的紅黑樹(shù)，為什么會(huì)有兩棵binder_ref紅黑樹(shù)

• refs_by_desc主要是通過(guò)desc來(lái)查找對(duì)應(yīng)的binder_ref
• refs_by_node主要是通過(guò)node來(lái)查找對(duì)應(yīng)的binder_ref

查找方式不一樣

4.Binder一次拷貝原理

傳統(tǒng)的數(shù)據(jù)拷貝方式如socket：

用戶空間---->內(nèi)核空間：`copy_from_user `
內(nèi)核空間---->用戶空間：`copy_to_user`

而binder使用mmap機(jī)制

在內(nèi)核空間和用戶空間中間使用物理地址開(kāi)辟了一個(gè)映射關(guān)系
內(nèi)核空間調(diào)用copy_from_user會(huì)直接將數(shù)據(jù)拷貝到內(nèi)核空間并反饋到映射后的物理地址上，
由于用戶空間和物理地址也有個(gè)映射關(guān)系，用戶空間可以直接通過(guò)映射的虛擬地址指針訪問(wèn)到寫(xiě)入物理地址的數(shù)據(jù)。
這就是binder一次拷貝的原理

5.Binder傳輸數(shù)據(jù)的大小限制?

對(duì)于內(nèi)核可以傳輸?shù)氖?code>4M，但是應(yīng)用層限制在1M-8K范圍內(nèi)，這就是在進(jìn)程間傳輸過(guò)大的數(shù)據(jù)會(huì)導(dǎo)致崩潰的原因

6.系統(tǒng)服務(wù)與bindService等啟動(dòng)的服務(wù)的區(qū)別

系統(tǒng)服務(wù)需要將服務(wù)注冊(cè)到ServiceManager，使用的時(shí)候需要通過(guò)服務(wù)名稱去ServiceManger中獲取服務(wù)的引用，

而bindService等啟動(dòng)的服務(wù)是將服務(wù)注冊(cè)到AMS中的ServiceMap中，所有的服務(wù)的生命周期都由AMS控制。啟動(dòng)服務(wù)的進(jìn)程如果需要使用IPC通訊，都是和獲取AMS的代理類進(jìn)行通訊，AMS也是在SystemServer啟動(dòng)的時(shí)候一個(gè)注冊(cè)到ServiceManager的系統(tǒng)服務(wù)。

7.Binder多線程

binder線程池默認(rèn)提供了15個(gè)線程進(jìn)行處理進(jìn)程間并發(fā)事件，如果服務(wù)端線程不夠用，則驅(qū)動(dòng)會(huì)發(fā)出一個(gè)信號(hào)，應(yīng)用層收到這個(gè)信號(hào)調(diào)用Register_Thread，這樣驅(qū)動(dòng)層就可以使用這個(gè)新建出來(lái)的子線程進(jìn)行數(shù)據(jù)的處理

8.Android APP進(jìn)程天生支持Binder通信的原理是什么?

Android APP進(jìn)程都是由Zygote進(jìn)程孵化出來(lái)的。

常見(jiàn)場(chǎng)景：

點(diǎn)擊桌面icon啟動(dòng)APP，或者startActivity啟動(dòng)一個(gè)新進(jìn)程里面的Activity，最終都會(huì)由AMS去調(diào)用Process.start()方法去向Zygote進(jìn)程發(fā)送請(qǐng)求，讓Zygote去fork一個(gè)新進(jìn)程，Zygote收到請(qǐng)求后會(huì)調(diào)用Zygote.forkAndSpecialize()來(lái)fork出新進(jìn)程,之后會(huì)通過(guò)RuntimeInit.nativeZygoteInit來(lái)初始化Andriod APP運(yùn)行需要的一些環(huán)境，而binder線程就是在這個(gè)時(shí)候新建啟動(dòng)的

virtual void onZygoteInit()
{
    sp proc = ProcessState::self();
    //啟動(dòng)新binder線程loop
    proc->startThreadPool();
}

9.同一個(gè)線程的請(qǐng)求必定是順序執(zhí)行，即使是異步請(qǐng)求(oneway)

一般而言，Client同步阻塞請(qǐng)求Service，直到Service提供完服務(wù)后才返回，不過(guò)，也有特殊的，比如請(qǐng)求用ONE_WAY方式，這種場(chǎng)景一般主要是用來(lái)通知，至于通知被誰(shuí)消費(fèi)，是否被消費(fèi)壓根不會(huì)關(guān)心。 拿ContentService服務(wù)為例子，它是一個(gè)全局的通知中心，負(fù)責(zé)轉(zhuǎn)發(fā)通知，而且，一般是群發(fā)，由于在轉(zhuǎn)發(fā)的時(shí)候，ContentService被看做Client，如果這個(gè)時(shí)候采用普通的同步阻塞勢(shì)必會(huì)造成通知的延時(shí)發(fā)送送，所以這里的Client采用了oneway，異步。

到此這篇關(guān)于Android中關(guān)于Binder常見(jiàn)面試問(wèn)題小結(jié)的文章就介紹到這了,更多相關(guān)Android Binder面試內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！