Android 的 HAL 技術，1： HAL的過去現在未來簡介-車機
Android 的 HAL 技術，2： 采用Service架構方式-車機
前面兩篇文章提到「采用Service架構整合HAL的做法」。本文再針對HAL如何采用Service架構與架構整合做一個概念的介紹。
Android的Service分為二種：Android Service與Native Service。
Android Service
Android Service又稱為Java Service，是實作在架構層（framework）裡的「Server」。這裡所講的「Service」是System Service，又稱為Server，與APP設計上所讨論的Service（android.app.Service）不同。Android Service以Java編寫。
android.app.Service
Service在Android應用程式裡四大實體之一。Android的應用程式不光是需要有圖形界面來進行互動，有時也會需要在沒有互動的情況下進行的操作，比如下載下傳、更新、監聽等。比如目前對我們網絡生存影響如此之大的社交網絡、或是更老一些聊天工具，總需要這類應用程式可以一直在背景運作，以等待可能過來的消息。：
Service擁有一部分Activity所無法完成的能力。一是背景運作，有時我們并不希望有過多對話框來影響使用者體驗，開機自動啟動，便可默默地在背景運作。另一特性，就是不被Activity生命周期所管理，Activity處于完全活躍的周期是onResume()與onPause()之間，如果這周期之外發生了事件，實際上Activity構成的執行部分也不會被執行到，進而無法響應處理，但Service由于本身過于簡單，則會通過一定的輔助手段來達到這個目标。
從Android應用程式的設計原理來看，Service同樣也是主線程裡執行的（這點尤為重要，Service由于在主線程裡執行，于是也會因為執行耗時操作而觸發ANR）。一個應用程式既然可以通過拓展Activity得到可互動的代碼邏輯，同樣也可以通過拓展Service來得到不互動在背景執行的邏輯。如下圖加強部分所示：
android.app.Service
Android Service
Native Service
Native Service則是實作在Runtime層裡的Server。
Native Service，這是Android系統裡的一種特色，就是通過C++或是C代碼寫出來的，供Java進行遠端調用的Remote Service，因為C/C++代碼生成的是Native代碼（機器代碼），于是叫Native Service。随着Android系統的性能需求越來越高，Native Service需求将越來越高。
Native Service的實作，相當于RemoteService的hack版，相當于直接将Remote Service裡在Java與C++代碼之間的互動設計偷換掉。Java代碼走到JNI實作的BinderProxy對象的transact()方法之後，便直接進入到Native實作BBinder對象，然後一直通過IPCThreadState對象發送Binder消息，在另一個實作了對應IBinder接口的程序空間裡的IPCThreadState對象會接收到這一Binder消息，再通過JNI回調到Java環境裡的Binder對象所實作的onTransact()方法，于是就得到Remote Service。
如果需要通過Native代碼來提供這樣的服務，實際上也很簡單，從IBinder接口的Stub端對象的原理可以看出，如果我們在回調Java的JNI之前将代碼調用截斷，直接通過Native代碼來實作onTransact()方法，則可以完成Service的Stub端實作。同時，出于實作角度的考慮，RemoteService接口不光可以服務于Java環境，也可以同時服務于Native環境，于是我們也可以提供Native環境裡的BinderProxy代碼，就可以直接通過BpBinder對象的transact()方法來發送Binder消息，此時就可以Native環境裡的Proxy端。
NativeService是由libbinder提供的一種機制，相當于是Java環境Remote Service的底層”Hack”實作。而通過Native Service，我們得到Java環境所不具備的一些新的特質：
1) 性能更高。性能上的差異性取決于執行時的不同上下文環境，但通常來說，Native代碼總會有比Java這種解釋型語言高得多的執行效率。
2) 使用同一種語言程式設計，更加容易了解與調試。Java語言不能直接進行系統調用，必須透過JNI來調用C代碼來通路系統功能。而NativeService則完全不同，C++具備直接進行系統調用的能力，于是在通路作業系統或是硬體功能時，不再需要JNI，可以直接進行調用，代碼實作上會更加統一。
3) 自動化GC，Native态的Binder，與Java協作時被自動切入到Dalvik虛拟機的GC管理，也能使用類似于Java環境的自動化垃圾回收。同時，這種GC機制可以通過RefBase進行進一步拓展。
4) 缺點：不能使用AIDL，編碼工作量更大。
5) 缺點：跟Java的Binder域程式設計環境功能重疊，也有可能會出錯。比如Binder指令的定義，在Java與Native Service互動時，在Java環境與C++環境都要有各自一份拷貝。
架構設計上，我們有二個選擇：
一個是實作Android Service、再透過JNI與HAL stub溝通；
另一個選擇是，跳過Android Service，讓Application（Manager API）直接與Native Service溝通。
未來的Android發展趨勢，應會以第二種做法為主，即Manager API直接與Native Service溝通，以達到更好的效能表現。
參考：
https://www.jollen.org/blog/2009/11/android-hal-android-native-service.html
https://blog.csdn.net/21cnbao/article/details/8086487