Android 全栈架构终极指南：从 Linux 内核、Binder 驱动到 Framework 源码实战

在 Android 开发的进阶之路上，许多人常年困于 Java API 的调用。然而，Android 是一个庞大且错综复杂的有机体。Google 提供的 5 层经典架构图（Linux 内核、HAL、系统库、Framework、App）仅仅是系统的"静态骨架"。

真正的高手，看的是系统的"血液循环"------即动态执行流。代码是死的，但系统运转是活的。各模块运行在不同的进程与线程中，通过 Binder、Socket、Handler 进行着极其复杂的信息传递。只有像"庖丁解牛"一样透视各个模块的地位与价值，才能在处理性能优化、稳定性治理时游刃有余。

Android 系统的启动是一个由下至上、环环相扣的过程：Loader -> Kernel -> Native -> Framework -> App。

一切的起点始于内核。

swapper 进程 (pid=0)： 这是系统初始化的第一个进程，负责初始化进程管理、内存管理，并加载 Display、Camera、Binder 等核心驱动。
kthreadd 进程 (pid=2)： 所有内核进程的鼻祖，负责创建内核工作线程和守护进程。

当内核初始化完成后，系统进入用户空间（User Space）。

init 进程 (pid=1)： 所有用户进程的鼻祖。它负责孵化关键守护进程，如 logd（日志）、lmkd（内存回收）、installd（应用安装）及 adbd 等。
ServiceManager： Binder 服务的大管家，它是整个 IPC 通信的核心基石。

Zygote 进程： Android 系统的第一个 Java 进程。它预加载虚拟机、类和资源，并通过 Socket 接收请求 fork 出所有 App 进程。
System Server 进程： 由 Zygote 孵化的第一个进程，负责启动并管理 ActivityManager、WindowManager、PackageManager 等几乎所有 Java Framework 服务。

在 Android 架构中，Binder 不仅仅是一种通信方式，它是整个系统的架构灵魂。

Binder 通信包含 Client、Server、ServiceManager 和 Binder 驱动四个关键组件。

Binder 相比于传统的 Linux IPC（如管道、消息队列），在性能（只需一次拷贝）和安全性（支持调用者 UID/PID 识别）上具有不可比拟的优势。

Android 系统稳定性的核心在于对进程"生死"的控制，即 ADJ 算法 与 LowMemoryKiller (LMK)。

系统通过 updateOomAdjLocked 动态调整每个进程的优先级（ADJ 分数）。

当系统内存紧张时，内核中的 LMK 会介入。它主要依据 PSS (Proportional Set Size) 值来判断。PSS 是衡量进程真实内存占用的最准确指标，因为它按比例分摊了共享库内存。

AMS 是整个系统的指挥官。它不仅管理四大组件的启动过程（如 startActivity、startService），还维护着各种 Record 对象（如 ActivityRecord、ServiceRecord）来跟踪应用状态。

WMS 负责窗口的层级管理和显示。理解 WMS 的启动过程及 StartingWindow 的创建，是优化应用冷启动白屏的关键。

触摸事件的处理是一个高并发的典型。InputReader 线程负责读取原始事件，InputDispatcher 线程负责分发，最终传递给应用的 UI 线程。这个流程的任何阻塞都会导致臭名昭著的 ANR。

一个成熟的工程师不仅要会写代码，更要会通过"线索"排查故障。

ANR 的本质是超时。常见的触发场景包括 Input 点击超时、Service 启动超时等。

信息收集： 当 ANR 发生时，系统会执行 AMS.appNotResponding 过程，收集各进程的 Trace 文件。
Trace 解读： 通过分析 kill -3 生成的 Java Trace 或 debuggerd -b 生成的 Native Trace，可以精准定位死锁或耗时操作。

掌握 Android 底层架构没有捷径，只有阅读源码 (Read The Fucking Source Code)。当你不再纠结于 API 的参数，而是能脑补出背后成千上万个"小蝌蚪"般的动态执行流时，你才真正跨越了技术的瓶颈。

想深入学习以上章节的每一篇源码分析？

👉 请关注 Gityuan 博客导航，在这里，我们基于 Android 6.0+ 源码，为您呈现最纯粹的技术架构解析！