Chapter 168: launchd, XPC, System Daemon, Service Access

Apple 平台上的系统能力访问，可以从一个用户可见现象切入：App 调用一个公开 Framework API，请求读取钥匙串、访问照片、建立网络通道、发起定位、播放受保护媒体，最终得到成功结果、权限错误、连接失效或后台受限。读者读完本章应能追踪这条路径：App 进入 Framework，Framework 建立 XPC 连接，launchd 定位并激活服务，daemon 根据调用者身份和系统策略决定是否处理请求。

本章讨论的核心对象是 launchd、XPC、system daemon、agent、XPC service、Mach service name、entitlement、sandbox、audit token 与 TCC 状态。它们共同构成 Apple 平台中 App 访问系统能力的后台服务模型。公开文档能确认 launchd 负责按需启动和管理服务，XPC 提供进程间通信和服务隔离；iOS、iPadOS 与 macOS 的完整内部服务命名、私有 daemon 实现和权限细节存在私有边界，正文只把公开材料、可观察行为和合理架构推断连接成判断路径。

贯穿材料采用一个抽象但贴近真实系统的例子：相册类 App 调用照片选择、媒体解析或云同步相关 API。App 表面上只面对 Photos、AVFoundation、CloudKit 或 Foundation 层对象；后台路径可能经过 Framework helper、XPC connection、系统 daemon、隐私授权服务、文件访问策略、媒体或网络服务。这个例子用来说明 Apple 服务模型的关键结论：App 拿到的公开 API 结果，来自多个后台服务对身份、权限、生命周期和资源状态的共同判断。

168.1 launchd 作为系统服务管理根节点

launchd 是 Apple 系统服务管理链上的根节点。这里的根节点指用户态服务的启动、监督、按需激活和退出协调入口。Apple 的 Daemons and Services Programming Guide 说明，系统启动后内核运行，随后 launchd 完成系统初始化；它读取 daemon 配置、注册 socket 和文件描述符、启动常驻任务，并在请求到达时按需启动目标服务。Apple 的 Creating Launch Daemons and Agents 给出的描述面向 OS X / macOS，但它揭示了 Apple 服务模型的主干：服务入口先由 launchd 持有，服务进程可以晚于客户端请求启动。

在传统应用视角中，后台服务像一个已经运行的进程；在 launchd 模型中，服务首先是一个可注册的系统入口。配置文件给出服务 label、可执行程序、启动条件、socket、文件描述符、Mach service name 等信息。launchd 根据这些信息把“服务存在”与“服务进程正在运行”拆开。客户端看到的是可连接的服务入口；实际进程由请求、系统启动阶段、KeepAlive 策略、空闲状态和崩溃恢复共同决定。

这个拆分直接影响 App 访问系统能力的路径。App 调用公开 Framework API 时，Framework 可能连接一个后台 daemon。该 daemon 当前可能已经运行，也可能由 launchd 因为这次连接被激活。App 的同步或异步调用因此包含两个阶段：先找到可连接入口，再等待服务处理请求。Apple 文档明确指出，launchd 可以先注册服务所需的描述符，让请求在服务尚未启动时被延后，等服务启动后继续处理。这让服务启动顺序从静态依赖表变成按请求触发的控制面。

对移动 OS 架构而言，launchd 的价值在于把后台进程数量、启动时机和失败恢复纳入系统控制。系统无需让所有能力后端长期占用内存和 CPU；请求到达、用户登录、系统状态变化、文件系统事件、定时条件或 KeepAlive 策略才触发对应服务。移动设备受电量、温度和内存压力约束，按需激活能把后台能力包装成可调度资源。服务模型因此服务于同一个目标：系统能力持续存在，进程生命周期由平台策略控制。

