HAL层

https://outfox.blog.csdn.net/article/details/8069588
看这个上面这个大牛分析得很仔细。

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，同一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第一次被使用时加载到内存，后续再使用时仅返回硬件对象操作接口，不会存在设备多次打开问题，并且由于多进程访问时返回的只是函数指针，代码没有重入问题。

2.HAL Stub框架分析

HAL stub的框架比较简单，三个结构体、两个常量、一个函数，简称321架构，它的定义在：

@hardware/libhardware/include/hardware/hardware.h

@hardware/libhardware/hardware.c

/* 
每一个硬件都通过hw_module_t来描述，我们称之为一个硬件对象。你可以去“继承”这个hw_module_t，然后扩展自己的属性，硬件对象必须定义为一个固定的名字：HMI，即：Hardware Module Information的简写，每一个硬件对象里都封装了一个函数指针open用于打开该硬件，我们理解为硬件对象的open方法，open调用后返回这个硬件对应的Operation interface。
*/
struct hw_module_t｛
	uint32_t tag;			// 该值必须声明为HARDWARE_MODULE_TAG
	uint16_t version_major;	// 主版本号
	uint16_t version_minor; 	// 次版本号
	const char *id;			//硬件id名，唯一标识module
	const char *name;		// 硬件module名字
	const char * author;		// 作者
	struct hw_module_methods_t* methods;	//指向封装有open函数指针的结构体
	void* dso;				// module’s dso
	uint32_t reserved[32-7];	// 128字节补齐
｝;
 
/* 
硬件对象的open方法描述结构体，它里面只有一个元素：open函数指针
*/
struct hw_module_methods_t{
	// 只封装了open函数指针
	int (*open)(const struct hw_module_t* module, const char * id,
		struct hw_device_t** device);
};
 
/*
硬件对象hw_module_t的open方法返回该硬件的Operation interface，它由hw_device_t结构体来描述，我们称之为：该硬件的操作接口
*/
struct hw_device_t{
	uint32_t tag;				// 必须赋值为HARDWARE_DEVICE_TAG
	uint32_t version;				// 版本号
	struct hw_module_t* module;	// 该设备操作属于哪个硬件对象，可以看成硬件操作接口与硬件对象的联系
	uint32_t reserved[12];			// 字节补齐
	int (*close)(struct hw_device_t* device);	// 该设备的关闭函数指针，可以看做硬件的close方法
};

上述三个结构之间关系紧密，每个硬件对象由一个hw_module_t来描述，只要我们拿到了这个硬件对象，就可以调用它的open方法，返回这个硬件对象的硬件操作接口，然后就可以通过这些硬件操作接口来间接操作硬件了。只不过，open方法被struct hw_module_methods_t结构封装了一次，硬件操作接口被hw_device_t封装了一次而已。

那用户程序如何才能拿到硬件对象呢？

答案是通过硬件id名来拿。

我们来看下321架构里的：两个符号常量和一个函数：

// 这个就是HAL Stub对象固定的名字
#define HAL_MODULE_INFO_SYM         	HMI
// 这是字符串形式的名字
#define HAL_MODULE_INFO_SYM_AS_STR  	"HMI"
//这个函数是通过硬件名来获得硬件HAL Stub对象
int hw_get_module(const char *id, const struct hw_module_t **module);

当用户调用hw_get_module函数时，第一个参数传硬件id名，那么这个函数会从当前系统已经注册的硬件对象里查找传递过来的id名对应的硬件对象，然后返回之。

从调用者的角度，我们基本上没有什么障碍了，那如何注册一个硬件对象呢？

很简单，只需要声明一个结构体即可，看下面这个Led Stub注册的例子：

const struct led_module_t HAL_MODULE_INFO_SYM = {
    common: {	// 初始化父结构hw_module_t成员
        tag: HARDWARE_MODULE_TAG,
	    version_major: 1,
	    version_minor: 0,
	    id: LED_HARDWARE_MODULE_ID,
	    name: "led HAL Stub",
	    author: "farsight",
	    methods: &led_module_methods,
	}, 
	// 扩展属性放在这儿
};