Android(安卓)系统HAL 简介
文章出处:http://blog.csdn.net/shift_wwx/article/details/54964384
请转载的朋友标明出处~~
在 《Android,在争议中逃离 Linux 内核的 GPL 约束》一文中说明了android 中产生HAL的过程,简单来说就是为了满足商业需求,避开GPL 约束。
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被多个进程映射多次,会有代码的重入问题。
二、新的架构
新的代码架构使用的是module stub方式.Stub是存根或者桩的意思,其实说白了,就是指一个对象代表的意思。上层应用层或者框架层代码加载so库代码,so库代码我们称之为module,在Hal层注册了每个硬件对象的存根stub,当上层需要访问硬件的时候,就从当前注册的硬件对象stub里查找,找到之后stub会向上层module提供该硬件对象的operations interface(操作接口),该操作接口就保存在module中,上层应用或框架层再通过这个module操作接口来访问硬件。其架构如下:
以上分别介绍了Module架构和Stub架构,下面做一个对比:
在Module架构中,本地代码由so库实现,上层直接将so库映射到进程空间,会有代码重入及设备多次打开的问题。新的Stub框架虽然也要加载module库,但是这个module已经不包含操作底层硬件驱动的功能了,它里面保存的只是底层stub提供的操作接口,底层stub扮演了“接口提供者”的角色,当stub第一次被使用时加载到内存,后续再使用时仅返回硬件对象操作接口,不会存在设备多次打开的问题,并且由于多进程访问时返回的只是函数指针,代码并没有重入。
下一篇会继续说明HAL 实现过程和stub 架构
更多相关文章
- 将Eclipse代码导入到Android(安卓)Studio的两种方式
- Android之UI学习篇八:使用GridView实现九宫格的菜单
- Android(安卓)call setting 源码分析 从顶层到底层(上)
- Android与JS代码交互
- Android(安卓)怎么样使用shape
- Android架构组件Room的使用
- Android系统介绍及架构概览
- Android源码下载并绑定到Eclipse中
- android 百度地图的经度纬度问题