在照片访问例子中，App 调用 PHPickerViewController 或媒体相关 API 时，App 侧无需知道后台服务是否已经启动。Framework 只需要把请求放入平台规定的通道。launchd、Framework 和 daemon 共同承担服务发现、启动和连接建立。App 看到的结果是 picker 弹出、媒体元数据返回、授权失败或连接错误；后台路径中的根节点是 launchd 对服务入口和进程生命周期的管理。

168.2 Daemon、Agent、XPC Service 的服务形态

Apple 服务模型中的后台程序可以按作用域分成 system daemon、user agent 和 XPC service。System daemon 面向系统范围的后台工作，通常在用户登录前就可能存在，权限、所有者和配置位置由系统域控制。User agent 面向用户会话，跟随登录用户的生命周期运行。XPC service 通常是应用或系统组件拆出的 helper 进程，用来承载隔离任务、较小权限集或不稳定代码路径。

Daemon 的关键特征是服务于系统能力。它可能管理网络配置、登录、通知、隐私数据库、媒体库、定位、蓝牙、钥匙串、同步或设备状态。它拥有比普通 App 更靠近系统策略和受保护资源的位置。它可以接收多个客户端请求，并基于调用者身份做策略判断。对 App 而言，daemon 是公开 API 后面的能力所有者；对系统而言，daemon 是可监督、可重启、可限制的后台责任主体。

Agent 的关键特征是绑定用户上下文。macOS 上的 LaunchAgents 适合需要用户会话、用户环境或用户 UI 上下文的后台任务。Apple 文档说明，用户登录后会有 per-user launchd 加载用户 agent 配置，并在用户登出时终止这些 agent。移动平台上用户会话形态与 macOS 不同，但“系统域服务”和“用户上下文服务”的区分仍然是理解 Apple 后台服务的必要维度：同一能力在系统域执行还是在用户上下文执行，会改变它可访问的数据、生命周期和错误边界。

XPC service 的关键特征是隔离。Apple 的 Creating XPC Services 说明，XPC Services API 集成 GCD 与 launchd，用于创建代表应用执行工作的轻量 helper；文档还说明 XPC service 常用于稳定性隔离和权限拆分。一个 App 可以把解析不可信文件、执行插件、处理图片或执行有限网络任务放进 XPC service，让崩溃和权限边界落在 helper 进程上。

三种形态的差异可以从同一组维度判断。System daemon 的入口由系统提供，客户端通常通过公开 Framework 间接接触；user agent 绑定用户登录状态，适合用户上下文工作；XPC service 常作为 bundle 内 helper 或系统组件内部 helper，服务入口和可见范围更窄。它们都能由 launchd 管理，但责任边界不同：daemon 承担平台能力后端，agent 承担用户会话任务，XPC service 承担隔离出来的工作单元。

照片访问例子可以映射到这些形态。照片库授权和数据库访问更像系统 daemon 负责的资源仲裁；一个图片处理 App 自己拆出的滤镜 helper 更像应用内 XPC service；一个随用户登录同步文件夹的桌面任务更像 user agent。判断服务形态时，先看谁拥有资源，再看服务作用域，最后看生命周期由系统启动、用户会话还是应用请求控制。

168.3 Framework Frontend 到 Daemon Backend 的调用路径

Framework frontend 是公开 API 表面，daemon backend 是能力后端。Frontend 的职责是给开发者稳定的类型、方法、回调、错误码和授权提示入口；backend 的职责是持有系统状态、执行权限检查、协调资源访问并返回结果。Apple 平台大量系统能力都呈现为这种前后端分离：App 直接链接 Framework，却通过 IPC 到达后台服务。

这条路径可以用一次照片资源请求描述。App 调用 Framework API，请求选择或读取某个媒体资源。Framework 先在进程内完成参数检查、对象包装和回调注册，然后创建或复用 XPC connection。连接目标可以是系统服务的 Mach service，也可以是 Framework 内部指定的 helper。消息中包含请求类型、参数、客户端期望的 reply 形式。daemon 收到消息后读取调用者身份，结合 entitlement、sandbox、TCC 状态和资源状态做判断，最后通过 reply callback 或异步事件返回结果。

