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，可以精准定位死锁或耗时操作。