Chapter 44: System Service Model

移动系统中的应用很少直接拥有相机、定位、音频、窗口、电源和包管理这类能力。应用看到的是 Framework API，真正持有状态、执行策略、协调并发和连接驱动的对象通常位于系统服务层。本章要建立的判断能力是：看到一个 App 可见行为时，能够追踪它进入哪个 Framework 入口，经过哪个系统服务，在哪个边界执行权限与策略检查，再由哪个 HAL、daemon、driver 或公开系统组件完成资源操作。

系统服务（System Service）是移动 OS 把硬件能力、用户授权、应用生命周期、进程身份和平台策略收束到一起的承载单元。它的输入是 App 请求、调用者身份、当前系统状态和底层资源状态；它的输出是成功结果、延迟回调、降级结果或可见失败。这个定义覆盖 Android 的 framework service、native service 和 vendor-facing service，也覆盖 Apple 公开模型中的 daemon、XPC service、framework 后端与受 entitlement 约束的系统能力。

贯穿本章的材料是一条定位请求路径：天气 App 请求当前位置。App 调用公开定位 API；Framework manager 先做参数与生命周期包装；IPC 把请求送到定位服务；服务读取调用者身份、权限状态、前后台状态、电源策略和定位 provider 状态；底层可能连接 GNSS、Wi-Fi、蜂窝、传感器融合或缓存；结果再通过回调返回给 App。这个例子足够典型，因为它同时涉及权限、并发、后台限制、硬件能力、缓存和失败表现。

公开资料只能支撑到公开边界。Android 侧可以使用 AOSP 架构、Binder IPC、HAL 和 ServiceManager 这些公开模型，Android architecture overview 与 Android Binder IPC 文档 提供了系统分层与 Binder 域的公开依据。Apple 侧可以使用 XPC 文档 与 Apple 归档的 launchd daemon/agent 文档 来解释 daemon 启动、按需运行和进程间通信模型；iOS 上大量具体服务实现属于私有系统边界，本文只把公开行为放入架构角色中解释。

44.1 System Service 作为系统能力承载单元

系统服务承载的是“可被平台管理的系统能力”。这里的能力指一组被系统统一命名、统一授权、统一调度并能向应用返回结果的操作集合。相机能力包含设备枚举、会话配置、预览流、拍照请求、错误回调和资源释放；定位能力包含 provider 选择、权限检查、精度控制、后台策略、缓存和回调；窗口能力包含焦点、层级、输入目标、显示区域和动画状态。能力进入服务层之后，系统就能把多个 App 的请求放到同一张状态表里处理。

定位请求可以展示服务承载能力的方式。天气 App 调用位置 API 时，App 只表达“我要一个当前位置”。定位服务实际处理的内容更多：调用者是哪一个 UID 或进程，是否具备位置权限，是否处在前台，是否允许精确位置，当前省电模式是否限制扫描，系统是否已经有可复用的缓存结果，底层 provider 是否可用。App 的一句请求在服务层被转换成一组带身份、策略和资源约束的系统状态更新。

这个模型让服务成为资源所有者。资源所有权不等于服务亲自操作寄存器，也不等于服务保存全部硬件数据。它表示服务拥有“谁能请求、请求如何排队、何时启动底层资源、何时停止、出错后如何恢复”的决策权。CameraService 可以决定哪个 client 拥有相机会话；AudioFlinger 或音频策略服务可以决定路由、混音和焦点；LocationManagerService 可以合并多个 App 的定位请求；WindowManagerService 可以维护窗口层级和焦点。

移动系统把这些决策放在服务层，原因来自手机约束。手机的同一颗相机、麦克风、GNSS、蓝牙控制器、屏幕和电池预算要服务多个 App、系统 UI、电话、闹钟、通知和后台任务。内核能隔离进程与管理设备节点，但内核缺少 App 生命周期、运行时权限、用户设置、商店策略和前台可见性这些平台语义。Framework API 能提供稳定接口，但 API 调用发生在 App 进程或 framework wrapper 中，无法成为全局仲裁点。服务层连接了平台语义和底层资源，因此成为系统能力的承载单元。

可以用一条责任链描述服务承载能力的边界：

