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