图中的关键点是身份随请求进入后台服务。公开 API 的参数只能表达 App 想做什么，授权判断需要知道谁在请求。daemon 因此需要同时读取消息字段和连接对应的调用者身份。这个身份来源通常与 Mach/XPC 通道、进程凭据、代码签名和系统审计信息有关。正文后续把它收束到 audit token、entitlement、sandbox 和 TCC 状态四类检查点。

Framework frontend 还承担错误语义的翻译。daemon 返回的底层失败可能是连接失效、服务崩溃、权限缺失、资源忙、数据库锁、网络不可用、后台限制或内部策略拒绝。Framework 需要把这些失败变成开发者可处理的错误码、异常、delegate 回调或 completion handler。App 看到的通常是“未授权”“资源不可用”“请求取消”“连接中断”这类 API 结果；它不直接看到 daemon 的内部状态机。

这条前后端路径也是 Apple 私有实现边界所在。公开 Framework 名称、公开 API 行为、XPC 机制和 launchd 服务管理模型属于可讨论材料；具体某个 iOS 版本中某个私有 daemon 的服务名、消息格式、内部数据库结构和策略代码，属于公开材料覆盖不足的区域。工程判断应停在可观察行为与架构角色层：Framework 负责开发者表面，daemon 负责系统能力后端，IPC 负责跨进程边界，策略服务负责身份和权限判断。

168.4 XPC Connection、Message、Reply 与连接生命周期

XPC connection 是两个进程之间的虚拟通信端点。Apple 文档把 XPC connection 描述为独立于服务二进制当前是否运行的端点：服务进程可按需启动，连接对象仍然代表客户端对服务的通信意图。这个设计让调用路径可以先建立逻辑连接，再由 launchd 激活实际服务。

XPC message 是跨进程传输的结构化数据。C XPC API 使用自己的对象容器，支持适合跨进程传输的 primitive、dictionary、array、file descriptor 等对象；Foundation 层的 NSXPCConnection 则把消息包装成基于协议和 proxy object 的远程方法调用。两者层级不同，但共同点是把进程内方法调用拆成可序列化请求、跨进程投递、服务侧处理和 reply 返回。

Reply 是请求生命周期的收束点。客户端可以发送 fire-and-forget 消息，也可以发送带 reply 的消息。带 reply 的消息要求服务侧构造响应并发送回来。Apple 文档说明，C XPC API 的典型流程包括创建连接、设置 event handler 或目标队列、resume 连接、发送消息、按需启动服务、服务处理消息、通过 reply dictionary 返回结果，并在连接关闭等错误发生时调用 error handler。这个流程提示读者：XPC 的调用语义和普通函数调用不同，reply 可能延迟、失败、乱序到达或被连接错误打断。

连接生命周期有四个关键状态。第一是 created，客户端创建连接对象但尚未开始传输。第二是 resumed，连接开始接收事件和发送消息。第三是 interrupted，服务崩溃、重启或短暂不可达时，连接可能进入中断语义，客户端需要把未完成请求当作待确认状态处理。第四是 invalidated，连接被显式取消、服务端关闭或系统判定不可恢复，后续请求需要新连接或直接失败。

移动 OS 中的 XPC 调用还要承受生命周期压力。App 可能进入后台，进程可能被挂起，reply 回调可能推迟，服务可能因空闲被终止。一个稳健的 Framework 或 App API 设计通常把请求建模为可取消、可重试、可超时、可幂等的操作。幂等指同一请求重复发送时不会造成资源状态被错误推进，例如重复查询授权状态、重复读取同一只读资源、重复提交带 request identifier 的任务。

