Android電話系統(tǒng)之-rild
Rild是Init進(jìn)程啟動的一個本地服務(wù)，這個本地服務(wù)并沒有使用Binder之類的通訊手段，而是采用了socket通訊這種方式。RIL(Radio Interface Layer)
Android給出了一個ril實現(xiàn)框架。由于Android開發(fā)者使用的Modem是不一樣的，各種指令格式，初始化序列都可能不一樣，GSM和CDMA就差別更大了，所以為了消除這些差別，Android設(shè)計者將ril做了一個抽象，使用一個虛擬電話的概念。這個虛擬電話對象就是GSMPhone（CDMAPhone),Phon對象所提供的功能協(xié)議，以及要求下層的支撐環(huán)境都有一個統(tǒng)一的描述，這個底層描述的實現(xiàn)就是靠RIL來完成適配。
Andoid將RIL層分為兩個代碼空間：RILD管理框架，AT相關(guān)的xxxril.so動態(tài)鏈接庫。將ＲＩＬ獨(dú)立成一個動態(tài)鏈接庫的好處就是Ａｎｄｒｏｉｄ系統(tǒng)適應(yīng)不同的Ｍｏｄｅｍ，不同的Mode可以有一個獨(dú)立的Ril與之對應(yīng)。從這個層面上看，Rild更多是一個管理框架。
而ril是具體的AT指令合成者和應(yīng)答解析者。從最基本的功能來講，ril建立了一個偵聽Socket，等待客戶端的連接，然后從該連接上讀取RIL-Java成傳遞來的命令并轉(zhuǎn)化成AT指令發(fā)送到Modem。并等待Modem的回應(yīng)，然后將結(jié)果通過套接口傳回到Ril-Java層。下圖是Ril-D的基本框架：
下面的數(shù)據(jù)流傳遞描述圖表描述了RIL-JAVA層發(fā)出一個電話指令的5 步曲。
在AT通訊的過程中有兩類響應(yīng)：一種是請求后給出應(yīng)答，一種是通知類，即為不請自來的，例如短信通知達(dá)到，我們稱該類通知為URC。在Rild中URC和一般的Response是分開處理的，概念上URC由
handleUnsolicited@Atchannel.c處理，而Response由handleFinalResponse來處理。
1 Event Loop
Rild管理的真正精髓在ril.cpp,ril_event.cpp中，在研究的過程中，可以看到設(shè)計者在抽象上所下的功夫，設(shè)計得很優(yōu)美。Event Loop的基本工作就是等待在事件端口（串口，Socket），一旦有數(shù)據(jù)到達(dá)就根據(jù)登記的Event回調(diào)函數(shù)進(jìn)行處理?，F(xiàn)在來看Ril設(shè)計者是如何建立一套管理框架來完成這些工作的？
1.1 Event對象
Event對象構(gòu)成：（fd,index,persist,func,param）
fd 事件相關(guān)設(shè)備句柄。例如對于串口數(shù)據(jù)事件，fd就是相關(guān)串口的設(shè)備句柄
index
persist 如果是保持的，則不從watch_list中刪除。
func 回調(diào)事件處理函數(shù)
param 回調(diào)時參數(shù)
為了統(tǒng)一管理事件，Android使用了三個隊列：watch_list,timer_list,pending_list,并使用了一個設(shè)備句柄池readFDS。
readFDS：是Linux的fd_set，readFDS保存了Rild中所有的設(shè)備文件句柄，以便利用select函數(shù)統(tǒng)一的完成事件的偵聽。
watch_list：監(jiān)測時間隊列。需要檢測的事件都放入到該隊列中。
timer_list：timer隊列
pending_list:待處理事件隊列，事件已經(jīng)觸發(fā)，需要所回調(diào)處理的事件。
事件隊列隊列的操作：ril_event_add,ril_event_del, ril_timer_add
在添加操作中，有兩個動作：
(1) 加入到watch_list
(2) 將句柄加入到readFDS事件句柄池。
1.2 ril_event_loop()
我們知道對于Linux設(shè)備來講，我們可以使用select函數(shù)等待在FDS上,只要FDS中記錄的設(shè)備有數(shù)據(jù)到來，select就會設(shè)置相應(yīng)的標(biāo)志位并返回。readFDS記錄了所有的事件相關(guān)設(shè)備句柄。readFDS中句柄是在在AddEvent加入的。所有的事件偵聽都是建立在linux的select readFDS基礎(chǔ)上。
ril_event_loop 利用select等待在readFDS（fd_set）上，當(dāng)select設(shè)備有數(shù)據(jù)時，ril_event_loop會從select返回，在watch_list中相應(yīng)的Event放置到pend_list，如果Event是持久性的則不從watch_list中刪除。然后ril_event_loop遍歷pengding_list處理Event事件，發(fā)起事件回調(diào)函數(shù)。
1.3 幾個重要的Event
上面分析了ril-d的框架，在該框架上跑的事件有什么
（1）s_listen_event- （s_fdListen,listenCallback）
listenCallback處理函數(shù)，
接收客戶端連接：s_fdCommand=accepte(..)
添加s_commands_event()
重新建立s_listen_event，等待下一次連接
（2） s_command_event(s_fdCommand,ProcessCommandsCallback)
從fdCommand Socket連接中讀取StreamRecord
使用ProcessCommandBufer處理數(shù)據(jù)
s_listen_event在大的功能上處理客戶端連接（Ril-JAVA層發(fā)起的connect）,并建立s_commands_event去處理Socket連接發(fā)來的Ril命令。ProcessCommandBufer實際上包含了Ril指令的下行過程。
1.4 下行命令翻譯及其組織@ProcessCommandBuffer
RIL_JAVA傳遞的命令格式：Parcel ，由命令號，令牌，內(nèi)容組成。RIL_JAVA到達(dá)RIL_C時轉(zhuǎn)為構(gòu)建本地RequestInfo，并將被翻譯成具體的AT指令。由于每條AT命令的參數(shù)是不同的，所以對不同的AT指令，有不同的轉(zhuǎn)換函數(shù)，在此Android設(shè)計在這里做了一個抽象，做了一個分發(fā)框架，通過命令號，利用sCommand數(shù)組，獲得該命令的處理函數(shù)。
sComand[]={
<...>
}
sComand 存在于Ril_command.h中。
&sComand[]=
<
{RIL_REQUEST_GET_IMEI, dispatchVoid, responseString},
{RIL_REQUEST_DIAL, dispatchDial, responseVoid},
{….}
>
dispatchXxx函數(shù)一般都放在在Reference-ril.c中，Reference-ril.c這個就是我們需要根據(jù)不同的Modem來修改的文件。
1.5 send_at_command框架
send_at_command是同步的，命令發(fā)送后，send_at_command將等待在s_commandcond，直到有sp_response->finalResponse。
2 read
loop@Atchannel.cRead loop是解決的問題是：解析從Modem發(fā)過來的回應(yīng)。如果遇到URC則通過handleUnsolicited上報的RIL_JAVA。如果是命令的應(yīng)答，則通過handleFinalResponse通知send_at_command有應(yīng)答結(jié)果。
對于URC，Rild同樣使用一個抽象數(shù)組@Ril.CPP.
static UnsolResponseInfo s_unsolResponses[] = {
#include "ril_unsol_commands.h"
};
并利用RIL_onUnsolicitedResponse將URC向上層發(fā)送。
3 Ril-d的整體數(shù)據(jù)流及其控制流示意圖