这张图的核心点是服务同时面对上层语义和下层资源。Framework API 把请求格式化，IPC 保留调用者身份，服务读取策略与状态，底层 backend 执行实际访问。App 看到的是一次 API 成功或失败，系统内部看到的是一次带身份、权限、优先级、资源和恢复路径的能力调度。

服务也承担稳定性边界。应用进程崩溃时，服务可以释放该 client 的资源；服务进程重启时，系统可以重建服务表、重新注册句柄、通知客户端或让下一次调用重新连接；底层 HAL 或 driver 超时时，服务可以把错误转换成统一异常、回调或状态码。服务层把底层失败翻译成平台可处理的结果，降低硬件差异和厂商实现差异对 App 的直接冲击。

44.2 Framework API 与 Service Backend 的分离

Framework API 是应用可见的能力入口，Service Backend 是系统内部执行请求的后端。两者分离后，平台可以保持公开 API 相对稳定，同时调整服务内部实现、底层 HAL 版本、vendor service、driver 或硬件策略。开发者看到的是 LocationManager、CameraManager、AudioManager、PowerManager、PackageManager 这类 manager 或 public API；系统内部看到的是 Binder stub、服务对象、策略模块、provider controller、HAL client 和错误恢复代码。

这个分离让 API 具有平台契约属性。App 调用定位 API 时，公开契约通常表达请求频率、精度、权限要求和回调形式。服务后端可以把同一个请求映射到 GNSS、网络定位、传感器融合、缓存位置或低功耗策略。底层 provider 改变时，App 侧契约仍然保持“请求位置并接收结果”。这种稳定性支撑应用兼容，也给系统更新和设备差异留出空间。

Android 的典型路径是 Context.getSystemService() 或对应 framework manager 获取一个 manager 对象，manager 内部持有远端服务接口，Binder stub 把调用送到 system_server 中的服务或 native service。公开文档中，Android Binder IPC 文档说明 Android framework 与 HAL 之间使用 Binder 通信，并区分 /dev/binder、/dev/hwbinder、/dev/vndbinder 等 IPC 域；这反映出 framework、vendor 和 HAL 边界需要通过不同通信域隔离。正文不要求读者读取 AOSP 源码，但这个公开模型足以支持“API 表面和服务后端分离”的判断。

Apple 平台也存在类似分离。开发者调用 Core Location、AVFoundation、Network、UserNotifications、Photos 等公开 framework；framework 后端通过系统 daemon、XPC、entitlement、sandbox extension 或内部 IPC 与受控服务交互。公开 XPC 文档说明 XPC 用于进程间通信，launchd 文档说明 daemon 可以按需启动并由 launchd 管理。具体 iOS daemon 的内部方法、端口名和状态机通常不在公开文档中，因此正文只把它们归入“受 framework 和系统策略管理的服务后端”。

分离带来的第一个工程后果是权限检查可以集中。Framework API 可以做快速参数检查和开发者可见错误提示，服务后端必须在可信边界重新检查调用者身份、权限和策略。原因很直接：App 进程中的 wrapper 代码属于调用方可控环境，系统不能把它当成最终安全边界。服务端检查能读取真实调用者身份、系统授权记录、AppOps 或 entitlement 状态、用户设置和生命周期状态。

第二个工程后果是版本兼容可以集中。公开 API 的输入输出要照顾历史 App；服务后端可以按系统版本、设备能力、权限模型和 vendor 实现改变实际路径。Android 10 引入 Stable AIDL 来处理接口稳定性，Android 8 引入更明确的 binder context 来隔离 framework 与 vendor 通信域，这些版本事实说明移动系统把 API 稳定性、服务边界和 vendor 更新放在同一个兼容问题中处理。Apple 侧则通过公开 framework、entitlement、系统签名和受控 daemon 组合出更封闭的兼容边界。

第三个工程后果是失败翻译可以集中。底层 provider 返回 timeout、busy、not available、permission denied、thermal throttled 或 transport error 时，服务后端把它转成 API 层可理解的异常、回调、状态码或空结果。天气 App 获取位置失败时，它不需要知道 GNSS 芯片是否冷启动、Wi-Fi 扫描是否受限、定位 daemon 是否刚重启；它需要收到可处理的失败状态、权限提示路径或可重试信号。

44.3 Service Process、Daemon、Manager、Controller 的角色划分