照片请求例子中，App 发起一次媒体读取。XPC message 包含资源标识、期望字段和 reply handler。若服务在处理期间崩溃，Framework 可能收到连接错误，再把它映射为请求失败或透明重试。若 App 进入后台，系统可能限制继续处理。若用户撤销照片权限，daemon 在处理时重新查询策略状态并返回拒绝。XPC 生命周期因此会直接进入用户可见结果。

168.5 Mach Service Name 与 launchd 按需启动

Mach service name 是 Apple 服务发现模型中的命名入口。这里的 Mach service 指通过 Mach bootstrap 命名空间注册的服务端口。客户端通过服务名请求连接，launchd 根据配置持有或注册该入口，并在需要时启动对应进程。公开 launchd 文档主要用 socket 和文件描述符解释按需启动；在实际 Apple 系统中，Mach service 也是系统服务发现和激活的重要形式。

在 launchd 管理模型中，服务名提供了一个稳定定位符。daemon 的可执行文件路径、运行用户、启动参数和 KeepAlive 策略可能是配置细节；客户端需要的是服务名。Framework 把服务名封装在内部，App 只调用公开 API。这样一来，Apple 可以调整后台服务实现、拆分 daemon、替换 helper 或改变启动策略，同时保持 Framework API 的兼容性。

按需启动的路径可以拆成五步。第一，系统或安装包提供 launchd job 配置，声明服务 label 和可被请求的入口。第二，launchd 在合适域中注册服务入口。第三，客户端通过 Framework 创建 XPC connection，目标是某个服务名。第四，若服务进程尚未运行，launchd 启动它并把连接交给服务端。第五，服务处理消息，后续空闲、崩溃、KeepAlive 和系统策略决定进程保留或退出。

Mach service name 的存在不代表 App 获得了直接能力。服务名解决“连接到哪里”的问题，权限检查解决“这个调用者能做什么”的问题。一个客户端即使能尝试连接服务，也可能在服务侧因 entitlement、sandbox、TCC 或调用上下文被拒绝。移动 OS 的安全边界因此分成两层：命名和连接是访问入口，策略检查是能力授予。

这一区分对分析后台失败很有用。若 Framework 调用失败发生在连接阶段，可能是服务名不可用、服务未能启动、连接被系统终止或进程生命周期受限。若连接成功但请求返回拒绝，重点应看 entitlement、sandbox、用户授权、资源状态或请求参数。把“找不到服务”和“服务拒绝请求”混在一起，会误判责任主体。

对照片请求例子而言，App 不需要知道照片库 daemon 的真实服务名。它只需要使用公开 API。Framework 内部把请求投递给后台服务，后台服务再访问照片库数据库、文件、iCloud 状态或隐私策略。服务名让 Framework 找到后端；后端策略决定本次请求能否得到资源。

168.6 Service Access 中的 Entitlement、Sandbox、Audit Token

Service access 的核心问题是服务如何判断调用者。Apple 平台把调用者身份拆成多个证据源：entitlement 表示代码签名授予的能力声明；sandbox profile 表示进程可执行的系统调用和资源访问范围；audit token 表示 IPC 发送者的内核审计身份快照；TCC 状态表示用户对隐私敏感资源的授权记录。daemon 通常把这些证据合并为一次策略判断。

Entitlement 是代码签名中的能力凭据。它说明某个二进制是否具有访问特定系统能力、App Group、Keychain Access Group、iCloud、Push、Background Modes 或受保护接口的资格。Entitlement 的价值在于把能力授权绑定到签名和分发边界。对第三方 App 来说，entitlement 由开发者配置、证书、profile、App Store 或企业分发路径共同约束；对系统进程来说，私有 entitlement 可表达更高权限的内部能力。

Sandbox profile 是进程运行时的访问限制。它控制进程能访问哪些文件、网络、Mach service、硬件资源和系统接口。Apple 的 XPC 文档说明，XPC service 默认运行在受限环境中，适合做权限拆分。这个点对架构理解很关键：同一个 App 可以把高风险解析逻辑放入更窄 sandbox 的 helper；系统 daemon 也可以把不同服务拆成不同权限集，让后台能力按责任隔离。

