Android radio interface layer

    其實Android很奇怪，明明是linux系統，ap卻偏偏要跑java。也因此，硬要多一層java與底層api間的橋樑，作為轉化劑，其中的目的就是透過android制定好的api去執行不同解決方案的modem。也因此多了很多麻煩。當然也是有他的好處，就是既然介面都訂好了，剩下的就是去配合不同的方案而產生不同的程式碼。

    底下是一張google自己的投影片，搜尋anatomy-google-io就找的到了。

    可以看到jave跟底層的溝通是透過socket和中間一個叫做rild的daemon program，這個daemon到也沒做什麼事情，只是init自己的event thread，這裡的event就是指每個socket listen到的結果，就是用select()去聽socket，有結果就做對應的事情。說穿了也就是收jave來的request和要送給java的request result。然後呢，他會去load oem的radio library並且做library的init，除了初始library的狀態之外，還會得到一組library必須提供的call back function的address然後利用這組call back functino跟library溝通。定義了五支call back。ex: onRequest(); onRequestComplete()之類的。

    如果是我，在這樣的情形之下，我會怎麼設計我的radio library呢?首先一定是來兩個queue，伴隨著相對應的兩支worker thread，一個處理daemon送來的request，然後往下送，另一個則相反，處理底層來的事件然後回送給daemon。這樣雖然複雜，但是萬無一失，屬於標準設計，library自我隔離於外界，專心於處理本份之上。

    所以每個onRequest()都會把資料put到library中處理request的queue然後給library的thread去按照順序楚哩。因為有了queue所以每個request會是mutual exclusive，因為我們可以等該request處理完畢之後，才去處理下一個。這樣也模擬了android原本對底層telephony的精神，也就是at command，而at command是mutual exclusive的。
    否則的話，如果有某個request的執行必須依賴之前的request的執行的結果的話，會有可能的錯誤發生，好比說在end call之後來一個switch call，那這個switch的request要不要被執行呢??
    而這，就會是推託爭執與各說各話的起點了。
    讓我想到夫妻與男女朋友的相處之道。