Android Hal层简要分析

 Android Hal层简要分析

    Android Hal层（即 Hardware Abstraction Layer）是Google开发的Android系统里上层应用对底层硬件操作屏蔽的一个软件层次，说直白点，就是上层应用不必关心底层硬件具体是如何工作的，只需要调用底层提供的统一接口即可，这种设计思想广泛的存在于当前的软件的架构设计里。个人感觉，以前在Linux系统下学习驱动程序的开发时，当驱动程序完成时，我们会编写相应的用户空间测试程序，感觉这就有点类似此处的硬件抽象层的工作，只不过原来是把测试程序用交叉工具链编译成可执行程序然后下载到开发板上进行验证，而在Android的硬件抽象层中，将测试程序再进行了一次封装，把测试接口封装起来传递给上一层调用，这样就能隐藏硬件的实现细节和参数。

      其实Android系统里完全可以没有HAL硬件抽象层，上层应用可以直接通过API调用到底层硬件，但是Android自出现一直打着开源的旗号，而一些硬件设备厂商由于商业因素，不希望把自己的核心代码开源出来，而只是提供二进制的代码。另外，Android系统里使用的一些硬件设备接口可能不是使用的Linux Kernel的统一接口，并且还有GPL版权的原因，所以Google在Android架构里提出了Hal的概念，这个HAL其实就是独立的意思，Android系统不仅依赖于某一个具体的硬件驱动，而是依赖于Hal代码，这样，第三方厂商可以將自己不开源的代码封装在HAL层，仅仅提供二进制代码。在具体分析Android硬件抽象层之前，先从下图了解下其在整个Android系统架构中所处的位置：

Android Hal架构分为两种：

①旧的架构module

②新的架构module stub

下面我们就具体分析下两种架构各自的特点：

一 Module架构

     Android用户应用程序或者框架层代码由JAVA实现，Java运行在Dalvik虚拟机中，没有办法直接访问底层硬件，只能通过调用so本地库代码实现，在so本地代码里有对底层硬件操作的代码，如下图所示：

       可以这样说，应用层或者框架层Java代码，通过JNI技术调用C或C++写的so库代码，在so库代码中调用底层驱动，从而实现上层应用操作底层硬件的目的。实现硬件操作的so库为module.

其实现流程如下图所示：

       这种设计架构虽然满足了Java应用访问硬件的需要，但是，使得我们的代码上下层次间的耦合太高，用户程序或者框架代码必须要去加载module库，如果底层硬件有变化，module要从新编译，上层也要做相应变化，另外，如果多个应用程序同时访问硬件，都去加载module，同一module被多个进程映射多次，会有代码的重入问题。

二 新的Hal架构：

     新的代码架构使用的是module stub方式.Stub是存根或者桩的意思，其实说白了，就是指一个对象代表的意思。上层应用层或者框架层代码加载so库代码，so库代码我们称之为module，在Hal层注册了每个硬件对象的存根stub，当上层需要访问硬件的时候，就从当前注册的硬件对象stub里查找，找到之后stub会向上层module提供该硬件对象的operations interface（操作接口），该操作接口就保存在module中，上层应用或框架层再通过这个module操作接口来访问硬件。其架构如下：

以上分别介绍了Module架构和Stub架构，下面做一个对比：

  在Module架构中，本地代码由so库实现，上层直接将so库映射到进程空间，会有代码重入及设备多次打开的问题。新的Stub框架虽然也要加载module库，但是这个module已经不包含操作底层硬件驱动的功能了，它里面保存