第一章：Android系统架构概览

各位同学好，我是你们的老朋友。今天咱们正式开讲《从源码看Android启动流程核心设计》的第一章。

很多人学Android，上来就写Activity，调API。但说实话，如果你不懂底层架构，遇到性能问题、启动优化、或者系统定制，就会一头雾水。我当年刚入行时也是这样，直到有一次被一个系统级bug折磨了三天，才逼着自己去啃源码。

嗯，咱们今天就从整体架构入手，把地基打牢。

1.1 五层架构：从硬件到应用

Android系统从下往上，一共五层。我习惯把它想象成一栋楼：

• Linux内核层：地基。负责硬件管理、进程调度、内存管理。
• 硬件抽象层（HAL）：一楼。把硬件接口封装好，上层不用管你是高通还是联发科。
• 系统运行时层（ART & Native库）：二楼。Java代码在这里跑起来，核心C++库也在这。
• Java框架层（Framework）：三楼。我们平时调用的ActivityManager、WindowManager都在这里。
• 应用层：四楼。你写的App，还有系统预装的应用。

每一层只跟相邻层通信。说白了，就是「各管各的，接口说话」。

1.2 各层之间的核心交互机制

我挑三个最关键的交互点，给大家拆开看看。

1.2.1 应用层 ↔ Framework层：Binder IPC

你启动一个Activity，代码里写了个startActivity()。这个调用怎么跑到系统进程里去的？

答案是Binder。说白了，Binder就是一个跨进程调用工具。客户端（你的App）发一个请求，服务端（SystemServer）处理完再返回结果。

我曾经在项目里遇到过一个问题：App频繁跨进程调用，导致Binder线程池耗尽。嗯，那会儿查了好久才发现是某个第三方SDK在疯狂轮询。后来我加了个缓存，问题就解决了。

// 典型的Binder调用流程（伪代码）
// 客户端
Intent intent = new Intent(this, TargetActivity.class);
startActivity(intent); // 这里会通过Binder跨进程调用到AMS

// 服务端（ActivityManagerService）
public int startActivity(IApplicationThread caller, Intent intent) {
    // 处理启动逻辑
    // 最终通过Binder回调到App进程
}

1.2.2 Framework层 ↔ 系统运行时层：JNI调用

Framework层的Java代码，怎么调用到底层的C++库？

靠JNI（Java Native Interface）。比如你创建一个线程，Java层的Thread.start()最终会调用到native层的pthread_create。

这里有个坑：JNI调用是有性能开销的。我建议你在高频调用的地方，尽量减少JNI边界穿越次数。比如一次传一个数组，别一次传一个元素。

1.2.3 系统运行时层 ↔ HAL层：硬件服务调用

你的App要打开摄像头，流程是这样的：

1. App调用Camera.open()
2. Framework层通过Binder调用CameraService
3. CameraService通过HAL接口调用底层驱动

HAL层的作用，就是把各家芯片厂商的差异屏蔽掉。你想想看，高通和联发科的摄像头驱动肯定不一样，但上层代码不用改。这就是HAL的价值。

1.3 启动流程中的关键角色

在后续章节中，我们会反复遇到这几个角色。先混个脸熟：

角色	所在层	职责
init进程	Linux内核层之上	启动所有用户空间进程，解析init.rc
Zygote进程	系统运行时层	孵化所有Java进程，预加载核心类
SystemServer	Java框架层	启动所有系统服务（AMS、WMS等）
ActivityManagerService	Java框架层	管理Activity生命周期、进程调度

1.4 我的一点个人体会

学Android架构，最忌讳「只见树木不见森林」。很多人盯着一个细节猛抠，结果连整体流程都说不清楚。

我建议你：先画一张架构图贴在墙上。每次看源码时，先问自己「我现在看的是哪一层？它跟上下层怎么通信？」。养成这个习惯，后面学启动流程会轻松很多。

好了，第一章就到这里。下一章咱们从按下电源键开始，一步步追踪系统是怎么活过来的。