Android进程空间：framework与services的深度解析

在 Android 的浩瀚代码库中，framework.jar 和 services.jar（是构建整个系统的基石。要从进程的角度理解它们，我们可以把它们想象成“随身工具箱”与“中央政府办公厅”的关系。

以下是深度解析：

---

1. 进程空间的归属：谁加载了这些代码？

理解代码运行空间的核心在于：哪个进程的虚拟机（ART/Dalvik）加载了这些类？

framework.jar：无处不在的“随身工具”

• 加载者： 几乎所有 Java 进程（包括 system_server 和所有 App 进程）。
• 原理： 在 Android 启动时，Zygote 进程会预加载 framework.jar。由于所有的 App 进程都是从 Zygote fork 出来的，它们都会继承这部分内存映射（Copy-on-Write）。
• 运行空间： 当你的 App 调用 View.setOnClickListener 或者 Context.getPackageName 时，这些代码运行在你 App 自己的进程空间内。它不需要跨进程，直接在本地执行。

services.jar：坐镇中央的“权力机构”

• 加载者： 主要是 system_server 进程。
• 原理： system_server 是 Android 的核心管理进程。它在启动时会显式地将 services.jar 加载进自己的类加载器中。
• 运行空间： 这里面包含了 ActivityManagerService (AMS)、WindowManagerService (WMS) 等核心逻辑。这些代码只运行在 system_server 进程中。

---

2. 如何区分代码运行在哪个空间？

区分的关键在于调用链（Call Stack）以及是否发生了跨进程通信（IPC/Binder）。

场景 A：本地调用（运行在 App 进程）

当你编写 Toast.makeText(...).show() 时：

1. Toast 类属于 framework.jar。
2. 代码在你的 App 进程中分配内存、设置参数。
3. 结论： 此时你处于 App 的代码运行空间。

场景 B：跨进程请求（运行在 System 进程）

接上面的例子，当 show() 被调用时，底层会通过 Binder 机制调用 NotificationManagerService：

1. 你的进程通过 INotificationManager.Stub.Proxy 发送请求。
2. 边界切换： CPU 执行流穿过内核，进入 system_server 进程。
3. 在 system_server 内部，NotificationManagerService.java（属于 services.jar）开始执行逻辑。
4. 结论： 此时核心逻辑运行在 system_server 进程空间。

---

3. 核心差异对照表

特性	framework.jar	services.jar
主要内容	SDK 公开 API、内部辅助类、Binder 客户端 (Proxy)	系统服务实现类 (AMS, PMS, WMS)、Binder 服务端 (Stub)
存在进程	所有 Java 进程 (Zygote 的子孙)	仅 system_server
内存占用	由 Zygote 共享映射，每个进程都有访问权	仅在 system_server 堆内存中
崩溃影响	仅导致当前 App 闪退	导致 system_server 崩溃，进而引发 Runtime 重启（手机变砖/重启）
角色比喻	办事指南和本地文具	办事大厅的窗口服务人员

---

4. 进阶理解：进程空间的“桥梁”

如何判断一段代码属于哪边？看 Binder。

• 如果你在源码中看到 extends Binder 或者 extends IXXX.Stub，这通常是 services.jar 里的东西，准备好被别人跨进程调用的。
• 如果你在源码中看到 ServiceManager.getService("...") 拿到的对象，那通常是一个“影子”（Proxy），它在 framework.jar 里定义，目的是把你的指令传送到 services.jar 所在的 system_server 进程中。

直白点说：

如果你在 App 里改了 framework.jar 的一个静态变量，只有你自己的 App 能看到改动；

但如果你在 services.jar 里改了一个静态变量，全系统的行为可能都会跟着改变。

从进程视角看，framework.jar 是分布式的（多份实例，各进程一份），而 services.jar 是单例的（全系统仅此一家，在 system_server 进程里）。

从驱动工程师的视角来看，Android 的进程树不仅仅是 PID 的递增，它实际上是一条从内核空间到用户空间、从原生 C++ 环境到 Java 虚拟机环境的演进路径。

以下是 Android 系统进程树的核心脉络及其相互关系：

---

1. 根基：内核进程 (Kernel Space)

在驱动层面，一切始于内核。