服务模型中常见的角色包括 service process、daemon、manager、controller 和 registry。Service process 是承载服务代码的进程，例如 Android 的 system_server、media server 相关进程、surfaceflinger 或 vendor service 进程。Daemon 是长期运行或按需运行的后台系统进程，在 Apple 公开模型中通常由 launchd 管理，在 Android 中也有 native daemon 或 init 管理的系统进程。Manager 是 Framework 侧的客户端门面，负责给 App 提供稳定 API。Controller 是服务内部的状态协调模块，负责把策略和资源操作拆成更细的状态机。

这些角色位于不同信任边界。Manager 常在 App 进程或 framework library 中运行，它知道 API 形状，但不拥有全局状态。IPC stub 是调用跨进程时的序列化与分发边界，它携带调用者身份和参数。Service process 拥有系统权限和全局状态，但也需要把不同服务隔离在合适进程中。Daemon 可以专注某类能力，例如媒体、定位、通知、网络、设备管理或安全相关任务。Controller 位于服务内部，通常处理 session、client list、provider selection、policy evaluation 和 callback dispatch。

以定位请求为例，App 侧的 manager 接收 requestLocationUpdates 一类调用，把参数整理成请求对象，并通过 IPC 送到服务端。服务端入口先解析调用者身份，再交给权限模块、App 状态模块、provider controller 和电源策略模块。provider controller 决定使用缓存、GNSS、网络定位或融合 provider。结果回来后，服务端 callback dispatcher 再把结果送回对应 client。这里的 manager、IPC stub、service、controller 和 provider backend 各自承担一个窄职责。

Android 中的 system_server 是理解服务模型的关键对象。大量 framework service 运行在这个进程中，原因是它们共享系统状态、权限检查和应用生命周期信息。Camera、audio、surface、media、Bluetooth、telephony 等能力又会拆出 native service、HAL service 或 vendor service，因为它们接近硬件、性能敏感、崩溃风险高或属于 vendor 边界。服务是否放入 system_server，不取决于 API 名称，而取决于权限、状态共享、性能、隔离和更新边界。

Apple 公开模型更强调 daemon、framework 和 entitlement 的组合。App 调用公开 framework 后，framework 可以通过 XPC 或其他系统 IPC 与后台服务交互；launchd 负责系统 daemon 和用户 agent 的启动、按需运行和生命周期管理。具体服务是否常驻、是否按需启动、是否由单独 daemon 承载，属于系统实现选择。可确认的公开边界是：App 通过公开 framework 和 entitlement 获取能力，后台服务由系统管理，开发者无法直接把私有 daemon 当作公共 API。

Service process 与 daemon 的区别在于架构视角。Service process 强调“服务代码运行在哪里，崩溃影响多大，权限有多高”；daemon 强调“后台进程由谁启动、如何保持、如何按需响应”。Manager 与 controller 的区别在于调用方向。Manager 面向 App，控制 API 形状和兼容；controller 面向服务内部，控制资源状态和策略执行。把这几类角色混在一起，会导致读者把一个 public class 当成真正资源所有者，也会误把一个 daemon 当成公开 API。

可以用同一组维度比较这些角色：

角色	所在位置	主要输入	主要输出	判断边界
Framework manager	App 进程或 framework library	App 参数、生命周期上下文	IPC 调用、同步返回、回调注册	API 兼容与参数包装
IPC stub	进程边界	序列化参数、调用者身份	服务端方法调用	身份传递与跨进程分发
System service	系统进程或 daemon	请求、权限、全局状态、资源状态	结果、回调、错误、状态更新	资源所有权与策略执行
Internal controller	服务内部	client list、policy、provider state	provider 操作、session 状态	并发、状态机与恢复
HAL / driver backend	vendor 或内核边界	服务命令、buffer、配置	硬件结果、状态码、中断或回调	设备访问与硬件差异

这张表的用途是定位责任。App 参数错误通常先在 manager 或服务入口被拒绝；权限撤销通常在服务端策略检查中生效；硬件 busy 通常来自 HAL 或 driver 后端，再由服务翻译；服务崩溃会影响注册表与 client 连接；driver 故障会通过服务表现为 timeout、unavailable 或进程重启后的状态丢失。

44.4 System Service 生命周期：启动、注册、查询、调用、恢复

