Android 系统架构详解

Android 系统架构详解

Android 是由 Google 主导、AOSP（Android 开源项目）维护的开源移动操作系统。自 2008 年发布以来，它已成长为全球市场份额最大的移动平台，覆盖手机、平板、手表、电视、车载乃至物联网设备。Android 之所以能够适配如此多样的硬件，得益于其清晰分明的分层软件栈架构——每一层都为上一层提供服务，并通过定义良好的接口与硬件实现解耦。本文自上而下逐层拆解 Android 的系统架构。

1、架构概述

Android 采用经典的分层（Layered）软件栈架构，从上到下依次为五层：系统应用层、Java API 框架层、原生库与 Android 运行时、硬件抽象层（HAL）、Linux 内核。应用开发者主要与上层 API 打交道，而硬件厂商则集中精力实现 HAL 与内核驱动，两者通过稳定的接口边界协作，互不侵入。

┌──────────────────────────────────────────────────────────┐
│                系统应用层  System Apps                    │
│   电话 / 短信 / 浏览器 / Launcher / 联系人 / 第三方应用     │
├──────────────────────────────────────────────────────────┤
│            Java API 框架层  Java API Framework            │
│   Activity Manager · Window Manager · View System ·        │
│   Content Provider · Notification · Package Manager ...   │
├─────────────────────────┬────────────────────────────────┤
│     原生 C/C++ 库         │      Android Runtime (ART)      │
│ OpenGL ES · SQLite ·      │   AOT + JIT + PGO · Dalvik 字节码│
│ Media Framework · Webkit  │                                  │
├─────────────────────────┴────────────────────────────────┤
│                  硬件抽象层  HAL                           │
│   相机 · 蓝牙 · 音频 · 图形 · 传感器 · WiFi · RIL          │
├──────────────────────────────────────────────────────────┤
│                    Linux 内核                              │
│   进程/内存管理 · 网络栈 · Binder 驱动 · 电源管理 · 驱动    │
└──────────────────────────────────────────────────────────┘

核心思想：

       - 分层解耦：上层只依赖下层提供的抽象接口，不关心具体实现

       - 替换自由：同一套框架可跑在不同厂商的硬件之上

       - 统一接口：HAL 与 Binder 让软硬件、进程间协作标准化

参考资料（官方文档）：

• Android 开发者 — 平台架构：https://developer.android.google.cn/guide/platform?hl=zh-cn

• AOSP — Android 架构：https://source.android.google.cn/docs/core/architecture?hl=zh-cn

2、系统应用层（System Apps）

位于架构最顶层的是一系列预装的系统应用，它们构成了用户感知到的"Android 手机"。这些应用本身并不享有任何特权，与用户后续安装的第三方应用使用完全相同的 API 与运行环境。

       - 核心应用：电话、短信、日历、电子邮件、浏览器、联系人、相机、时钟、设置

       - 桌面启动器（Launcher），即用户看到的主屏幕

       - 用户从应用商店或 APK 安装的第三方应用

正因系统应用与普通应用地位平等，用户才能用第三方启动器替换默认桌面、用第三方短信应用替换默认短信，体现了 Android 的开放性。

3、Java API 框架层（Java API Framework）

这是应用开发者最熟悉的一层，它把 Android 的全部能力封装成一组完整的 Java API。框架层由一系列管理器（Manager）与系统服务组成，开发者通过它们驱动应用的生命周期、界面、数据与设备能力。

       - Activity Manager：管理应用生命周期与回退栈

       - Window Manager：管理窗口与层级

       - View System：构建 UI，提供 ListView、GridView、TextView、Button 等控件

       - Content Provider：跨应用数据共享（如通讯录、媒体库）

       - Notification Manager：状态栏与通知

       - Package Manager：应用包信息查询与安装

       - Resource Manager：加载字符串、图片、布局等非代码资源

       - Location Manager：定位与地理围栏

       - Telephony Manager：蜂窝网络与通话

这些服务大多运行在 system_server 等系统进程中，应用通过 Binder IPC 调用它们。

4、原生库与 Android 运行时

4.1、原生 C/C++ 库

许多核心能力由 C/C++ 编写的原生库承担，性能关键路径（如图形渲染、媒体解码）都依赖它们。这些库大多通过上层的 Java API 间接暴露给开发者，部分可通过 NDK 直接调用。

       - Surface Manager：管理显示合成与窗口叠层

       - Media Framework：音视频编解码（基于 PacketVideo / OpenCORE）

       - SQLite：轻量级关系型数据库，支撑应用的本地存储

       - OpenGL ES：嵌入式 3D 图形渲染

       - WebKit / WebView：网页内容渲染

       - FreeType：位图与矢量字体渲染

       - SSL / Conscrypt：安全通信与加密

       - libc（Bionic）：Google 为 Android 量身定制的 C 运行库，小而快

4.2、Android Runtime（ART）

