Android系统架构概述
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
应用层中的应用，时刻都在与这些系统服务打交道。每一次构造窗口、处理用户交互事 件、绘制界面、获得当前地理信息、了解设备信息等操作，都是在各个系统服务的支持下实 现的。
而对于开发者而言，框架层最直观的体现就是 SDK，它通过一系列的 Java 功能模块，来 实现应用所需的功能。SDK 的设计决定了上层应用的开发模式、开发效率及能够实现的功能 范畴。因此，对于开发者而言，关注 SDK 的变迁是一件很有必要的事情，SDK 每个新版本的 诞生，都意味着一些老的接口会被调整或抛弃，另一些新的接口和功能火热出炉。开发者不 但要查看和关注那些被修改的接口，来检查应用的兼容性，并采取相应的策略去适应这些变 化，更重要的是，开发者还要追踪新提供的接口，寻找改进应用的机会，甚至是寻求开发新 应用的可能。
为了提升 Android 应用的执行效率，从垃圾回收器(Garbage Collection，GC)到编译器， Dalvik 一直在各个方面进行优化。经常可以听到这样的消息：“新版本的 Android 系统，比上 一个版本的效率高了 x 倍。”这大都是改善 Dalvik 的效果。在 Android 2.2 中，Dalvik 引入了 对 JIT(Just-in-time)编译的支持，将上层应用的执行效率提升了 2～4 倍，开启了 Android 发展 的新篇章。
1.1.3 运行时
和所有的 Java 程序运行平台一样，为了实现 Java 程序在运行阶段的二次编译， Android 为它们提供了运行时(Runtime)的支撑。
Android 的运行时由 Java 核心类库和 Java 虚拟机 Dalvik 共同构成。Java 核心类库涵盖了 Android 框架层和应用层所要用到的基础 Java 库，包括 Java 对象库、文件管理库、网络通信 库，等等。
小贴士 从 Android 2.3(API 9)开始，新增了 android.app.NativeActivity 类，它是通过调用
Fra Baidu bibliotek
预定义的 JNI 接口来实现的。开发者可以基于 NDK，通过 C/C++语言来实现具体功能。这就 意味着，开发者仅通过 C/C++语言就能实现整个应用。这对于游戏开发者而言是一大喜讯， 但由于控件在 Android 中并没有 Native 的实现，普通的应用开发者通常还是需要通过 Java 来实现上层界面。
本文的后续内容将针对以上各层逐一进行分析。
1.1.1 应用层
对于普通的用户而言，只能通过具体的应用来判断移动平台的优劣。即便一个移动平台 具有最华丽的技术，但是如果不能给用户提供最得心应手的应用，顶多也只能赢得无冕之王 的名头，而无法抓住用户的心，赢得市场的认可。
Android 应用层由运行在 Android 设备上的所有应用共同构成，它不仅包括通话、短信、 联系人等系统应用(随 Android 系统一起预装在移动设备上)，还包括其他后续安装到设备中 的第三方应用。
从系统设计的角度来看，Android 期望框架层是所有应用运行的核心，参与到应用层的 每一次操作中，并进行全局统筹。Android 应用的最大特征是基于组件的设计方式。每个应 用都由若干个组件构成，组件和组件之间并不会建立通信信道，而是通过框架层的系统服务， 集中地调度和传递消息。这样的设计方式相当于增加了一个中间层，该层了解所有组件的状 况，可以更智能地进行协调，从而提升了整个系统的灵活性。
为了帮助游戏和图形图像处理等领域的开发者搭建更高效的应用，Android 将数学函数 库、OpenGL 库等核心类库以 NDK 的形式提供给开发者，开发者可以基于 NDK 更高效地构 建算法，进行图形图像绘制。从实践的角度看，只要能获取到底层类库的头文件信息，开发 者就可以逾越 NDK 的界限，用其他核心类库的接口进行开发。但这样做的危险之处在于兼 容性差，Android 在版本变迁时，可能会替换或修改一些类库接口或实现，这就会导致依赖 于这些类库的应用无法运行。而 NDK 提供的都是稳定的类库实现，不会再做修改，以保证 使用 NDK 的应用具有向上的兼容性。
Linux 之于 Android 最大的价值，便是其强大的可移植性。Linux 可以运行在各式各样的 芯片架构和硬件环境下，而依托于它的 Android 系统，也便有了强大的可移植性。同时，Linux 像一座桥梁，将 Android 的上层实现与底层硬件连接起来，使它们可以不必直接耦合，因此， 降低了移植的难度。
第三方应用都是基于 Android 提供的 SDK(Software Development Kit)进行开发的，并受到 SDK 接口的约束。而预装在设备中的系统应用，则可以调用整个框架层的接口和模块，其中 的很多接口在 SDK 中是隐藏的，因此，系统应用具有比第三方应用更多的权利。
Android 的应用都是基于 Java 语言来开发的，但在很多应用(尤其是游戏)中，需要进行 大规模的运算和图形处理，以及使用开源 C/C++类库。通过 Java 来实现，可能会有执行效率 过低和移植成本过高等问题。因此在 Android 开发中，开发者可以使用 C/C++来实现底层模 块，并添加 JNI(Java Native Interface)接口与上层 Java 实现进行交互，然后利用 Android 提供 的交叉编译工具生成类库并添加到应用中。
由于对于大部分应用开发者而言，无须了解 Android 运行时的具体细节，因此，本书后 续将不会详细介绍 Android 运行时的相关内容，有兴趣的读者，可以另行查阅相关资料和源 代码。
1.1.4 核心类库
对于框架层而言，核心类库就是它的“贤内助”。每一次 Android 系统升级，能看到的 都是框架层 SDK 的变迁，增加了新的功能，提供了新的接口。而在这些新功能的背后，核 心类库都是居功至伟。
为了让应用开发者能够绕过框架层，直接使用 Android 系统的特定类库，Android 还提 供了 NDK(Native Development Kit)，它由 C/C++的一些接口构成，开发者可以通过它更高效地 调用特定的系统功能。
但在 Android 上，开发者通常只能使用 C/C++编写功能类库，而不是整个应用。这是因 为，诸如界面绘制、进程调度等核心机制是部署在框架层并通过 Java 来实现的，应用只有 按照它们规定的模式去编写特定的 Java 模块和配置信息，才能够被识别、加载和执行。
Dalvik 是为 Android 量身打造的 Java 虚拟机，负责动态解析执行应用、分配空间、管理 对象生命周期等工作。如果说框架层是整个 Android 的大脑，决定了 Android 应用的设计特 征，那么，Dalvik 就是 Android 的心脏，为 Android 的应用提供动力，决定它们的执行效率。
核心类库由一系列的二进制动态库共同构成，通常使用 C/C++进行开发。与框架层的系 统服务相比，核心类库不能够独立运行于线程中，而需要被系统服务加载到其进程空间里， 通过类库提供的 JNI 接口进行调用。
核心类库的来源主要有两种，一种是系统原生类库，Android 为了提高框架层的执行效 率，使用 C/C++来实现它的一些性能关键模块，如：资源文件管理模块、基础算法库，等等。 而另一种则是第三方类库，大部分都是对优秀开源项目的移植，它们是 Android 能够提供丰 富功能的重要保障，如：Android 的多媒体处理，依赖于开源项目 OpenCORE 的支持;浏览器 控件的核心实现，是从 Webkit 移植而来;而数据库功能，则是得益于 Sqlite。Android 会为所 有移植而来第三方类库封装一层 JNI 接口，以供框架层调用。
1.1.5 硬件抽象层和 Linux 内核
Android 系统并不是从零开始设计的，而是搭建在 Linux 内核之上。狭义的 Android 系统， 主要指的是 Linux 内核以上的各层，从运行的角度来看，它们只是运行在 Linux 系统上的一 些进程，并不是完整的系统，离开了 Linux 的支撑，就像鱼儿离开了水一样，无法运行。
Android 的架构图如下，图中按照功能结构及面向人群进行划分，可以看出 Android 分成 三个部分：
应用部分：包含在 Android 设备上运行的所有应用，它们是 Android 系统中直接面向用 户的部分。
核心部分： Android 系统中核心的功能实现，包括应用框架、核心类库等，每个 Android 应用的开发者，都是在此基础上进行应用开发的。
1.1.2 框架层
框架层是 Android 系统中最核心的部分，它集中体现了 Android 系统的设计思想。在 Android 之前，有很多基于 Linux 内核打造的移动平台。作为超越前辈的成功范例，框架层 的设计正是 Android 脱颖而出的关键所在。
框架层由多个系统服务(System Service)共同组成，包括组件管理服务、窗口管理服务、 地理信息服务、电源管理服务、通话管理服务，等等。所有服务都寄宿在系统核心进程(System Core Process)中，在运行时，每个服务都占据一个独立的线程，彼此通过进程间的通信机制 (Inter-Process Communication，IPC)发送消息和传输数据。
底层部分：主要指 Android 寄宿的 Linux 操作系统及相关驱动。通常来说，只有硬件厂 商和从事 Android 移植的开发者，才会基于此来进行开发。
除了上述划分方式以外，从系统实际的架构模型来看，Android 则可以分成以下几个层 次：
应用层
框架层
运行时
核心类库
硬件抽象层
Linux 内核
与为低端移动设备而设计的 J2ME 虚拟机不同，Dalvik 是专门为高端设备而优化设计的。 它没有采用基于栈的虚拟机架构，而是采取了基于寄存器的虚拟机架构设计。通常来说，基 于栈的虚拟机对硬件的依赖程度小、生成的应用更节约空间，可以适配更多的低端设备;而 基于寄存器的虚拟机，对硬件的门槛会更高一些，编译出的应用可能会耗费稍多的存储空间， 但它的执行效率更高，更能够发挥高端硬件(主要指处理器)的能力。
而硬件抽象层(Hardware Abstract Layer，HAL)，是 Android 为厂商定义的一套接口标准， 它为框架层提供接口支持，厂商需要根据定义的接口实现相应功能。
Dalvik 没有沿用传统的 Java 二进制码(JavaBytecode)作为其一次编译的中间文件，而是应用了 新的二进制码格式文件.dex。在 Android 应用的编译过程中，它会先生成若干个.class 文件， 然后统一转换成一个.dex 文件。在转换过程中，Android 会对部分.class 文件中的指令做转义， 使用 Dalvik 特有的指令集 OpCodes 来替换，以提高执行效率。同时，.dex 会整合多个.class 文件中的重复信息，并对冗余部分做全局的优化和调整，合并重复的常量定义，以节约常量 池耗费的空间。这使得最终得到的.dex 文件通常会比将.class 文件压缩打包得出的.jar 文件更 精简。
而对于开发者而言，框架层最直观的体现就是 SDK，它通过一系列的 Java 功能模块，来 实现应用所需的功能。SDK 的设计决定了上层应用的开发模式、开发效率及能够实现的功能 范畴。因此，对于开发者而言，关注 SDK 的变迁是一件很有必要的事情，SDK 每个新版本的 诞生，都意味着一些老的接口会被调整或抛弃，另一些新的接口和功能火热出炉。开发者不 但要查看和关注那些被修改的接口，来检查应用的兼容性，并采取相应的策略去适应这些变 化，更重要的是，开发者还要追踪新提供的接口，寻找改进应用的机会，甚至是寻求开发新 应用的可能。
为了提升 Android 应用的执行效率，从垃圾回收器(Garbage Collection，GC)到编译器， Dalvik 一直在各个方面进行优化。经常可以听到这样的消息：“新版本的 Android 系统，比上 一个版本的效率高了 x 倍。”这大都是改善 Dalvik 的效果。在 Android 2.2 中，Dalvik 引入了 对 JIT(Just-in-time)编译的支持，将上层应用的执行效率提升了 2～4 倍，开启了 Android 发展 的新篇章。
1.1.3 运行时
和所有的 Java 程序运行平台一样，为了实现 Java 程序在运行阶段的二次编译， Android 为它们提供了运行时(Runtime)的支撑。
Android 的运行时由 Java 核心类库和 Java 虚拟机 Dalvik 共同构成。Java 核心类库涵盖了 Android 框架层和应用层所要用到的基础 Java 库，包括 Java 对象库、文件管理库、网络通信 库，等等。
小贴士 从 Android 2.3(API 9)开始，新增了 android.app.NativeActivity 类，它是通过调用
Fra Baidu bibliotek
预定义的 JNI 接口来实现的。开发者可以基于 NDK，通过 C/C++语言来实现具体功能。这就 意味着，开发者仅通过 C/C++语言就能实现整个应用。这对于游戏开发者而言是一大喜讯， 但由于控件在 Android 中并没有 Native 的实现，普通的应用开发者通常还是需要通过 Java 来实现上层界面。
本文的后续内容将针对以上各层逐一进行分析。
1.1.1 应用层
对于普通的用户而言，只能通过具体的应用来判断移动平台的优劣。即便一个移动平台 具有最华丽的技术，但是如果不能给用户提供最得心应手的应用，顶多也只能赢得无冕之王 的名头，而无法抓住用户的心，赢得市场的认可。
Android 应用层由运行在 Android 设备上的所有应用共同构成，它不仅包括通话、短信、 联系人等系统应用(随 Android 系统一起预装在移动设备上)，还包括其他后续安装到设备中 的第三方应用。
从系统设计的角度来看，Android 期望框架层是所有应用运行的核心，参与到应用层的 每一次操作中，并进行全局统筹。Android 应用的最大特征是基于组件的设计方式。每个应 用都由若干个组件构成，组件和组件之间并不会建立通信信道，而是通过框架层的系统服务， 集中地调度和传递消息。这样的设计方式相当于增加了一个中间层，该层了解所有组件的状 况，可以更智能地进行协调，从而提升了整个系统的灵活性。
为了帮助游戏和图形图像处理等领域的开发者搭建更高效的应用，Android 将数学函数 库、OpenGL 库等核心类库以 NDK 的形式提供给开发者，开发者可以基于 NDK 更高效地构 建算法，进行图形图像绘制。从实践的角度看，只要能获取到底层类库的头文件信息，开发 者就可以逾越 NDK 的界限，用其他核心类库的接口进行开发。但这样做的危险之处在于兼 容性差，Android 在版本变迁时，可能会替换或修改一些类库接口或实现，这就会导致依赖 于这些类库的应用无法运行。而 NDK 提供的都是稳定的类库实现，不会再做修改，以保证 使用 NDK 的应用具有向上的兼容性。
Linux 之于 Android 最大的价值，便是其强大的可移植性。Linux 可以运行在各式各样的 芯片架构和硬件环境下，而依托于它的 Android 系统，也便有了强大的可移植性。同时，Linux 像一座桥梁，将 Android 的上层实现与底层硬件连接起来，使它们可以不必直接耦合，因此， 降低了移植的难度。
第三方应用都是基于 Android 提供的 SDK(Software Development Kit)进行开发的，并受到 SDK 接口的约束。而预装在设备中的系统应用，则可以调用整个框架层的接口和模块，其中 的很多接口在 SDK 中是隐藏的，因此，系统应用具有比第三方应用更多的权利。
Android 的应用都是基于 Java 语言来开发的，但在很多应用(尤其是游戏)中，需要进行 大规模的运算和图形处理，以及使用开源 C/C++类库。通过 Java 来实现，可能会有执行效率 过低和移植成本过高等问题。因此在 Android 开发中，开发者可以使用 C/C++来实现底层模 块，并添加 JNI(Java Native Interface)接口与上层 Java 实现进行交互，然后利用 Android 提供 的交叉编译工具生成类库并添加到应用中。
由于对于大部分应用开发者而言，无须了解 Android 运行时的具体细节，因此，本书后 续将不会详细介绍 Android 运行时的相关内容，有兴趣的读者，可以另行查阅相关资料和源 代码。
1.1.4 核心类库
对于框架层而言，核心类库就是它的“贤内助”。每一次 Android 系统升级，能看到的 都是框架层 SDK 的变迁，增加了新的功能，提供了新的接口。而在这些新功能的背后，核 心类库都是居功至伟。
为了让应用开发者能够绕过框架层，直接使用 Android 系统的特定类库，Android 还提 供了 NDK(Native Development Kit)，它由 C/C++的一些接口构成，开发者可以通过它更高效地 调用特定的系统功能。
但在 Android 上，开发者通常只能使用 C/C++编写功能类库，而不是整个应用。这是因 为，诸如界面绘制、进程调度等核心机制是部署在框架层并通过 Java 来实现的，应用只有 按照它们规定的模式去编写特定的 Java 模块和配置信息，才能够被识别、加载和执行。
Dalvik 是为 Android 量身打造的 Java 虚拟机，负责动态解析执行应用、分配空间、管理 对象生命周期等工作。如果说框架层是整个 Android 的大脑，决定了 Android 应用的设计特 征，那么，Dalvik 就是 Android 的心脏，为 Android 的应用提供动力，决定它们的执行效率。
核心类库由一系列的二进制动态库共同构成，通常使用 C/C++进行开发。与框架层的系 统服务相比，核心类库不能够独立运行于线程中，而需要被系统服务加载到其进程空间里， 通过类库提供的 JNI 接口进行调用。
核心类库的来源主要有两种，一种是系统原生类库，Android 为了提高框架层的执行效 率，使用 C/C++来实现它的一些性能关键模块，如：资源文件管理模块、基础算法库，等等。 而另一种则是第三方类库，大部分都是对优秀开源项目的移植，它们是 Android 能够提供丰 富功能的重要保障，如：Android 的多媒体处理，依赖于开源项目 OpenCORE 的支持;浏览器 控件的核心实现，是从 Webkit 移植而来;而数据库功能，则是得益于 Sqlite。Android 会为所 有移植而来第三方类库封装一层 JNI 接口，以供框架层调用。
1.1.5 硬件抽象层和 Linux 内核
Android 系统并不是从零开始设计的，而是搭建在 Linux 内核之上。狭义的 Android 系统， 主要指的是 Linux 内核以上的各层，从运行的角度来看，它们只是运行在 Linux 系统上的一 些进程，并不是完整的系统，离开了 Linux 的支撑，就像鱼儿离开了水一样，无法运行。
Android 的架构图如下，图中按照功能结构及面向人群进行划分，可以看出 Android 分成 三个部分：
应用部分：包含在 Android 设备上运行的所有应用，它们是 Android 系统中直接面向用 户的部分。
核心部分： Android 系统中核心的功能实现，包括应用框架、核心类库等，每个 Android 应用的开发者，都是在此基础上进行应用开发的。
1.1.2 框架层
框架层是 Android 系统中最核心的部分，它集中体现了 Android 系统的设计思想。在 Android 之前，有很多基于 Linux 内核打造的移动平台。作为超越前辈的成功范例，框架层 的设计正是 Android 脱颖而出的关键所在。
框架层由多个系统服务(System Service)共同组成，包括组件管理服务、窗口管理服务、 地理信息服务、电源管理服务、通话管理服务，等等。所有服务都寄宿在系统核心进程(System Core Process)中，在运行时，每个服务都占据一个独立的线程，彼此通过进程间的通信机制 (Inter-Process Communication，IPC)发送消息和传输数据。
底层部分：主要指 Android 寄宿的 Linux 操作系统及相关驱动。通常来说，只有硬件厂 商和从事 Android 移植的开发者，才会基于此来进行开发。
除了上述划分方式以外，从系统实际的架构模型来看，Android 则可以分成以下几个层 次：
应用层
框架层
运行时
核心类库
硬件抽象层
Linux 内核
与为低端移动设备而设计的 J2ME 虚拟机不同，Dalvik 是专门为高端设备而优化设计的。 它没有采用基于栈的虚拟机架构，而是采取了基于寄存器的虚拟机架构设计。通常来说，基 于栈的虚拟机对硬件的依赖程度小、生成的应用更节约空间，可以适配更多的低端设备;而 基于寄存器的虚拟机，对硬件的门槛会更高一些，编译出的应用可能会耗费稍多的存储空间， 但它的执行效率更高，更能够发挥高端硬件(主要指处理器)的能力。
而硬件抽象层(Hardware Abstract Layer，HAL)，是 Android 为厂商定义的一套接口标准， 它为框架层提供接口支持，厂商需要根据定义的接口实现相应功能。
Dalvik 没有沿用传统的 Java 二进制码(JavaBytecode)作为其一次编译的中间文件，而是应用了 新的二进制码格式文件.dex。在 Android 应用的编译过程中，它会先生成若干个.class 文件， 然后统一转换成一个.dex 文件。在转换过程中，Android 会对部分.class 文件中的指令做转义， 使用 Dalvik 特有的指令集 OpCodes 来替换，以提高执行效率。同时，.dex 会整合多个.class 文件中的重复信息，并对冗余部分做全局的优化和调整，合并重复的常量定义，以节约常量 池耗费的空间。这使得最终得到的.dex 文件通常会比将.class 文件压缩打包得出的.jar 文件更 精简。