系统服务生命周期可以拆成启动、注册、查询、调用、恢复五个阶段。这个顺序解释了为什么 App 能在不同时间发现系统能力，也解释了服务故障后系统如何重新建立调用路径。移动 OS 的服务生命周期需要服务启动速度、开机时序、按需启动、后台功耗、崩溃隔离和 API 可用性之间保持平衡。

启动阶段决定服务进程何时存在。Android 中，一部分核心服务在系统启动时由 system_server 创建并启动；一部分 native daemon 由 init 或服务管理配置拉起；HAL service 可能按设备和版本进入不同进程。Apple 公开 launchd 文档说明，launchd 可以在系统启动后加载 daemon 配置、注册 socket 或文件描述符，并在请求到来时按需启动对应 daemon。两类平台都在解决同一个问题：系统能力要能被发现，同时服务进程数量、启动依赖和常驻开销需要受控。

注册阶段决定服务如何被命名和发现。Android 服务会把 Binder 对象注册到 ServiceManager 或对应 manager 中，client 通过服务名拿到 handle。HAL 层还有 hwservicemanager、AIDL service instance 和 manifest/matrix 之类的能力声明边界。Apple 公开模型中，launchd job 的 label、Mach service、socket 或 XPC service 名称可以成为能力发现入口；具体移动系统私有服务名称不属于稳定公开契约。注册表的共同作用是把“某个进程中的服务对象”变成“其他进程可查询的系统能力”。

查询阶段发生在 App 或 framework 准备调用能力之前。Android App 通过 framework API 获取 manager，manager 内部可能懒加载远端接口，也可能在服务死亡后重新获取。Apple App 调用公开 framework，由 framework 负责与后台服务建立连接或触发按需启动。查询阶段的输出通常是一个可以发送请求的代理对象、port、connection、handle 或服务引用；硬件结果要等到后续调用阶段才会产生。

调用阶段是策略与资源真正发生作用的位置。App 请求进入服务端后，服务先读取调用者身份，再检查权限、App 状态、用户设置、电源策略和资源状态。通过检查后，服务把请求加入内部状态机，决定启动底层 provider、复用缓存、合并请求、排队等待、抢占旧 client 或立即失败。定位请求的调用阶段可能返回缓存位置，也可能启动 provider，也可能因为后台限制和权限状态返回空结果或错误。

恢复阶段处理服务崩溃、底层超时、client 死亡和状态丢失。服务需要知道哪些状态可以重建，哪些状态必须让 client 重新发起请求。包管理、窗口、电源、通知这类服务有大量持久化或系统全局状态；相机、定位、传感器、媒体会有更多 session 状态和 callback 状态。服务恢复的关键不在于“恢复原样”，而在于把资源释放、状态重建、client 通知和下一次调用重新连接串成可预测行为。

服务生命周期可以用状态机表示：

这张状态图强调两个判断。第一，服务可被发现不代表底层硬件已经处在工作状态；定位服务可查询时，GNSS provider 可能尚未启动。第二，服务恢复后不一定保留旧 session；相机会话、定位订阅、传感器回调和音频流都可能需要 client 重新建立。读者排查 App 可见失败时，应先判断失败发生在发现阶段、调用阶段、策略阶段、backend 阶段还是恢复阶段。

44.5 Service Registry 与系统能力发现机制

Service Registry 是把服务名映射到可调用句柄、端口或连接入口的系统机制。它解决的问题是：调用方不需要知道服务进程的具体 PID、启动顺序和内部对象地址，就能通过稳定名称发现系统能力。移动系统的服务数量多、启动时序复杂、权限层级不同，registry 让服务发现成为受控入口。

Android 的 ServiceManager 是理解 registry 的典型例子。Framework service 把 Binder 对象注册到服务管理器；client 通过服务名查询；Binder driver 和用户态 libbinder 负责把远端对象调用变成事务。Android 8 后 Binder 文档中出现不同 binder context 和不同设备节点，是因为 framework、HAL、vendor 之间需要隔离服务发现域。/dev/binder、/dev/hwbinder 和 /dev/vndbinder 的存在说明“可查询的服务名”必须落在某个 IPC 域中，域本身就是平台边界。

