Android 框架学习（1）—— 系统架构

        最近由于工作需要，开始接触Android 8.0架构，以前做过几款简单的Android应用，但是对于底层架构这方面的知识完全是小白，所以得从头学起，网络上对于Android 8.0架构的内容很多，但更多的是基于应用方面的内容，这里边学习边做些笔记，好记性不如烂笔头，开始吧。

一、整体架构

        Android系统架构分为五层：

• 应用框架

        应用框架最常被应用开发者使用。并且很多此类 API 都可以直接映射到底层 HAL 接口，并可提供与实现驱动程序相关的实用信息。

• Binder IPC

        Binder 进程间通信 (IPC) 机制允许应用框架跨越进程边界并调用 Android 系统服务代码，这使得高级框架 API 能与 Android 系统服务进行交互。在应用框架级别，开发者无法看到此类通信的过程，但一切似乎都在“按部就班地运行”。

• 系统服务

        系统服务是专注于特定功能的模块化组件，例如窗口管理器、搜索服务或通知管理器。 应用框架 API 所提供的功能可与系统服务通信，以访问底层硬件。Android 包含两组服务：“系统”（诸如窗口管理器和通知管理器之类的服务）和“媒体”（与播放和录制媒体相关的服务）。

• 硬件抽象层 (HAL)

        HAL 可定义一个标准接口以供硬件供应商实现，这可让 Android 忽略较低级别的驱动程序实现。借助 HAL，您可以顺利实现相关功能，而不会影响或更改更高级别的系统。HAL 实现会被封装成模块，并会由 Android 系统适时地加载。

• Linux 内核

        开发设备驱动程序与开发典型的 Linux 设备驱动程序类似。Android 使用的 Linux 内核版本包含几个特殊的补充功能，例如：Low Memory Killer（一种内存管理系统，可更主动地保留内存）、唤醒锁定（一种 PowerManager 系统服务）、Binder IPC 驱动程序以及对移动嵌入式平台来说非常重要的其他功能。这些补充功能主要用于增强系统功能，不会影响驱动程序开发。您可以使用任意版本的内核，只要它支持所需功能（如 Binder 驱动程序）即可。不过，建议使用 Android 内核的最新版本。

二、架构解析

        在一个大的项目里面，分层是非常重要的，处于最底层的接口最具有"通用性"，接口颗粒度最细，越往上层通用性降低。理论上来说上面每一层都可以"开放"给开发者调用，例如开发者可以直接调用硬件抽象层的接口去操作硬件，或者直接调用系统服务层中的接口去直接操作系统服务，甚至像Windows开发一样，开发者可以在内核层写程序，运行在内核中。不过开放带来的问题就是开发者权利太大，对于系统的稳定性是没有任何好处的，一个病毒制作者搞一个内核层的病毒出来，系统可能就永远起不来。所以谷歌的做法是将开发者的权利收拢到"应用程序框架层"，开发者只能调用这一层的接口。
        在上面的层次中，内核层与硬件抽象层均用C/C++实现，系统服务层是以Java实现，硬件抽象层编译为so文件，以JNI的形式供系统服务层使用。系统服务层中的服务随着系统启动而启动，只要不关机，就会一直运行。这些服务干什么事情？其实很简单，就是完成一个手机所有的核心功能如短信的收发、电话的接听、挂断以及应用程序的包管理、Activity的管理等等。每一个服务均运行在一个独立的进程中，因此是以Java实现，所以本质上来说是运行在一个独立进程的Dalvik虚拟机中。那么问题来了，开发者的App也运行在一个独立的进程空间中，如何调用到系统的服务层中的接口？答案是：进程间通信IPC（Inter-Process Communication），它和远程过程调用RPC（Remote Procedure Call）是不一样的，实现原理也不一样。每一个系统服务在应用框架层都有一个Manager与之对应，方便开发者调用其相关功能，具体关系如下：

三、总结

• Android 从下而上分了内核层、硬件抽象层、系统服务层、Binder IPC 层、应用程序框架层。
• Android 中"应用程序框架层"以 SDK 的形式开放给开发者使用，“系统服务层”
  中的核心服务随系统启动而运行，通过应用层序框架层提供的 Manager 实时为应用程序提供服务调用。系统服务层中每一个服务运行在自己独立的进程空间中，应用程序框架层中的 Manager 通过 Binder IPC 的方式调用系统服务层中的服务。