📚 课程目录第1章 Android Framework模块化概述

第1章：Android 系统源码整体布局

本章从架构总览视角，系统梳理 AOSP（Android Open Source Project）顶层目录的结构与职责，定位 Framework 源码位置，并给出核心模块清单。这是理解 Android 模块化机制的前提——只有在脑图中标定每一块的边界与连接方式，后续的剥离、复用、测试才能落地。

1.1 AOSP 顶层目录与模块边界

AOSP 根目录下数十个一级目录，各自代表一个大模块组。模块边界划分遵循“平台层-硬件层-工具链”三族原则，每一族内再按“功能域”细分。下表列出最关键的 12 个顶层目录及其职责边界：

目录名	所属族	模块边界与核心职责
frameworks	平台层	应用框架与系统服务（Android Framework 主仓库）
system	平台层	核心系统守护进程、init、adb、logd 等基础基础设施
hardware	硬件层	HAL（硬件抽象层）接口定义与参考实现
kernel	硬件层	Linux 内核（AOSP 内为预构建内核头文件与配置）
external	平台层	第三方开源库（如 libpng、boringssl、sqlite）
art	平台层	Android Runtime（ART 编译器与运行时）
bionic	平台层	标准 C 库实现（BSD 派生，替代 glibc）
build	工具链	构建系统（Soong / Blueprint 规则与 make 支持）
prebuilts	工具链	预编译工具链（JDK、clang、gradle 等）
device	硬件层	OEM 设备配置、BoardConfig、内核与 vendor 脚本
packages	平台层	系统预装应用（Settings、Launcher、Phone）
vendor	硬件层	厂商私有扩展（驱动、HAL 实现、专有库）

边界设计原则：平台层目录 frameworks 与 system 严格分离——frameworks 只包含 Java / C++ 服务框架，system 包含原生守护进程与核心命令行工具。这种拆分使得 Framework 可在不依赖 init/ logd 的情况下做单元测试（通过 Mock 系统调用）。

1.2 Framework 源码位置与核心模块清单

Framework 源码集中在 frameworks/ 目录下，其中四个子目录构成主体：

frameworks/base — 所有核心 Java 框架、系统服务、资源管理、API 定义。
frameworks/native — 原生 C++ 层服务（SurfaceFlinger、AudioFlinger、SensorService）。
frameworks/av — 多媒体组件（MediaPlayer、MediaCodec、Camera 服务）。
frameworks/support — 现为 Jetpack 仓库，提供向后兼容的 API 库。

核心模块清单（仅列出架构级关键模块）：

模块名称	位置	职责
ActivityManagerService	frameworks/base/services/core/java/…	生命周期管理、进程调度、任务栈
WindowManagerService	frameworks/base/services/core/java/…	窗口布局、输入分发、动画合成
PackageManagerService	frameworks/base/services/core/java/…	APK 安装、权限校验、组件查询
SurfaceFlinger	frameworks/native/services/surfaceflinger	图形合成（GPU 图层混合）
AudioFlinger	frameworks/av/services/audioflinger	音频混音与 HAL 代理
MediaServer	frameworks/av/media/mediaserver	多媒体服务主进程（MediaPlayerService 等）

控制流与信任链路简述：应用通过 Binder IPC 调用系统服务端（如 AMS），服务端再通过 JNI 调用 Native 层（如 SurfaceFlinger），最终通过 HAL 与内核驱动交互。信任链路以进程隔离为基础，每个服务运行在独立进程中（system_server、media_server 等），权限由 manifest 中的 android:permission 与 ServiceManager 的访问控制共同保障。

1.3 分层结构：从内核到应用的四层模型

Android 系统在逻辑上分为四层，每一层封装底层复杂性，向上提供稳定接口。下图为分层架构及各层核心组件：

模块化陷阱：分层模型令人误以为层间耦合松散，但实际上 ActivityManagerService 直接通过 JNI 调用 SurfaceFlinger 的 native 接口，形成严重的跨层依赖。后续章节将详细剖析如何通过接口剥离、服务化切分来解除这种硬绑定。

1.4 选型权衡与风险点

决策点	选项 A	选项 B	AOSP 选择与权衡
系统服务实现语言	全部 C++	全部 Java	混合：性能敏感型（图形/音频）用 C++；业务逻辑复杂（AMS/WMS）用 Java。代价是 JNI 桥接开销与调试复杂。
IPC 机制	Socket / Pipe	Binder	Binder 兼具高性能与安全校验，但需要维护 .aidl 接口与 Stub/Proxy 模式，增加了模块拆分的代码量。
模块复用粒度	静态库 / 动态库	单独进程服务	AOSP 倾向于将大模块（如媒体服务）独立进程以隔离崩溃影响，但带来了跨进程通信延迟与序列化开销。
Hardware 抽象方式	内核模块直编	HAL + HIDL	HAL 支持厂商 stub 替换，但每次版本升级需重新编译全部 stub，旧版 HAL 与新版本 Framework 不兼容（Treble 后通过 HIDL 解决）。

风险点摘要：

源码树耦合：frameworks/base 与 external/ 大量条件编译（#ifdef），改动一处可能引爆全局。
构建依赖爆炸：单个模块更改（如 libbinder）触发数千个目标重编译。
厂商碎片化：vendor/ 直接引用 hardware/ 中的私有符号，导致 OTA 升级时二进制不兼容。

1.5 落地步骤（面向架构师）

环境准备：拉取 AOSP 源码（建议 master 或 android-13+），确保 lunch 目标为 aosp_arm64-eng。
目录扫描：逐层进入 frameworks/base、frameworks/native、frameworks/av，记录各子目录模块名与其 Android.bp 入口。
边界绘制：使用工具（如 find . -name "Android.bp" | xargs grep "cc_library\|java_library"）导出模块依赖，画出本机模块依赖图（用于后续模块化改造基准）。
关键模块标注：在依赖图中标注 AMS、WMS、SurfaceFlinger 等核心节点的进程归属与对外接口类型（Binder AIDL / 直接函数调用）。
信任链路审计：检查 system/core/rootdir/init.rc 以确认各服务启动顺序与 SELinux 策略文件中的 domain 声明。

1.6 验收标准

检查项	验收通过条件
顶层目录识别	能独立说出 `frameworks/sys tem/hardware/kernel/external/art` 等目录的核心职责
Framework 源码位置	能准确指示 `frameworks/base` 中 `core/java`、`services/core`、`graphics` 等关键 package 路径
核心模块清单	能列出至少6个系统服务名称及其所属进程（system_server / media_server / surfaceflinger）
分层结构图	能手绘或利用工具绘制出四层架构及每层的代表组件，并标注层间通信机制
风险点描述	能说出至少 2 个与源码组织相关的架构风险（如跨层 JNI 耦合、构建依赖爆炸）

第一章小结：本章建立了 Android 系统源码的“地图”——从顶层目录的模块边界到 Framework 内部的核心模块清单，并以分层结构图展示了数据流与控制流的基本路径。后续章节将深入每一层的模块化设计方案，包括 ServiceManager 的接口解耦、Binder 的跨进程能力提纯、以及 HAL 层的 Treble 化改造。