Apple 公开模型可以用 launchd、Mach service、XPC service 和 Service Management 来理解 registry。launchd 文档说明 daemon 的配置可以声明 label、socket 和按需启动规则；XPC 给进程间通信提供连接模型。调用方连接的是一个服务名称或 endpoint，系统负责在合适时机启动或连接服务。具体 iOS 系统服务的内部 registry 名称通常不作为开发者可依赖接口，公开 framework 才是稳定入口。

Service Registry 让系统能力发现和权限边界分开处理。查询到服务句柄不代表调用已经被授权。句柄只是通信入口；真正的权限检查仍应在服务端方法中完成。原因是同一个服务可能向不同调用者开放不同子能力。例如包管理服务可以向普通 App 提供查询已安装包的受限视图，向系统组件提供安装、卸载、签名验证和权限管理能力；定位服务可以向一个 App 提供粗略位置，向另一个具备授权的 App 提供精确位置。

Registry 还承担故障恢复作用。服务死亡后，旧 handle 或 connection 失效；client 需要收到 death notification、connection invalidation、异常返回或下一次调用失败。Framework manager 可以隐藏部分重连细节，但不能保证所有 session 自动恢复。相机预览、音频录制、蓝牙连接、定位订阅都有可能在服务重启后失去原有状态。判断恢复问题时，先看服务是否重新注册，再看 client 是否重新查询，再看 session 是否需要重新建立。

能力发现也与平台兼容相关。Android 的 VINTF、HAL manifest 和 service instance 让 framework 能判断某个 HAL 能力是否存在、版本是否匹配、设备是否满足系统镜像要求。Apple 的封闭设备矩阵和受控 framework 能力则把发现过程更多放在系统内部，开发者通过公开 API 查询 capability、availability 或 authorization status。两者的共同目标是让上层根据稳定入口判断能力，而底层根据设备差异提供实现。

对读者而言，Service Registry 的可复用判断顺序是：先确认 App 调用的是哪个 public API，再确认 framework manager 查找哪个服务入口，然后确认这个入口属于哪个 IPC 域或 daemon 管理域，接着确认服务端是否重新检查权限，最后确认服务死亡或 backend 失败时 client 是否会重新查询。这个顺序能把“找得到服务”和“有权使用能力”拆开，也能把“服务存在”和“硬件可用”拆开。

44.6 App、Framework、Service、Driver 之间的调用边界

移动系统能力调用跨过四类边界：App 到 Framework 的 API 边界、Framework 到 Service 的 IPC 边界、Service 到 HAL 或 daemon 的实现边界、HAL 或 driver 到硬件的设备边界。每个边界都会改变请求的语义。App 说的是业务意图，Framework 说的是平台 API，Service 说的是策略化资源请求，HAL 或 driver 说的是设备命令、buffer、队列和状态码。

定位请求穿过这些边界时，语义不断收缩。App 说“给我当前位置”；Framework 把它变成带频率、精度、生命周期和 callback 的请求对象；IPC 把对象和调用者身份送到服务端；服务把它放入全局 client list，并结合权限、前后台、电源、provider 可用性和缓存判断执行方式；provider backend 决定读取 GNSS、网络定位、传感器融合或历史缓存；结果回到服务后，再按 App 授权精度和生命周期状态进行过滤并回调。

相机请求也能说明边界变化。App 通过 camera API 创建 session 和 capture request；Framework manager 检查设备列表、参数和回调；服务端检查权限、前台状态、设备占用和 client 优先级；HAL 接收 stream configuration、buffer 和 request；driver 与 ISP、sensor、DMA、interrupt 和 firmware 交互；服务再把 frame、metadata、error 或 disconnect 事件回传。App 看到的是预览、拍照成功、相机被占用或会话断开，服务看到的是一组 client、stream、buffer、policy 和 backend 状态。

音频请求的边界又强调共享和混合。App 请求播放或录音；Framework 包装 audio attributes、usage、session 和 focus；音频服务处理焦点、路由、混音、音量策略和设备状态；Audio HAL 与 codec、DSP、Bluetooth stack 或 USB audio 交互。这里的核心是服务如何把多个 client 的流混合、路由和策略化，单个硬件独占只是音频系统中的局部场景。电话、闹钟、媒体播放、导航播报和语音助手都要进入同一套音频策略。

