Android系统是一个基于Linux内核的软件栈,其设计采用了分层架构,每一层都为上层提供特定的服务,并隐藏了下层的复杂实现。这种结构保证了系统的稳定性、安全性和可扩展性。
经典的Android系统体系结构分为五个主要层次,从下到上依次是:
1. Linux内核
这是整个系统的基础,位于硬件和其他软件层之间。
-
核心功能:
- 硬件抽象: 负责与设备硬件(如显示、摄像头、蓝牙、Wi-Fi、音频等)进行通信。它将硬件差异屏蔽起来,为上层的C/C++库和Android运行时提供统一的接口。
- 进程管理: 管理所有应用程序和系统进程的创建、执行、调度和销毁。
- 内存管理: 负责虚拟内存、物理内存的分配与回收,处理内存不足的情况。
- 电源管理: 通过
wakelocks
等机制管理设备的休眠和唤醒,优化电池寿命。 - 网络堆栈: 提供网络通信能力(如TCP/IP)。
- 安全性: 基于Linux的用户和权限模型,为每个应用分配独立的用户ID(UID),实现进程级别的沙箱隔离。应用无法直接访问系统资源或其他应用的数据。
-
专家视角:
- Android使用的内核并非标准Linux内核,它包含了许多Android特有的补丁和驱动 ,例如
Binder IPC
、ashmem
(匿名共享内存)、wakelocks
等,这些是Android系统运行的核心。
- Android使用的内核并非标准Linux内核,它包含了许多Android特有的补丁和驱动 ,例如
2. 硬件抽象层
HAL是一个承上启下的关键层,它定义了标准接口,让Android框架能够与设备特定的硬件驱动进行交互,而无需关心底层的具体实现。
-
核心功能:
- 提供了一组标准化的C/C++头文件接口 ,例如
camera.h
、sensors.h
、audio.h
等。 - 硬件制造商(OEM)需要根据这些接口实现具体的HAL模块(.so库文件)。
- 提供了一组标准化的C/C++头文件接口 ,例如
-
专家视角:
- 解耦的关键: HAL是Android能够运行在不同厂商、不同硬件设备上的关键。它使得Google可以独立更新Android框架,而OEM厂商则可以专注于实现自己硬件的HAL。
- Project Treble: 在Android 8.0中引入的Treble项目 对HAL进行了重大重构,引入了Vendor Interface 。它将HAL定义为一个稳定的、经过版本控制的接口,并强制要求使用
Binderized HAL
(通过Binder IPC通信),这使得系统框架(System Image)和供应商实现(Vendor Image)可以独立升级,极大地加快了系统更新的推送速度。
3. 原生C/C++库 & Android运行时
这一层包含了执行特定任务的高性能原生库和Android应用的运行环境。
A. 原生C/C++库
这些库通常由C/C++编写,通过Java原生接口(JNI) 被上层的应用框架调用。
- 核心组件:
- Surface Manager: 管理显示子系统,无缝合成来自多个应用的2D和3D图形层。
- Media Framework: 基于OpenCORE和Stagefright,负责音频和视频的录制与回放,支持多种格式(如MPEG4, H.264, MP3, AAC等)。
- OpenGL ES: 用于高性能2D和3D图形渲染的API。
- Vulkan: 一个低开销、跨平台的3D图形和计算API,提供对GPU更直接的控制,比OpenGL ES效率更高。
- SQLite: 一个轻量级的关系型数据库引擎,是所有应用和系统都可以使用的核心数据存储。
- WebKit: 浏览器引擎的底层支持(现已被Chromium项目替代)。
- libc: 标准C库,但Android使用的是专为嵌入式设备优化的Bionic Libc。
B. Android运行时
这是Android应用执行的环境。它在不同版本中经历了重大演变。
-
Dalvik虚拟机(Android 5.0之前):
- 一个由Google设计的、专为移动设备优化的Java虚拟机。
- 它使用
.dex
(Dalvik Executable)格式,该格式专为低内存和低速CPU设计,比标准Java的.class
文件更高效。 - 采用JIT(Just-In-Time) 编译,在应用运行时将字节码编译为本地机器码。
-
ART(Android Runtime,Android 5.0及之后):
- Dalvik的替代者,使用相同的
.dex
字节码。 - 关键改进是引入了AOT(Ahead-Of-Time) 编译。应用在安装期间 就被编译成原生机器码,这使得应用的启动速度和运行速度显著提升,但安装时间变长,占用空间更多。
- 现代ART(Android 7.0+): 采用了混合模式,结合了AOT、JIT和解释执行。它使用JIT来分析应用运行时的热点代码,并在设备空闲时对其进行AOT编译,实现了性能和空间占用的最佳平衡。
- Dalvik的替代者,使用相同的
-
核心运行时库:
- 包含了大量的Java API(如
java.util
,java.lang
等),为应用提供核心的Java编程功能。Android应用开发者使用的Java类库主要就来源于此。
- 包含了大量的Java API(如
4. Java API框架(应用框架层)
这一层是应用开发者最直接打交道的部分,它提供了构建Android应用所需的全套Java和Kotlin API。
-
核心组件与服务:
- Activity Manager: 管理应用的生命周期和活动栈(Back Stack)。
- View System: 用于构建用户界面的丰富且可扩展的控件集合(按钮、列表等)。
- Resource Manager: 提供对非代码资源(如图片、字符串、布局文件)的访问。
- Notification Manager: 允许所有应用在状态栏显示自定义提醒。
- Content Providers: 管理应用间数据的共享和访问(如联系人信息)。
- Location Manager: 提供系统级的位置服务(GPS,网络定位)。
- Package Manager: 管理设备上安装的所有应用包信息。
- Telephony Manager: 提供手机通话相关功能的API。
- Window Manager: 管理窗口(Window)和视图(View)的层次结构。
- XMPP Service: (已过时,被其他云消息服务替代)早期用于推送服务。
-
专家视角:
- 这些服务大多以系统进程 的形式运行,并通过Binder IPC 机制向应用暴露接口。当应用调用
getSystemService(Context.WINDOW_SERVICE)
时,实际上是通过Binder与WindowManagerService
进行跨进程通信。
- 这些服务大多以系统进程 的形式运行,并通过Binder IPC 机制向应用暴露接口。当应用调用
5. 系统应用和应用层
这是用户直接交互的顶层,包含了设备出厂时预装的系统应用和用户从应用商店下载安装的第三方应用。
- 核心组件:
- 系统应用: 如主屏幕(Launcher)、拨号器、联系人、短信、相机、浏览器、设置等。这些应用不仅为用户提供核心功能,同时也作为API的使用范例,并且它们本身的功能(如拨号)也可以被第三方应用通过Intent调用。
- 第三方应用: 开发者利用下层提供的所有能力构建的丰富应用生态。
贯穿各层的核心机制:Binder IPC
Binder是整个Android系统的"神经系统",是实现跨进程通信(IPC)的核心机制。
- 作用: 允许运行在不同进程中的组件(如一个应用和系统服务)进行高效、安全的通信。
- 工作方式: 应用框架中的大多数服务(如
ActivityManagerService
)都运行在system_server
进程中。当应用调用这些服务时,Binder驱动会将请求和数据从一个进程的地址空间复制到另一个进程的地址空间。 - AIDL: 开发者也可以使用Android接口定义语言来定义自己的Binder接口,实现自定义的跨进程服务。
总结与演进
- 分层优势: 这种分层架构实现了高内聚、低耦合,使得各层可以独立开发和演进。
- 系统更新演进:
- 传统更新: 在Treble之前,由于框架和HAL紧密耦合,OEM厂商需要从芯片商(如Qualcomm)获取新的驱动和HAL实现,才能进行大版本更新,过程缓慢。
- Project Treble: 通过引入稳定的Vendor Interface,将框架和供应商实现分离,使得OEM厂商可以更快地适配新版本Android。
- Project Mainline(Android 10+): 进一步模块化,允许Google通过Google Play商店直接更新核心系统组件(如媒体编解码器、权限控制器等),实现了类似Chromebook的模块化更新,进一步提升了安全性和一致性。
理解Android系统体系结构,能帮助开发者从宏观上把握应用是如何与系统交互的,从而在开发、调试和性能优化时能够更加得心应手。
