📚 课程目录第3章 System Service基础概念

3. System Service基础概念

在Android系统中，System Service（系统服务）是支撑整个框架层运转的核心组件。它们由SystemServer进程在系统启动时创建并注册，向应用层、框架层乃至其他系统服务提供跨进程能力。理解System Service，是进入Android系统级开发的第一道门槛。

一、什么是System Service

System Service是运行在system_server进程中的一类长期驻留服务对象。它们通常继承自Binder，通过ServiceManager注册为具名Binder服务，供其他进程通过Binder机制调用。常见的系统服务包括：

ActivityManagerService（AMS）：管理Activity、进程、任务栈与生命周期。
PackageManagerService（PMS）：负责APK解析、安装、权限与组件查询。
WindowManagerService（WMS）：管理窗口层级、输入分发与显示合成。
PowerManagerService：控制电源状态、唤醒锁与休眠策略。
BatteryService：采集电池信息并广播电量变化。

这些服务并非普通Java对象，而是具备跨进程访问能力的Binder服务端实体。应用通过Context.getSystemService()获取到的，其实是服务在客户端进程中的代理对象（Proxy），真正的实现位于system_server。

核心特征：System Service = 系统进程内驻留 + Binder服务端 + ServiceManager注册 + 跨进程可访问。

二、与普通Service的区别

Android中有两类容易混淆的“Service”：一是应用组件android.app.Service，二是系统服务System Service。二者名称相近，但定位、生命周期与通信方式完全不同。

对比维度	普通Service（应用组件）	System Service（系统服务）
所属进程	应用自身进程	system_server进程
启动方式	startService / bindService	SystemServer启动时创建并注册
生命周期	受应用与系统调度影响，可被回收	随系统启动创建，通常常驻至关机
通信方式	Intent、Binder、Messenger	Binder + ServiceManager查询
访问权限	应用内或导出组件	受系统权限、SELinux、签名校验约束
典型代表	音乐播放Service、下载Service	AMS、PMS、WMS、PowerManagerService

从开发视角看，普通Service是“应用内的后台任务载体”，而System Service是“系统能力的提供者”。前者关注任务执行，后者关注系统资源与状态的统一管理。

三、Binder通信机制简介

System Service之所以能被跨进程访问，依赖的是Android的Binder IPC机制。Binder是一种基于内核驱动的C/S架构通信方式，具备一次拷贝、身份校验、线程池管理等特性。

一次典型的Binder调用流程如下：

客户端通过ServiceManager.getService("activity")获取AMS的Binder代理。
客户端调用代理方法，参数被序列化写入Parcel。
Binder驱动将请求传递到system_server中的Binder线程。
服务端onTransact()解析Parcel，执行实际逻辑。
结果写回Parcel，经驱动返回客户端。

// 客户端获取系统服务代理
IBinder binder = ServiceManager.getService("activity");
IActivityManager am = IActivityManager.Stub.asInterface(binder);

// 跨进程调用
am.startActivity(...);

// 服务端Stub处理
public boolean onTransact(int code, Parcel data, Parcel reply, int flags) {
    switch (code) {
        case START_ACTIVITY_TRANSACTION:
            data.enforceInterface(DESCRIPTOR);
            // 执行实际逻辑
            return true;
    }
    return super.onTransact(code, data, reply, flags);
}

在AIDL或手动编写的Binder接口中，Stub是服务端骨架，Proxy是客户端代理。System Service通常直接继承Binder或使用AIDL生成的Stub，并通过ServiceManager.addService()完成注册。

提示：应用层通过getSystemService()拿到的对象，本质是System Service在客户端进程中的代理，并非服务本体。真正的服务实现始终运行在system_server。

四、典型场景与常见误区

场景：应用查询当前前台应用

应用调用ActivityManager.getRunningAppProcesses()时，实际是通过Binder向AMS发起请求。AMS在system_server中查询进程状态，再将结果返回。整个过程对应用透明，但背后是一次完整的跨进程通信。

场景：系统启动时注册服务

SystemServer在startBootstrapServices()、startCoreServices()、startOtherServices()三个阶段中依次启动并注册系统服务。例如AMS在Bootstrap阶段启动，因为其他服务依赖它；而一些非关键服务则放在Other阶段。

常见误区一：把System Service当成普通Service去startService()。System Service不能通过Intent启动，只能由SystemServer创建。
常见误区二：认为getSystemService()返回的是服务本体。实际上它是代理对象，直接强转为服务实现类会失败。
常见误区三：忽略权限与SELinux限制。即使拿到Binder代理，没有对应权限或SELinux策略，调用仍会被拒绝。

复盘要点：

System Service运行在system_server，普通Service运行在应用进程。
System Service通过ServiceManager注册，通过Binder跨进程访问。
客户端持有的是Proxy，服务端是Stub，二者通过Binder驱动通信。
开发系统服务时，需关注启动阶段、权限声明、SELinux策略与线程模型。

掌握System Service的概念、与普通Service的差异以及Binder通信路径，是后续开发自定义系统服务、修改框架层行为的基础。下一阶段将深入SystemServer启动流程与ServiceManager注册细节。