一、AOSP系统服务概述：什么是系统服务、系统服务在Android架构中的位置、系统服务与APP的关系
各位同学，咱们今天聊聊Android系统里最核心的一个概念——系统服务。
说实话，我刚开始接触Android源码时，也被这一堆Service搞晕过。什么ActivityManagerService、WindowManagerService、PackageManagerService……名字长得像兄弟，功能却天差地别。后来我花了整整两周，才把这些服务的脉络理清楚。
嗯，今天我就把这份经验分享给你。
1.1 什么是系统服务
系统服务，说白了就是Android系统里那些常驻后台、提供特定功能的守护进程。它们不是普通的APP，而是系统级别的组件。
举个例子：你手机上的“设置”APP，它只是一个普通应用。但“设置”里能显示WiFi列表、能调整亮度、能管理应用权限——这些能力从哪来？
答案就是系统服务。
系统服务负责管理硬件资源、提供系统级API、协调应用之间的交互。它们运行在独立的进程中，拥有更高的权限。
核心特征：
- 系统级进程，通常以"system"用户运行
- 提供Binder接口供APP调用
- 生命周期由系统管理，APP无法直接创建或销毁
- 拥有系统权限，可以访问敏感资源
我记得有一次，我需要给一个定制ROM添加新的系统服务。当时踩了个坑——服务启动顺序没处理好，结果系统开机就卡在动画界面。后来我查了三天源码，才发现是依赖的服务还没准备好，我就急着注册了。
避坑指南：我曾经在Android 11上尝试在SystemServer里过早注册自定义服务，导致系统启动时死锁。记住：服务注册必须在Looper.loop()之前完成，且要处理好依赖关系。
1.2 系统服务在Android架构中的位置
咱们先看看Android的整体架构。从下往上，大致是这么几层：
| 层级 | 说明 | 示例 |
|---|---|---|
| 应用层 | 用户直接接触的APP | 微信、抖音、设置 |
| Framework层 | 系统服务、API框架 | AMS、WMS、PMS |
| 运行时层 | ART虚拟机、核心库 | libcore、libnativehelper |
| HAL层 | 硬件抽象层 | Camera HAL、Audio HAL |
| 内核层 | Linux内核、驱动 | Binder驱动、显示驱动 |
系统服务就位于Framework层。它们向上给APP提供API，向下调用HAL操作硬件。
你想想看，APP想打开摄像头，它不会直接去操作硬件驱动——那太危险了。APP会通过Binder调用CameraService，CameraService再去调用Camera HAL，最终由内核驱动完成操作。
这就是系统服务的桥梁作用。
我个人习惯把系统服务比作“酒店前台”。你（APP）想订餐、叫车、打扫房间，不需要自己去找厨师、司机、保洁员。你只需要给前台打个电话，前台会帮你协调一切。
系统服务就是那个前台。
1.3 系统服务与APP的关系
这个关系其实很简单，就三个字：服务与被服务。
APP是消费者，系统服务是提供者。APP通过Binder IPC调用系统服务的接口，获取所需的功能。
但这里有个关键点：APP无法直接访问系统服务的内部状态。所有交互都必须通过Binder接口。
小技巧：如果你想查看当前系统运行了哪些服务，可以在adb shell里执行：service list。这个命令会列出所有注册的系统服务及其Binder标识。
举个例子，APP想获取当前运行的进程列表：
// APP端调用
ActivityManager am = (ActivityManager) getSystemService(Context.ACTIVITY_SERVICE);
List<ActivityManager.RunningAppProcessInfo> processes = am.getRunningAppProcesses();
// 实际上，这背后是Binder调用到ActivityManagerService
// AMS内部维护着所有进程的信息，然后返回给APP你看，APP只是调用了getRunningAppProcesses()，但背后AMS做了大量工作：遍历进程列表、检查权限、格式化数据……
为什么要这么设计？说白了就是安全隔离。如果每个APP都能直接操作进程列表，那恶意应用就能随意杀掉其他应用，系统就乱套了。
我记得在Android 8.0之前，有些APP利用这个漏洞，通过反射调用系统服务的私有方法，绕过权限检查。后来Google在9.0里加了隐藏API限制，才堵住这个口子。
注意：从Android 9开始，系统限制了非SDK接口的调用。如果你在定制ROM里开发系统服务，记得把接口标记为@SystemApi，否则第三方APP可能无法调用。
1.4 系统服务的启动流程
系统服务是怎么启动的？简单说，就是SystemServer进程在开机时，按顺序启动所有服务。
启动顺序大致如下：
- Zygote进程孵化SystemServer
- SystemServer加载系统库、初始化Binder线程池
- 启动引导服务（如Installer、DeviceIdentifiersPolicyService）
- 启动核心服务（如ActivityManagerService、PackageManagerService）
- 启动其他服务（如WindowManagerService、InputManagerService）
- 通知系统就绪，允许APP启动
这里有个细节：服务启动顺序很重要。比如AMS必须在WMS之前启动，因为WMS需要AMS来管理窗口的Activity生命周期。
我曾经在定制系统时，想加一个“智能省电服务”，需要在电池服务之后、应用管理服务之前启动。结果我把它放到了最后，导致省电服务启动时，有些APP已经占用了大量资源，错过了最佳优化时机。
嗯，从那以后，我每次加新服务都会先画一张依赖图。
1.5 总结
这一章我们聊了：
- 系统服务是什么——常驻后台的系统级守护进程
- 它在架构中的位置——Framework层，连接APP和硬件
- 与APP的关系——服务与被服务，通过Binder通信
- 启动流程——SystemServer按序启动
下一章，我们会深入系统服务的核心——Binder机制。我会带你手写一个简单的Binder服务，让你真正理解它的工作原理。
到时候见。