这些边界决定排查顺序。看到 App 层失败时，先确认 API 输入和生命周期；再确认权限授权、系统设置和前后台状态；再确认服务端资源状态，例如是否被其他 client 占用；再确认 HAL 或 driver 的能力和错误；最后才把问题归因到底层硬件。这个顺序能减少误判，因为许多用户可见失败发生在服务策略层，底层硬件本身可能可用。

调用边界也决定日志和证据的含义。App log 只能证明 API 调用和回调表现；Framework log 能证明 manager 层参数和连接状态；service log 能证明调用者身份、权限、client list 和 policy decision；HAL log 能证明设备配置、buffer 和 backend error；kernel log 能证明 driver、中断、DMA、功耗状态和设备异常。没有服务层证据时，把一个 timeout 直接归因给硬件故障会跳过中间策略层。

本章不要求读者运行调试工具，但可以建立一个可迁移的静态判断表：

观察现象	优先定位层	需要追问的问题	典型用户可见结果
API 立即抛出参数错误	Framework API	请求参数、生命周期、API 版本是否匹配	调用失败、开发者可见异常
授权后仍无结果	Service policy	权限精度、前后台、电源、provider 状态是否允许	空结果、延迟、权限提示
相机显示被占用	System service	当前 owner、前台优先级、通话或系统 UI 是否占用	打不开相机、会话断开
播放有声但路由错误	Audio service / HAL	audio focus、route、Bluetooth、codec 是否匹配	声音走错设备、音量异常
服务重启后订阅丢失	Service lifecycle	client 是否收到死亡通知，session 是否重新建立	回调停止、需要重新打开页面
底层设备不可用	HAL / driver	HAL status、driver error、thermal 或 power state 是否异常	unavailable、timeout、降级

这张表服务于判断动作。读者看到一个现象时，不应先背服务名，而应把现象放入边界：参数错误偏 API，权限和前后台偏服务策略，资源占用偏服务状态，设备不可用偏 HAL 或 driver，重启后状态丢失偏生命周期恢复。

44.7 System Service Model 对手机系统架构的中心意义

System Service Model 是手机系统架构的中心模型，因为它同时解释权限、并发、资源所有权、故障隔离和平台兼容。移动 OS 的核心矛盾是“多个 App 和系统组件如何在有限电量、温度、隐私、传感器和网络条件下共同使用系统能力”；App 调用硬件只是这个矛盾中的表层行为。服务层正是这个矛盾的执行位置。

权限模型依赖服务层形成闭环。用户授权记录、App 身份、前后台状态、敏感指示器、撤销行为和精度设置都需要在可信系统边界执行。Framework API 可以展示权限请求入口，服务端必须在每次资源操作前重新判断授权和策略。定位权限撤销后，旧 App 进程里的 manager 对象仍可能存在；服务端检查能让撤销在下一次调用或持续订阅中生效。

并发模型也依赖服务层。相机、麦克风、音频路由、屏幕焦点、蓝牙扫描、定位 provider 和传感器采样都有多个 client。服务把这些 client 放入统一状态表，按前台可见性、用户操作、系统优先级、硬件能力和电源策略决定共享、合并、排队、抢占或拒绝。内核可以调度线程，但它不知道哪个相机 client 对应用户当前看到的预览画面；服务知道。

资源所有权通过服务层变成平台契约。应用无需知道设备树、HAL 版本、firmware 状态、driver queue 或 ISP buffer；应用只需要理解 public API、权限状态和失败回调。服务把不同设备上的硬件差异收敛到稳定行为，厂商可以在 HAL、driver 和 firmware 中适配硬件，系统可以在服务层维持一致的权限、生命周期和错误语义。

故障隔离也靠服务层完成翻译。App 崩溃时，服务根据 client death 释放资源；service 崩溃时，registry 和 framework manager 负责重新连接或暴露失败；HAL 崩溃时，服务把 backend 错误转成统一状态；driver 故障时，服务可以报告 unavailable、timeout 或触发重建。服务层让故障有边界、有返回、有清理动作。

平台兼容最终也回到服务模型。Android 通过 framework service、Binder、HAL、VINTF、AIDL/HIDL 和 vendor 边界处理多厂商硬件；Apple 通过公开 framework、daemon、XPC、entitlement、签名和受控硬件矩阵处理能力开放。两种平台形态不同，共同系统问题相同：公开 API 要稳定，底层实现要可替换，权限要可执行，资源要可仲裁，失败要可恢复。

