Android系统架构

图1.1  Android系统架构
从上图可看出，Android系统大体可分为五层，从下往上依次是：

Linux内核层：包含了Linux内核和一些驱动模块，驱动模块主要对应于相应硬件的驱动。Binder驱动除外，Binder驱动本身不对应任何硬件，所有操作都在软件层。
硬件抽象层(HAL)：该层封装了硬件实现细节和参数，以保护移动设备厂商的利益（厂商定制部分在此层实现）。
Libraries：该层提供动态库、Android运行时库、Dalvik虚拟机等。这一层大部分都是用C或C++编写，因此也可看成是Native层。
Framework层：我们常用API就在此层，该层通常由java语言编写，因此也可以称为Java Framework。
  Applications层：这一层属于安卓应用程序层，系统的联系人、打电话以及我们编写的应用程序等都属于该层。

       由上面介绍可看出， Android应用程序以及Framework层都是使用java语言编写而成，Android系统为我们搭建了一个java世界，而这个世界的运转依赖于Libraries的Native世界。这两个世界的交互通过JNI完成。JNI（Java Native Interface），意为Java本地接口。通过JNI，我们可以在java程序中调用C/C++函数，也可以在C/C++程序中调用java方法。如图1.2所示：



图2 java世界与Native世界交互

        实际上，在开发应用时，我们可以使用java语言编写，也可以使用C/C++语言编写，但是当我们使用C/C++语言编写的时候，需要使用JNI技术进行衔接，以在java层中可以调用C/C++函数。包括Framework层，也有部分使用C/C++语言编写的函数，此时当我们在Applications层需要调用这些函数时，中间使用JNI技术，达到复用的目的。因此我们可以得出一个结论：在安卓中，可以使用java语言也可以使用Native语言（C/C++）进行开发实现某些功能，然而由于安卓的上层（Activity/Service等）是用java语言编写，因此当你需要使用Native语言编写的功能，你必须通过JNI技术，达到在java层调用Native函数的目的。

为什么要创建一个与Native无关的JNI技术？

主要基于以下考虑：

承载java世界的虚拟机是用Nativie语言编写，而虚拟机又运行在具体的平台上，所以虚拟机本身无法做到平台无关。然而有了JNI技术后，就可以对Java层屏蔽不同操作系统平台（如Windows和Linux）之间的差异。以此来实现Java本身的平台无关性
在Java语言诞生之前，很多程序都是使用Native语言编写，java出现后，虽然得到了迅速发展，但仍无法将软件世界彻底改朝换代，于是便有了这种的方法。在已用Native语言实现的功能模块中，通过JNI技术，在java中使用它们，以免重复制造轮子，此外，一些要求效率和速度的场合还是需要Native语言参与。

Android系统为什么要把对硬件的支持分为两层来实现？

       Android系统通过硬件抽象层（Hardware Abstract Layer, HAL）和Linux内核层实现对硬件的支持，HAL位实现在用户空间， 向上提供硬件服务，向下屏蔽硬件驱动模块的实现细节，而Linux内核则实现在内核空间。传统的Linux系统对硬件的支持是完全实现在“内核空间”中，也就是把硬件的支持完全实现在硬件驱动模块中。然而，Linux内核源代码是遵循GPL协议的，如果Android系统中所使用的Linux内核增加或者修改了代码，就必须将这部分代码公开，这样相当于暴露了硬件实现细节和参数，也就损害了移动设备厂商的利益。而Android系统源代码是遵循Apache
License协议，它允许移动厂商增加或修改Android系统源代码的时候不必公开这些代码。因此把对硬件的支持需要隐藏的部分实现在用户空间，封装硬件的实现细节和参数，也就达到了保护移动设备厂商的利益。