這里，先回顧一下智能手機的架構。目前，很多智能手機的硬件架構都是兩個處理器：一個處理器用來運行操作系統，上面可以跑應用程序，這個處理器稱作Application Processor，簡稱AP；另一個處理器負責和射頻無線通信相關的工作，叫Baseband Processor，簡稱BP。AP和BP芯片之間采用串口進行通信，通信協議使用的是AT指令。 什么是AT指令呢？AT指令最早用在Modem上，后來幾大手機廠商如摩托羅拉、愛立信、諾基亞等為GSM通信又設計了一整套AT指令。AT指令的格式比較簡單，是一個以AT開頭，后跟字母和數字表示具體功能的字符串。了解具體的AT指令，可參考相關的規范參考或手機廠商提供的手冊，這里就不再多說了。 在Android系統中，Rild運行在AP上，它是AP和BP在軟件層面上通信的中樞，也就是說，AP上的應用程序將通過Rild發送AT指令給BP，而BP的信息通過Rild傳送給AP上的應用程序。 現介紹在Rild代碼中常會碰到的兩個詞語： - 第一個solicited Respose，即經過請求的回復。它代表的應用場景是AP發送一個AT請求指令給BP進行處理，處理后，BP會對應回復一個AT指令告知處理結果。這個回復指令是針對之前的那個請求指令的，此乃一問一答式，所以叫solicitedResponse。 - 第二個unsolicited Response，即未經請求的回復。很多時候，BP主動給AP發送AT指令，這種指令一般是BP通知AP當前發生的一些事情，例如一路電話打了過來，或者網絡信號中斷等。從AP的角度來看，這種指令并非由它發送的請求所引起的，所以稱之為unsolicited Response。 上面這兩個詞語，實際指明了AP和BP兩種交互類型： - AP發送請求BP，BP響應并回復AP。 - BP發送通知給AP。 這兩種類型對軟件而言有什么意義呢？先來看Rild在軟件架構方面遇到的挑戰： - 有很多把AP和BP集成在一塊芯片上的智能手機，它們之間的通信可能就不是AT指令了。 - 另外，即使AP和BP通信使用的是AT指令，不同的手機廠商在AT指令上也會有很大的不同，而且這些都屬于商業秘密，所以手機廠商不可能共享源碼，它只能給出二進制的庫。 Rild是怎么解決這個問題的呢？結合前面提到的AP/BP交互的兩種類型，大體可以勾畫出圖9-7： :-:  圖9-7 Rild解決問題的方法 從上圖中可以看出： - Rild會動態加載廠商相關的動態庫，這個動態庫加載在Linux平臺上則使用dlopen系統調用。 - Rild和動態庫之間通過接口進行通信，也就是說Rild輸出接口供動態庫使用，而動態庫也輸出對應的接口供Rild使用。 - AP和BP交互的工作由動態庫去完成。 Rild和動態庫運行在同一個進程上，為了方便理解，可把這兩個東西分離開來。 根據上面的分析可知，對Rild的分析包括兩部分： - 對Rild本身的分析。 - 對動態庫的分析。Android提供了一個用作參考的動態庫叫libReference_ril.so，這個庫實現了一些標準的AT指令。另外，它的代碼結構也頗具參考價值，所以我們的動態庫分析就以它為主。 分析Rild時，為書寫方便起見，將這個動態庫簡稱為RefRil庫。