Audit token 是 IPC 身份判断的关键输入。它由内核在进程通信边界提供，包含发送者进程相关的审计身份信息。服务端可以利用 audit token 将一次消息绑定回调用者，再结合代码签名、entitlement 查询和 sandbox/TCC 状态做判断。它解决的问题是消息字段可伪造，通道身份需要由系统提供。daemon 信任内核给出的发送者身份，再用自己的策略表决定请求结果。

TCC 状态承担用户隐私授权判断。TCC 通常指 Transparency, Consent, and Control，对应相机、麦克风、照片、联系人、日历、定位等隐私敏感能力的用户授权记录和提示行为。App 发起请求时，Framework 可能触发系统提示；daemon 或隐私服务记录授权状态。后续调用中，后台服务根据调用者身份和授权状态决定放行、拒绝、返回受限数据集或要求用户重新授权。

四类证据的关系需要按顺序理解。Entitlement 说明二进制是否具备能力资格；sandbox 限制进程运行时可触达的资源和服务；audit token 把请求绑定到实际调用者；TCC 状态表达用户对隐私资源的授权。一次服务访问成功，通常需要这些证据共同满足。缺少 entitlement 可能让请求在服务侧被拒绝；sandbox 限制可能让客户端连接或资源访问失败；TCC 拒绝会让敏感数据不可用；audit token 异常会让服务无法确认调用者身份。

照片请求例子中，App 访问用户选择的照片可能走受限授权路径。Entitlement 决定 App 是否拥有相关平台能力资格，sandbox 决定 App 自身能访问的文件和服务范围，audit token 让后台服务确认请求来自哪个 App，TCC 状态决定照片访问范围。最终用户看到的差异可能是完整图库、有限照片集合、选择器返回的临时访问、权限弹窗或拒绝错误。

168.7 Daemon Failure、Restart、Crash 与系统恢复

Daemon failure 是 Apple 服务模型中必须显式处理的正常边界。后台服务可能崩溃、被系统终止、被更新替换、因空闲退出、因资源压力被回收，或因策略错误返回失败。launchd 的职责包括监督和重启符合策略的服务；XPC 的职责包括把连接中断、失效和错误事件传给客户端；Framework 的职责是把底层失败转化为开发者可处理的 API 语义。

Apple XPC 文档说明，XPC service 由 launchd 按需启动、崩溃后重启、空闲时终止；如果服务在处理需要回复的消息时崩溃，客户端会看到连接变为 invalid，直到服务重新启动。这个行为给出一个通用判断：服务重启能恢复入口可用性，但无法自动恢复所有 in-flight request。正在处理的请求需要由客户端、Framework 或服务端持久状态共同决定重试方式。

崩溃恢复可以拆成三个层级。第一层是进程层，launchd 根据 job 策略重启服务或限制过快重启。Apple 文档提示，如果 daemon 启动后过快退出，launchd 可能判定为崩溃并暂停后续启动。第二层是连接层，XPC connection 向客户端报告 interruption、invalidation 或 error。第三层是业务层，Framework 或 daemon 根据请求 id、事务状态和持久化记录决定是否重发、回滚或向 App 报错。

服务失败的用户可见结果取决于失败发生的位置。连接建立前失败，App 可能看到系统服务不可用或 API 调用失败。处理过程中失败，App 可能看到超时、取消、连接 invalid、资源读取失败或回调缺失。处理完成后 reply 丢失，客户端需要把结果当作未知状态处理。对于修改类请求，例如写入钥匙串、提交同步任务或改变设置，未知状态比明确失败更难处理，因为重复请求可能造成状态重复推进。

