By 高焕堂 2011/09/04
[ IT史上最完整、最经典的软件框架开发技术宝典 (上百篇经典文章&eBooks) ]
[Go Back]
HAL(Hardware Abstraction Layer)技术观点(2)：
JNI Native Code该属于Android的那一块呢?
许多人使用NDK工具去开发C/C++层级的JNI Native Code。也懂得如何将Native Code封装成为*.so链接库，进而将其打包到APK里。然而，看看下图的Android 架构图1，却看不出到底这JNI Native Code是属于哪一部分?
图1 Android基本架构
Android 专家Jollen在其<<Android 的 HAL 技术, #1: 简介与发展现况>>文章里写到：
“过去的 libhardware_legacy 作法，比较是传统的module方式，也就是将 *.so 档案当做shared library来使用，在 runtime(JNI 部份)以 direct function call 使用 HAL module。透过直接函数呼叫的方式，来操作驱动程序。”
在Jollen的观点里，JNI Native Code是属于Android Runtime的一部分，如下图：
图2a Jollen的观点(第1种观点)
图2b Jollen的观点(第1种观点)
除了上述的Jollen观点之外，还有其它不同的观点，例如Albert Chen在其文章：
http://jinguo.javaeye.com/blog/689242 里就把JNI独立出来，既不属于Runtime也不属于Libraries部分。如下图：
图3 Albert Chen的观点(第2种观点)
此外，还有许多人将JNI Native Code归到C/C++层的Libraries里，如下图4：
图4 另一个观点(第3种观点)
大家都知道，观点本身并没有对或错，因为它并非本质或真理。只是这些观点，在文章里都是幕后的知识，并未呈现于文章里。如果没有特别留意，并不容易正确理解文章作者的涵意。[歡迎光臨 高煥堂 網頁： http://www.cnblogs.com/myEIT/ ]
例如，知道了上述Jollen的观点(第1种观点)，就能轻易理解他的文句：
“Stub 向 HAL「提供」操作函数（operations），而 runtime 则是向 HAL 取得特定模块（stub）的 operations，再 callback 这些操作函数。”
的文句涵意了。再如，知道了上述的第3种观点，就能轻易看懂下图：
图5a 第3种观点之例(一)
图5b 第3种观点之例(二) (PS. 上图摘自”Android HAL and Graphics”(http://soulbuzz.net/?p=175) 一文。)
此观点让VM和Core Libraries两个角色退居到幕后。凸显了：
AP -> JNI Native Code -> Native Service -> HAL Stub -> Kernel Driver
的简洁架构。Jollen在其文章里也写到：
“谈了许多「Android Service」以及「HAL Stub」，这里再补充一点。Android操作系统启动时，会执行一个process称为servicemanager。Servicemanager process负责管理、提供并保存「Android Service」。Android Service为Java层，因此接下来会透过JNI来呼叫C/C++层的Native Service。广义来说，Native Service也提供Runtime的功能，即Core Library层。Runtime的重要工作之一为「取得HAL Stub所提供的API」，因此这是撰写完整Native Service的前哨站。”
可以知道Jollen把Native Service归到runtime部分(即上述的第1种观点)，而且归入Core Library层。从上图5a 可以看到另一种观点(即上述的第1种观点)。◆
[Go Back]
