一位同事離職了,其實嚴格說來是我的長官。跟他平常並沒有機會交談,一直到很後來才偶然的有機會跟他聊天。 其實,他還滿有想法的,平常也有閱讀的習慣。
這真的很難得,在上班之後還能在閒暇之虞讀點閒書。因為我認識的大部分的上班族回家之後都是發呆或躺平的。
其實想說明的是,有跟他討論到一些他正在閱讀的書,以後有時間也要去買來看。1. 雪球 2. 一個投機者的告白 3. 黑天鵝效應 4. 投資金律
2009年8月5日 星期三
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要不要被執行呢??
而這,就會是推託爭執與各說各話的起點了。
讓我想到夫妻與男女朋友的相處之道。
底下是一張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要不要被執行呢??
而這,就會是推託爭執與各說各話的起點了。
讓我想到夫妻與男女朋友的相處之道。
訂閱:
文章 (Atom)
標籤
- 生活
- 閒聊
- android
- arm
- assembly
- beaglebone black
- bl
- business trip
- car rental
- coupon
- cross compile
- cygwin iphone toolchain install build
- dropbear
- embedded system
- find
- GDB
- gdbserver
- grep
- instruction
- io
- kinect
- life
- linux
- openni
- programming
- QT visual studio express 2008 install
- qualcomm
- qualcomm business trip
- replace
- rild
- san diego
- ssh
- substitute
- system realated
- toolchain
- ubuntu
- vim ^M 換行
- Windows CE VM