系统恢复还依赖状态放置位置。纯计算型 helper 可以接近无状态，崩溃后重试成本低。管理数据库、硬件设备或同步队列的 daemon 需要把状态持久化到数据库、文件、系统配置或云端事务中。移动 OS 服务通常偏向把长期状态放在 daemon 可恢复的数据结构中，把 App 侧连接看作临时会话。这样 App 进程被杀、连接断开或服务重启后，系统仍能基于持久状态恢复。

照片请求例子中，若媒体解析 helper 崩溃，Framework 可以重新创建服务并重新解析。若照片库数据库写入正在进行，服务需要事务保证索引、缩略图和元数据一致。若 App 只是请求读取某张用户授权的图片，失败可以表现为重试或错误回调。若用户在服务重启期间撤销授权，恢复后的请求应重新读取 TCC 状态，并以最新授权为准。

排查这类问题时，判断顺序应固定：先确认失败是连接阶段、处理阶段还是 reply 阶段；再确认调用者身份和权限状态；再判断服务是否崩溃、重启或被系统回收；最后看业务状态是否具备幂等重试条件。这个顺序能把“服务挂了”“权限没给”“后台受限”“请求状态未知”分开。

168.8 Apple 服务模型中的后台隔离和权限控制

Apple 服务模型把后台隔离和权限控制合成一条责任链。Framework 提供稳定的公开入口；XPC connection 把请求送出 App 进程；launchd 管理服务入口、按需启动和重启；daemon 持有系统资源和策略状态；entitlement、sandbox、audit token 和 TCC 共同决定调用者能获得什么结果。这条链把 App 代码和系统资源之间放入多个可监督边界。

后台隔离首先保护系统稳定性。App 崩溃不应带着系统 daemon 一起崩溃；daemon 崩溃也应通过连接错误和重启策略与 App 进程隔离。XPC service 进一步把 App 内部的高风险功能拆成 helper 进程，使插件、文件解析、媒体处理或脚本执行的失败被限制在较小进程内。移动 OS 关注交互连续性，后台隔离能把单点失败转化为可恢复错误。

权限控制其次保护系统资源。App 的 sandbox 让它无法任意读取其他 App 容器、系统数据库或硬件设备。Framework 让 App 以平台支持的方式表达意图。Daemon 在后台读取调用者身份，合并 entitlement、TCC 和资源状态后返回结果。这样系统能力以“App 通过受控 API 请求能力，由 daemon 代为仲裁”的形式交付，而非把设备文件直接开放给 App。

这个模型还支持平台演进。Apple 可以在不改变公开 API 的情况下调整后台 daemon、XPC 消息、缓存策略、隐私提示、系统数据库和硬件访问路径。开发者依赖的是 Framework 语义和公开权限模型；系统内部保留重构空间。移动平台需要长期兼容大量 App，同时持续收紧隐私和后台策略，这种前后端分离给平台留下策略更新空间。

版本边界需要明确。macOS 公开文档对 launchd、daemon、agent 和 XPC service 给出的材料更完整；iOS / iPadOS 的很多后台服务实现是私有的。读者分析 iOS 行为时，应使用公开 API 文档、系统权限提示、错误码、配置 entitlement、App Sandbox 行为和可观察日志作为证据，谨慎描述私有 daemon 名称和消息格式。架构结论可以讲“由后台服务仲裁”，具体实现细节应标注公开资料覆盖范围。

回到贯穿例子，照片类 App 的一次资源请求由多层共同完成。App 只表达用户意图和 API 参数；Framework 负责公开语义和连接；launchd 让服务入口持续存在并按需激活；daemon 负责资源所有权和策略判断；TCC 决定用户授权范围；sandbox 和 entitlement 固定进程可触达边界；XPC 把返回结果或失败送回 App。这条链解释了为什么同一个 API 在前台、后台、首次授权、撤销授权、服务重启、低内存或系统升级后可能得到不同结果。

