[Android的系統移植與平台開發]初識HAL

1.      HAL的module與stub

HAL（Hardware AbstractLayer）硬件抽象層是Google開發的Android系統裡上層應用對底層硬件操作屏蔽一個軟件層次，說白了，就是上層的應用不用關心底層硬件具體如何工作的，只要向上層提供一個統一的接口即可，這種設計思想廣泛的存在於當前的軟件架構設計裡。

嚴格來講，Android系統裡完全可以沒有HAL硬件抽象層，上層應用層可以通過API調用到底層硬件，但是Android自出現開始一直打著開源的旗號，而一些硬件廠商由於商業因素，不希望自己的核心代碼開源出來，而只是提供二進制代碼。另外，Android系統裡使用的一些硬件設備接口可能不是使用的Linux Kernel的統一接口，並且還有GPL版權的原因，所以Google不利己，在Android的架構裡提出了HAL的概念，這個HAL其實就是硬件獨立的意思，Android系統不依賴於某一個具體的硬件驅動，而是依賴於HAL代碼，這樣，第三方廠商可以將自己不開源的代碼封裝在HAL層，僅提供二進制。

HAL的架構分為兩種：

Ø  舊的架構module

Ø  新的架構modulestub

1.1 module架構

舊的架構比較好理解，Android用戶應用程序或框架層代碼由Java實現，Java運行在Dalvik虛擬機中，沒有辦法直接訪問底層硬件，只能通過調用so本地庫代碼實現，在so本地庫代碼裡有對底層硬件操作代碼，如下圖所示：

也就是說，應用層或框架層Java代碼，通過JNI技術調用C或C++寫的so庫代碼，在so庫代碼中調用底層驅動，實現上層應用的提出的硬件請求操作。實現硬件操作的so庫為：module。

其實現流程如下圖：

由此可見，Java代碼要訪問硬件效率其實挺低的，沒有C代碼效率高，但是Android系統在軟件框架和硬件處理器上都在減少和C代碼執行效率的差距，據國外測試的結果來看，基本上能達到C代碼效率的95%左右。

這種設計架構雖然滿足了Java應用訪問硬件的需要，但是，使得我們的代碼上下層次間的耦合太高，用戶程序或框架代碼必須要去加載module庫，如果底層硬件有變化，moudle要重新編譯，上層也要做相應的變化，另外，如果多個應用程序同時訪問硬件，都去加載module，同一設備被打開多次，還有代碼的重入問題。因此，Google又提出了新的HAL架構。

1.2 新的HAL架構

新的架構使用的是module stub方式。Stub是存根或樁的意思，其實說白了，就是指一個對象代表的意思。由上面的架構可知，上層應用層或框架層代碼加載so庫代碼，so庫代碼我們稱為module，在HAL層注冊了每個硬件對象的存根stub，當上層需要訪問硬件的時候，就從當前注冊的硬件對象stub裡查找，找到之後stub會向上層module提供該硬件對象的operations interface（操作接口），該操作接口就保存在了module中，上層應用或框架再通過這個module操作接口來訪問硬件。如下圖，以Led為例的示意圖：

Led App為Android 應用程序，Led App裡的Java代碼不能操作硬件，將硬件操作工作交給本地module庫 led_runtime.so，它從當前系統中查找Led Stub，查找到之後，Led Stub將硬件驅動操作返回給module，Led App操作硬件時，通過保存在module中的操作接口間接訪問底層硬件。

問題來了：

Ø  麻煩，覺得比module方式復雜

Ø  硬件對象怎樣注冊為stub？

Ø  上層如何查找硬件對象的stub?

“麻煩”是確定的，但是Google這麼聰明的公司不可能是光制造麻煩的公司，肯定是考慮到其它的優越性才使用這種方式。

1.3Module架構與Stub構架對比

在Module架構中，本地代碼由so庫實現，上層直接將so庫映射進進程空間，會有代碼重入及設備多次打開的問題。新的Stub框架雖然也要加載module庫，但是這個module已經不包含操作底層硬件驅動的功能了，它裡面保存的只是底層Stub提供的操作接口，底層Stub扮演了“接口提供者”的角色，當Stub第一次被使用時加載到內存，後續再使用時僅返回硬件對象操作接口，不會存在設備多次打開問題，並且由於多進程訪問時返回的只是函數指針，代碼沒有重入問題。