在上一篇日記裡,我們介紹了Android HAL的大概念。接下來,將慢慢地進行細部的分析與研究。首先,我們先針對HAL的現況先做討論,後續再針對HAL的設計提出觀念。
圖1:採用Service架構與不採用Service架構
如圖1,應用程式存取驅動程式的過程,可區分為以下二種:
採用Service架構方式是比較標準的做法,即圖上藍色線的部份;紅色線的部份為非Service架構式的做法。先前,在「Android 驅動開發關鍵技術:HAL及移植要領」演講中最後所提出的一個LED範例,即是一種非架構式的做法,簡報上有一段範例程式碼,歡迎下載參考。
採取Service架構的方式,是建議的做法,當然因為這是標準架構,也應該採用。
Service在Android框架裡的角色是「存取底層硬體」,往上層的話,可以和應用程式溝通。因此,採用標準的Service做法,好處是在資料存取(data communication)的處理較為系統化。這方面,Android提供了標準的處理架構,後續再進行討論。
圖上的「core libraries」即是Service程式碼的實作,也就是,Android應用程式透過JNI(Dalvik)來到Service這一層,再透過Service載入*.so檔;而非標準做法則是讓應用程式直接透過JNI來載入*.so檔。
不使用Service架構
紅色的過程,因為不使用Service架構,因此「框架整合」的工作量比較小,甚致大部份的實作都不需要改動框架本身。這樣的做法,就有點像是「跳過framework」的方式;相對的,此時應用程式開發者需要考慮的設計議題就比較多。
例如,當遇到block operation時,是否需要獨立的Java thread來處理?
Jollen's Blog 使用 Github issues 與讀者交流討論。請點擊上方的文章專屬 issue,或 open a new issue
您可透過電子郵件 jollen@jollen.org,或是 Linkedin 與我連絡。更歡迎使用微信,請搜尋 WeChat ID:jollentw