可迁移的判断顺序是：先定位公开 API 属于哪个 Framework；再判断是否需要后台服务持有资源；接着找 IPC、服务入口和 launchd 生命周期边界；再检查调用者身份证据，包括 entitlement、sandbox、audit token 和 TCC；最后把失败映射到连接失败、策略拒绝、资源不可用、服务崩溃或生命周期限制。这个顺序能把 Apple 平台的服务访问从一组私有名词还原成可分析的责任链。

最小自检任务

你在设计一个图片整理 App。App 调用公开 Framework 读取用户选择的照片，并把缩略图生成放入应用内 XPC service。某次用户反馈：前台第一次使用时系统弹出照片授权提示，选择有限照片集合后可以看到部分图片；几分钟后 App 进入后台，再回到前台时部分缩略图生成失败，并出现一次连接失效错误。请写出这次行为的系统路径，区分 Framework、launchd、daemon、XPC service、entitlement、sandbox、audit token 和 TCC 各自承担的判断职责，并说明失败可能发生在哪些边界。

答案要点

请求路径应从 App 调用照片相关公开 Framework API 开始。Framework 负责把 App 意图转换为系统请求，并通过 XPC 或内部服务通道到达后台照片服务。launchd 负责让相关服务入口可连接，并在服务尚未运行时按需激活后台进程。照片相关 daemon 持有照片库资源、隐私状态和资源访问策略，不能把文件系统路径直接交给任意 App 自行读取。

权限判断应拆成四类证据。Entitlement 表示 App 是否具备相关平台能力资格；sandbox 限制 App 和应用内 XPC service 的文件、网络和服务访问范围；audit token 让后台 daemon 把请求绑定到真实调用者；TCC 状态记录用户对照片资源的授权范围。用户选择有限照片集合后，daemon 返回的数据集应受 TCC 授权范围约束。

缩略图生成失败可以发生在应用内 XPC service 边界。该 service 由 launchd 管理并按需启动，崩溃、空闲终止、后台状态变化或连接 invalidation 都可能让 App 看到连接失效。若失败发生在照片 daemon，表现更可能是资源读取失败、权限拒绝或系统服务不可用。若失败发生在后台生命周期策略，表现可能是回调延迟、任务取消或恢复后需要重新发起请求。

核心结论是：公开 API 成功返回一部分图片，说明 Framework 到 daemon 的服务路径和 TCC 限定授权已经成立；缩略图失败和连接失效更指向应用内 helper 的 XPC 生命周期或后台状态压力。排查顺序应先看授权范围，再看 XPC service 崩溃或失效，再看后台切换时请求是否具备重试和幂等标识。

本章知识点总结

• 根节点：launchd 负责用户态服务入口、按需启动、监督、重启和退出协调。
• 入口分离：服务名或描述符可以先存在，服务进程可以在请求到达时再启动。
• 服务形态：system daemon 面向系统能力，user agent 绑定用户会话，XPC service 承担隔离 helper 工作。
• 前后端链：Framework 给 App 稳定 API，daemon 在后台持有资源状态和策略判断。
• XPC 连接：XPC connection 是虚拟通信端点，服务进程当前未运行时仍可表达连接意图。
• 消息回复：XPC message 和 reply 把一次调用拆成序列化请求、服务处理、异步返回和错误事件。
• 服务命名：Mach service name 解决服务发现和激活入口，权限检查决定调用者可获得的能力。
• 身份检查：entitlement、sandbox、audit token 和 TCC 状态共同构成服务访问的身份与权限证据。
• 失败恢复：daemon crash、service restart、connection invalidation 和 in-flight request 需要分别判断。
• 后台隔离：Apple 服务模型用 Framework、XPC、daemon 和 sandbox 把 App 代码与系统资源隔离。
• 平台边界：macOS 公开材料更完整，iOS / iPadOS 私有 daemon 细节需要停在公开行为和架构角色层分析。
• 判断顺序：分析 Apple 服务访问时先定位 Framework，再看服务后端、连接生命周期、身份策略和用户可见失败。