因此，读移动 OS 时应把服务模型放在 kernel 与 app 之间。Kernel 提供进程、内存、设备、调度和安全原语；App 表达用户意图和业务请求；System Service 把两者连接成平台行为。掉帧、发热、定位不准、相机被占用、通知延迟、后台任务被推迟、蓝牙扫描受限，这些现象大多需要经过服务层才能解释完整。

本章建立的最终判断是：系统服务是移动 OS 的能力仲裁层，API 名词集合和后台进程列表都只能描述其中一部分。读者看到任何 App 可见系统能力，都可以按“public API → manager → IPC → service → policy/state → backend → result”的顺序追踪，并在每个边界判断责任主体、可见证据和失败表现。

最小自检任务

题目：一个天气 App 在用户已经授予位置权限后，仍然长时间拿不到当前位置。请按 System Service Model 写出这次请求的责任链，说明每一层需要判断什么，并给出至少三种可能的失败位置。要求覆盖 App 意图、Framework 入口、系统服务、策略检查、资源边界、底层 provider 和用户可见结果。

答案要点

App 意图是获取当前位置，Framework 入口是公开定位 API 和对应 manager。manager 负责把请求频率、精度、回调和生命周期包装成平台请求，并通过 IPC 送到定位服务。IPC 边界需要保留调用者身份，使服务端能够读取 UID、包名、权限记录和前后台状态。

系统服务是定位能力的资源所有者。它需要检查位置权限是否仍然有效、精确或粗略位置设置是否匹配请求、App 是否处于允许定位的生命周期状态、省电模式和后台策略是否限制扫描、当前 provider 是否可用、是否存在可复用缓存，以及多个 client 的请求是否可以合并。

底层 provider 可以是 GNSS、Wi-Fi、蜂窝、传感器融合或缓存。provider 不可用、冷启动耗时、弱信号、电源策略限制扫描、服务刚重启后订阅丢失，都会让 App 长时间没有结果。服务应把这些情况转成延迟回调、空结果、错误状态或权限/设置提示。

三种典型失败位置分别是：第一，Framework 或 App 生命周期层，页面已经停止但请求仍以旧回调等待；第二，服务策略层，权限存在但精度、后台状态或省电策略使服务拒绝启动高功耗 provider；第三，backend 层，GNSS 或网络 provider 当前不可用，服务只能等待、返回缓存或报告 unavailable。最终用户看到的结果可能是位置迟迟不更新、显示上一次位置、提示打开定位设置，或 App 展示“无法获取当前位置”。

本章知识点总结

• 服务承载：系统服务把硬件能力、用户授权、应用生命周期和系统策略收束成可管理的能力单元。
• 资源所有：服务拥有请求排队、并发仲裁、资源释放、错误恢复和结果翻译的决策权。
• API 分离：Framework API 提供稳定公开入口，Service Backend 处理权限、状态、HAL、daemon 和 driver 访问。
• 可信检查：权限和策略需要在服务端可信边界执行，App 进程内 wrapper 只能承担参数包装和开发者可见提示。
• 角色划分：manager 面向 App，IPC stub 负责跨进程分发，service 负责策略与状态，controller 负责内部状态机，backend 负责设备访问。
• 生命周期：系统服务经历启动、注册、查询、调用和恢复，App 可见失败需要放入对应阶段判断。
• 能力发现：Service Registry 把服务名映射到 handle、port 或 connection，但查询成功不等于调用授权成功。
• 边界变换：App 意图经过 Framework、Service、HAL 和 driver 后，会从业务请求逐步变成策略化资源操作和设备命令。
• 故障翻译：服务层把 App 崩溃、service 重启、HAL 超时和 driver 错误翻译成可清理、可回调、可重试的系统行为。
• 平台兼容：Android 和 Apple 的实现形态不同，但都通过服务层维持公开 API 稳定、底层实现可替换和用户行为可预测。
• 排查顺序：分析系统能力问题时，先定位 public API，再定位 manager、IPC、service、policy/state、backend 和用户可见结果。
• 中心模型：System Service Model 是理解移动 OS 的能力仲裁层，也是连接 kernel 原语和 App 行为的关键结构。