2. Android系统架构概览

要理解ServiceManager为什么能成为Android系统中“服务的总机”，必须先看清它所在的整栋“大楼”。Android系统并非一个扁平的Linux发行版，而是从内核到应用被划分为五个层次：内核层（Kernel）、硬件抽象层（HAL）、系统服务层（System Services / Native Libraries + Android Runtime）、框架层（Java API Framework）与应用层（Applications）。每一层只通过明确定义的接口向上提供服务，向下依赖能力。Binder并不是某一层的私有物，而是贯穿内核层、系统服务层与框架层的一条“通信总线”。

一、五层结构的分工与依赖方向

自下而上，各层职责如下：

• 内核层：Linux内核、驱动、内存管理、进程调度、电源管理。Binder驱动（/dev/binder）就位于这一层，是唯一被内核直接支持的IPC机制。
• HAL层：以.so动态库形式封装摄像头、音频、传感器、蓝牙等硬件差异，向上提供统一接口，使框架层无需关心具体芯片。
• 系统服务层：包含Native库（libc、libutils、libbinder）与Android Runtime（ART），以及大量常驻系统服务进程，如servicemanager、surfaceflinger、media_server、zygote。
• 框架层：以Java/Kotlin实现的ActivityManagerService、PackageManagerService、WindowManagerService等，通过Context.getSystemService()暴露给应用。
• 应用层：普通App、系统App，通过AIDL生成的Stub/Proxy与框架层交互。

依赖方向是单向的：应用层调用框架层，框架层通过Binder调用系统服务层，系统服务层通过HAL访问硬件，HAL最终落到内核驱动。反向的数据回调同样沿这条链路返回。

二、Binder在架构中的定位

Binder是Android的进程间通信（IPC）机制，也是整个系统服务体系的“神经系统”。它的定位可以从三个视角理解：

1. 内核视角：Binder驱动提供open、mmap、ioctl接口，实现一次拷贝（mmap映射接收方缓冲区）与线程池管理，是性能优于Socket与共享内存的关键。
2. 系统服务视角：所有系统服务在启动时向servicemanager注册，客户端通过名字查询得到Binder代理，从而跨进程调用。
3. 框架视角：Java层的IBinder、Binder、BinderProxy、Parcel与Native层libbinder一一对应，AIDL自动生成代理与桩代码。

三、五层与Binder的关系图解

下图把五层结构、典型组件以及Binder的贯穿路径放在同一张图中，便于建立整体空间感。

四、一次跨层调用的完整链路

以“App获取当前前台Activity”为例，调用链如下：

App进程
  └─ ActivityManager.getRunningTasks()
       └─ IActivityManager.Stub.Proxy（AIDL代理）
            └─ BinderProxy.transact()  →  Parcel打包
                 └─ libbinder（Native）
                      └─ ioctl(/dev/binder)  →  Binder驱动
                           └─ 目标进程 system_server 的 Binder 线程
                                └─ ActivityManagerService.onTransact()
                                     └─ 返回结果沿原路回传

可以看到，一次调用同时穿过了应用层、框架层、系统服务层与内核层。Binder驱动负责线程调度与数据搬运，servicemanager负责让App先“找到”AMS的Binder句柄。

五、各层关键组件与Binder关系清单

六、常见误区与复盘