最近和同事交流，多次听到HAL层，由于小松以前主要负责应用软件，所以几乎没听说过这一层，搜了一下图片，发现他全名为Hardware Abstraction Laye（硬件抽象层），位于Linux Kernel和FramWork之间，是抽象底层接口传递给上层的，但是我转念一想，如果是控制硬件的话其实这个HAL层完全可以归入Linux Kernel中嘛，难道他还有别的作用？
所以今天呢，小松就来好好研究研究这个层的作用与原理
存在的意义
Hardware Abstraction Layer 为硬件抽象层，我们知道，虽然android应用层使用java或者kotlin语言，但是控制设备的代码一般都是用C/C++的，这里的C/C++接口是以so库的形式存在项目中，然后java通过jni调用so库，那么so库就会继续往下调用设备，这些设备包括Audio，Camera，BlueTooth等等
但是现在有一个问题，比如说小米手机给“拍摄月亮”这一需求进行了底层的算法优化，并提供给其他厂商接口调用，该怎么办？
首先，为了保护知识产权，不能提交到下面的Linux Kernel层，因为这一层是开源的
所以android虽然在内核开源，但是用户空间是可以选择不开源的，所以，用户空间保留了这么一个“黑箱”，厂商自己有知识产权不愿意公开的代码就可以以二进制方式放在里面，对外提供接口，这样自己的代码不会泄漏，别人也能用到自己的产品
另外，还有一个重要原因是，Hardware Abstraction Layer顾名思义，屏蔽了不同硬件设备的差异，不管底层硬件如何变化，使用HAL接口的代码也可以不受影响，所以，通过HAL来控制底层硬件对于开发者来说比较稳定
如下图，类似一个相机控制应用，“拍摄月亮”的算法就可以放在HAL层中，控制路径为 app应用 -> Stub -> HAL Driver -> Kernel Driver
架构
321架构
HAL层由三个结构体，两个常量，一个函数构成，所有的模块需要遵循这一架构
三个结构体
/**
* Every hardware module must have a data structure named HAL_MODULE_INFO_SYM
* and the fields of this data structure must begin with hw_module_t
* followed by module specific information.
*/
typedef struct hw_module_t {
/** tag must be initialized to HARDWARE_MODULE_TAG */
uint32_t tag;
......
typedef struct hw_module_methods_t {
/** Open a specific device */
int (*open)(const struct hw_module_t* module, const char* id,
struct hw_device_t** device);
} hw_module_methods_t;
/**
* Every device data structure must begin with hw_device_t
* followed by module specific public methods and attributes.
*/
typedef struct hw_device_t {
/** tag must be initialized to HARDWARE_DEVICE_TAG */
uint32_t tag;
......其中 hw_module_t依赖hw_module_methods_t，内部的open函数可以被重载，主要存放是具体模块的信息
比如说可以定义一个camera_module_t重载open函数
hw_device_t主要是和硬件设备相关的操作
两个变量与一个函数
# define HAL_MODULE_INFO_SYM HMI
# define HAL_MODULE_INFO_SYM_AS_STR "HMI"
int hw_get_module(const char *id, const struct hw_module_t **module);在上层调用hw_get_module时，这两个变量可以找到模块入口，重载之前的open函数，从而获取hw_device_t
也就是说，上层首先调用hw_get_module，通过两个变量获取到三个结构体，从而访问对应的【实现函数】
整个逻辑是不是很简单？“拍摄月亮”这样的算法就可以放在【实现函数】中
参考文章
【Android】HAL层浅析