Android 应用以 Dalvik 字节码（.dex）形式分发。早期设备使用 Dalvik 虚拟机以 JIT（即时编译）方式运行；自 Android 5.0 起，Dalvik 被性能更强的 ART（Android Runtime）全面取代。

       - AOT（Ahead-of-Time）编译：在应用安装时将字节码预编译为机器码

       - JIT（Just-in-Time）编译：运行时对热点代码即时编译

       - Profiles / PGO：基于实际运行配置文件引导编译，兼顾安装速度与运行性能

       - 每个应用运行在独立的进程中，拥有独立的 ART 实例与内存空间

5、硬件抽象层（HAL）

HAL（Hardware Abstraction Layer）是连接上层框架与底层硬件的关键薄层。它把各类硬件能力抽象成标准接口，由各硬件厂商各自实现，从而让同一套 Android 框架可以适配千差万别的元器件。

       - 相机、蓝牙、音频、传感器、WiFi

       - 图形：Gralloc（显存分配）、HWC（硬件合成器）

       - 通信：RIL（Radio Interface Layer），对接蜂窝基带

       - 指纹、生物识别、DRM 等专用硬件

HAL 的存在使 Android 平台代码与厂商硬件实现彻底解耦：Google 维护框架与接口规范，厂商只需"填空"实现自家 HAL 即可。

6、Linux 内核

Android 的根基是 Linux 内核（基于上游 LTS 版本），它负责操作系统的底层事务，并包含大量针对移动场景的定制。

       - 进程调度与内存管理

       - 网络协议栈

       - 驱动模型，对接各类外设

       - Binder 驱动：Android 跨进程通信的核心，详见下节

       - 电源管理（wakelocks）：适配移动设备的休眠与唤醒

       - 低内存杀手（LMK）：内存紧张时按优先级回收后台进程

       - ashmem / dma-buf：高效的共享内存机制

可以说，没有 Linux 内核对进程隔离、内存与 IPC 的支撑，上层的多应用沙箱与系统服务就无从谈起。

7、关键机制与安全模型

7.1、Binder IPC

Android 的进程间通信（IPC）几乎全部建立在 Binder 之上。它依托 Linux 内核中的 binder 驱动，只需一次数据拷贝，性能优于传统的管道、共享内存与 Socket，且天然携带调用者身份，便于权限校验。所有框架层系统服务都通过 Binder 暴露接口，开发者通常用 AIDL 描述接口。

// IRemoteService.aidl —— 用 AIDL 定义可跨进程调用的接口
interface IRemoteService {
    int getPid();
    void basicTypes(int anInt, long aLong, boolean aBoolean,
                    float aFloat, double aDouble, String aString);
}

核心实现：

1. 客户端通过代理对象发起调用

2. 数据经 binder 驱动一次拷贝到服务端进程

3. 服务端在 Binder 线程上执行并返回结果

4. 驱动全程校验调用方 UID/PID，保障安全

7.2、Project Mainline（模块化更新）

自 Android 10 起，Google 推出 Project Mainline，把部分核心系统组件拆分为可独立升级的模块（APEX）。这些模块不再依赖整机 OTA，而是通过 Google Play 系统更新快速推送，显著缩短了安全补丁与关键组件的更新周期。

       - 媒体编解码器、DNS 解析器、NNAPI 等可独立升级

       - Conscrypt（安全组件）可快速响应 TLS 漏洞

       - 模块接口向下兼容，不影响厂商定制

7.3、应用沙箱与权限模型

Android 的安全建立在 Linux 的 UID 隔离之上。每个应用在安装时分配独立 UID，运行在独立进程与独立沙箱中，默认无法访问彼此数据。在此基础上叠加权限模型与强制访问控制。

       - 应用沙箱：独立 UID、独立进程、文件权限隔离

       - 权限模型：普通权限安装时授予，危险权限运行时申请

       - SELinux：强制访问控制（MAC），细化系统组件的最小权限

       - Verified Boot：启动链逐级校验，防止系统被篡改

8、总结

Android 系统架构是一个教科书级的分层软件栈：以 Linux 内核为地基，以 HAL 屏蔽硬件差异，以原生库与 ART 提供运行能力，以 Java API 框架统一应用开发接口，最上层承载系统与第三方应用。Binder 把各层、各进程粘合在一起，Project Mainline 让核心组件得以快速演进，沙箱与权限模型则守护着整个平台的安全。

关键要点：

       - 五层架构：系统应用 / Java 框架 / 原生库与运行时 / HAL / Linux 内核

       - HAL 让平台与硬件解耦，是适配万千设备的基石

       - ART 以 AOT + JIT + PGO 平衡安装速度与运行性能

       - Binder 是贯穿全栈的 IPC 纽带，沙箱与 SELinux 守护安全

对于 Android 开发者而言，理解这套架构不仅有助于写出更贴合平台特性的代码，更是排查性能、稳定性与安全问题时的底层地图——当应用出现卡顿、内存抖动或 IPC 异常时，能否快速定位到"问题落在哪一层"，往往决定了排查的效率。