1. Framework Service 概述与演进
1.1 从单进程到跨进程服务的演进
Android 系统服务的核心设计目标是实现跨进程通信（IPC）。早期的单进程模块演变为多进程、高内聚、低耦合的Service架构，使得系统组件如ActivityManager、WindowManager、PackageManager等运行在独立进程中，并通过Binder机制向应用层提供服务。这种演进带来了以下关键优势：
- 隔离性：服务崩溃不影响上层APP进程。
- 可复用性：同一服务可被多个APP同时调用。
- 权限控制：通过ServiceManager统一管理注册和访问权限。
1.2 AIDL 与 Binder 基础
Binder是Android独有的IPC机制，底层基于内核驱动的Binder Driver实现。AIDL（Android Interface Definition Language）是定义Binder接口的语言，编译器自动生成Binder代理与Stub代码。开发者只需编写AIDL文件，即可实现跨进程服务调用。
AIDL 接口定义示例
// IMyService.aidl
package com.example.framework;
interface IMyService {
int add(int a, int b);
String getServiceName();
}编译后自动生成IMyService.java内部类Stub（用于服务端）和Proxy（用于客户端）。服务端需继承Stub并实现方法；客户端通过asInterface转型后即可调用。
Binder通信流程图
1.3 系统服务注册流程
在Android Framework中，系统服务（SystemService）的注册遵循固定生命周期：
- 创建服务对象：在SystemServer的main()中实例化，如
new WindowManagerService(context)。 - 获取ServiceManager引用：通过
ServiceManager.getService("window")（内部通过Binder查询）。 - 注册到ServiceManager：调用
ServiceManager.addService("window", service)。 - 发布给系统：部分服务还需调用
publishBinderService()将binder注册到LocalService。 - 启动服务循环：服务进入Looper循环处理回调。
| 步骤 | 关键类 | 核心操作 |
|---|---|---|
| 创建 | SystemServer | new XXXService(context) |
| 注册 | ServiceManagerNative | addService(name, binder) |
| 查询 | ServiceManager | getService(name) → 远程Binder引用 |
| 权限检查 | ContextImpl | checkCallingPermission() |
startBootstrapServices()和startCoreServices()之间注册服务顺序错误会导致依赖服务未就绪而崩溃。建议严格按照AOSP官方启动顺序添加自定义服务。
1.4 ServiceManager 角色
ServiceManager是Binder IPC的“电话总机”，运行于系统进程servicemanager中。它维护一张服务名到Binder引用的哈希表，提供addService()和getService()两个核心调用。所有系统服务在启动时向它注册，客户端通过服务名查询binder句柄，实现解耦。
- 注册：服务端调用
addService("service_name", binder)，ServiceManager将信息存入内部列表。 - 查询：客户端调用
getService("service_name")，返回binder引用；若服务未就绪，返回null或阻塞等待（取决于调用方式）。 - 死亡通知：服务端进程死亡时，ServiceManager会向注册了linkToDeath的客户端发送通知。
实际开发中，自定义Service无需直接操作ServiceManager，而是通过Framework提供的Context.BINDER_SERVICE机制和ServiceManager.addService()的封装API完成注册。本教程后续章节将基于AOSP代码详细演示添加一个完整的自定义系统服务。