?Android的硬件訪問服務提供了一個APP調用硬件實現的方法模型。我們從上往下來看。應用層面對的都是一個個的服務叫service.比如電源管理服務，震動服務等等。應用層代碼首先就需要去查詢系統是否存在這么一個服務，或者目前是不是可以被獲取的。從這個角度，我們就牽扯出來兩個問題。a：既然去系統里面查找這么個服務，那么首先應該又什么地方注冊加入系統的。b:有了這么個服務，我也得創建一個接口函數來鏈接APP跟這個服務函數的橋梁。我們的應用APP通過這么一個橋梁來去訪問這個服務。
我們需要懟的就是這么個服務是怎么添加到系統的，以及他的前世今生。這個工作是由systemserver.java文件來做的。在 startotherservices函數中我們先去new 一個服務實例對象，然后再去addservice 將這個方法注冊到系統的service_manager.c這就是前面我說的系統。那么這個服務的方法是根據誰來實例化的呢？那么肯定會有一個class類來做，也就是說我們需要創建這么一個類。
APP操作的根源還是在底層，現在我們講好了service,那么我們還需要一個地方去注冊管理底層的方法。這個仍舊是在SystemServer.java里面集中管理。這個是通過Loadlibrary函數調用JNIonload。cpp這里面并沒有直接做JNI的處理，因為安卓各個方法如果都寫在這么一個文件里面就會顯得特別亂。我們繼續通過調用下一層的JNI文件來處理。這個JNI文件是需要隨著系統一起編譯的。后期我們沒改一次JNI就去編譯一次Anroid系統，太費勁了。我們就引入了Hal文件。我們的jni只需要提供標準的接口。hal文件去實現這些jni。而且這些hal文件不需要跟著系統一起編譯，我們還可以把他做成.so文件，加載到庫里。這樣同時還解決了保密問題。對吧。
說的還是挺繞的。簡而言之。我們把底層各種封裝處理，然后提供處理啊那么一個插頭（我們的service實例化后的方法就是一個插頭，里面包含了各種處理）。我們的應用層也使用一個插頭，當這倆插頭接到了一起，就實現了我們的安卓硬件訪問服務。

如果某個硬件資源只能被某一個應用使用，可以使用下面的方法訪問硬件：

JAVA APP--->JNI_OnLoad（）加載C庫---->將JAVA三個地方法與C庫函數進行關聯并注冊---->調用JAVA本地Native方法就可以訪問C庫的C接口------>進而訪問硬件驅動中的open, read, write，從進訪問硬件。
但是，以上場景僅限于只有一個APP使用這個硬件資源，如果有多個應用想要使用某個硬件時，如果還按上面方法，必須會造成硬件資源的沖突，所以此時需要有一種框架來解決這個問題。解決方案就是訪問硬件資源的程序只能并且只有一個，我們稱之為System Server, 其它要訪問這個硬件資源的APP必須要給Server發請求，由Server間接的操作硬件，從而實現資源的訪問。這個就稱之為硬件訪問服務。
關于硬件訪問服務需要注意以下幾點：1 System Server是由JAVA編寫的，所以它要想訪問硬件，必須要加載JNI的C庫(Loadlibrary).2 C庫的JNI_Onload函數里要注冊本地方法，分別調用各個硬件的函數來注冊本地方法。比如LED，振動器，有串口。。。等等。。3 System Server：(1)對每個硬件都要添加服務,add service前提需要實現的是：對每個硬件構造service,使用本地Native方法(2)對于(1)添加的服務就是向service_manager.c注冊，比如serialservice, vibratorservice, ledservice等。如果JAVA應用程序需要使用某些Service的時候，就需要通過這個Service_manager查詢及獲取相應的Service。
4 最終APP怎么使用？(1)APP使用之前需要獲得這個服務getService(2)最后就是使用這個服務了。執行Service的方法
以后修改硬件驅動的時候，把驅動文件放在hal里面,如hal_led.c，有幾個好處：(1)容易修改(2)很多公司不愿意開放其硬件操作，他們只提供so文件，出于保密的目的。試想一下，如果把硬件操作源代碼放到JNI文件里，如果要修改，需要編譯整個工程，此外，硬件源代碼暴露出來了,保密性不好。

分析一下：以上操作涉及到三個進程，?1 SystemServer進程：它提供的功能如下：---a: 它向service_manager.c注冊服務---b: 加載硬件Service JNI 的C庫---C: 接收其它app的硬件操作請求，訪問硬件資源
2 Service_Manager進程：負責硬件資源各種Service的注冊添加,以及接怍JAVA應用app的各種service查詢請求及資源的獲取。
3 JAVA應用APP進程，它其實是一個客戶端，它首先向Service_Manager查詢獲得某一個Service, 最后，把這個Service發送給SystemServer進程以請求相應的服務，
而以上三個進程之間的內部通信，主要依靠Android內核的Binder Driver系統進行內部進程間通信。這個Binder并不是linux內核自帶的，是google公司對linux內核進行修改添加的一個驅動程序，可實現更加高效的進程間通信。
ps:注冊Server與Service的區別，可以這么理解，Server服務器提供各種服務Services.



思考：如何實現一個硬件訪問服務。1 編寫JNI和HAL,以led為例，先編寫com_android_server_ledservice.cpp，用于注冊JNI本地方法。再編寫hal_led.c，里面就是實現open,read,write等硬件訪問接口。2 修改onload.cpp,調它調用com_android_server_ledservice.cpp內實現的函數，3 修改system server.java,?new ledservice()add ledservice()4編寫LEDService.java提供一個類，做接口用的，他自己是不能調用本地方法的。他是通過在systemserver.java中實例化對象提供接口來實現功能的！！這個地方要謹記，很容易讓人混沌不清。
5 編寫ILEDService.java接口給app使用。

?

總結

以上是生活随笔為你收集整理的Android硬件访问服务框架思想初识的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。