• idle 进程 (PID 0)： 系统启动后的第一个进程，负责 CPU 负载均衡和功耗管理。
• kthreadd (PID 2)： 所有内核线程的鼻祖。你编写的驱动程序如果创建了内核线程（如 kworker），它们的父进程都是它。

---

2. 第一号用户进程：init (PID 1)

内核挂载根文件系统后，启动 /system/bin/init。它是所有用户态进程的祖先。

init 进程会根据 .rc 文件（如 init.rc, init.hardware.rc）孵化出三大类关键子进程：

A. 关键原生守护进程 (Native Daemons)

这些进程通常直接与内核驱动交互：

• ueventd： 负责处理内核的 uevent，动态创建 /dev 下的设备节点（驱动工程师最常打交道）。
• logd： 日志系统。
• vold： 卷管理，处理 SD 卡、USB 挂载。
• servicemanager： Binder 机制的“大管家”，管理所有服务的注册与查询。
• hwservicemanager： HIDL 服务的管家（虽然在较新版本中逐渐被 AIDL 取代）。

B. 硬件抽象层进程 (HALs)

这是驱动工程师的“主战场”。在 Project Treble 之后，HAL 运行在独立的进程中：

• android.hardware.graphics.allocator@X.X-service： 显卡驱动相关。
• android.hardware.camera.provider@X.X-service： 摄像头驱动相关。
• vendor..hw-service： 各种厂商自定义的硬件服务进程。

C. Java 世界的启动器：Zygote

• Zygote / Zygote64： 它是 Android 所有 Java 应用的母体。它预加载了你提到的 framework.jar，并初始化了 Art 虚拟机。

---

3. Android 进程树全景图

idle (PID 0)
└── kthreadd (PID 2)
    └── [kworker, ksoftirqd, ...] (内核驱动相关线程)

init (PID 1)
├── ueventd (管理 /dev 节点)
├── logd, vold, installd, adbd... (原生系统服务)
├── servicemanager (Binder 注册表)
├── hwservicemanager (HIDL 注册表)
├── /vendor/bin/hw/android.hardware.* (各种 HAL 进程，对接内核驱动)
│
├── Zygote / Zygote64 (加载 framework.jar)
│   ├── system_server (PID 核心，加载 services.jar)
│   │   └── (包含各种 Service: AMS, WMS, PMS, BMS...)
│   ├── com.android.phone (电话进程)
│   ├── com.android.systemui (状态栏/下拉菜单)
│   ├── webview_zygote (专为 Webview 服务的孵化器)
│   └── com.example.app (普通用户 App 进程)

---

4. 深度解析：framework.jar 与 services.jar 在树中的分布

作为驱动工程师，理解这两者的“物理分布”对调试系统性能非常重要：

framework.jar：分布式存在

• 位置： 在 Zygote 启动时被加载到内存。
• 空间： 当 Zygote fork() 出 App 进程或 system_server 时，这些进程通过写时拷贝 (COW) 技术共享了 framework.jar 的内存。
• 视角： 在进程树中，每一个从 Zygote 分裂出来的叶子节点（App）里都跑着 framework.jar 的代码。

services.jar：单点存在

• 位置： 仅由 system_server 进程显式加载。
• 空间： 它的逻辑只运行在 system_server 这个特定的进程中。
• 视角： 在进程树中，它是唯一的。如果 system_server 因为 services.jar 里的逻辑触发了 Watchdog 导致崩溃，init 进程会杀掉所有受影响的子进程并重启 Zygote，这就是所谓的“软重启”。

---

5. 驱动工程师视角下的跨进程流转

当你写了一个驱动并希望 App 访问时，流程在进程树上的跳跃如下：

1. 内核层： 你的驱动产生数据。
2. HAL 层： android.hardware.xxx-service 进程通过 ioctl 或 mmap 读取内核数据。
3. 系统服务层： system_server 中的某个 Service（来自 services.jar）通过 Binder 调用 HAL 进程获取数据。
4. 应用层： App 进程通过 framework.jar 提供的接口，再次利用 Binder 向 system_server 请求数据。

总结： init 是根，Zygote 是 Java 之源，system_server 是管理中枢。驱动位于最底层，通过 HAL 进程向上输送数据。