Chapter 166: Apple Full Stack Capability Path

读完本章，读者应能追踪一次 Apple 平台能力调用从 App 到硬件的完整责任链：App 先通过公开 framework 表达意图，framework 把请求转交给系统服务，系统服务根据签名、entitlement、sandbox、隐私授权和运行状态做决策，再通过 XNU、IOKit / DriverKit 或厂商私有驱动路径触达硬件，最后把成功、降级或拒绝结果返回给 App。

本章以“一个 iOS App 请求当前位置并展示结果”为贯穿材料。这个材料足够小：入口可以是 Core Location，用户可见结果可以是授权弹窗、定位回调、错误码或长时间无结果。它同时覆盖身份、权限、daemon、内核、驱动、无线硬件、功耗策略和隐私策略，能用一条路径串起 Apple full stack。

Apple 平台的公开资料主要覆盖 public framework、开发者授权模型、DriverKit、部分 Darwin / XNU 源码和行为文档。iOS 上大量 system daemon、硬件驱动、baseband、sensor fusion 和定位内部实现属于私有边界。因此，本章采用三层证据：公开 API 行为用于说明 App 可见入口，公开文档和 XNU 源码用于说明通用系统基础，平台行为推断用于连接 framework 后端、daemon 和硬件路径。凡涉及私有实现，本章只给责任边界和可观察信号。

Apple full stack 的核心结论是：App 从来不直接拥有硬件能力。App 拥有的是一组被签名身份、sandbox、entitlement、用户授权、系统服务状态和硬件策略共同过滤后的调用资格。一次定位请求成功，说明整条链路同时满足 API 使用条件、服务访问条件、隐私授权条件、后台策略条件和硬件可用条件；任意一层收缩，App 看到的都会变成授权失败、回调延迟、精度下降、后台停止或系统拒绝。

166.1 Apple Full Stack 的分层总图

Apple full stack 可以按“能力请求的控制权”划分。App 层表达意图，framework 层提供稳定 API，XPC / daemon 层拥有系统状态和策略执行权，XNU 提供进程、内存、IPC、文件、网络和驱动基础，IOKit / DriverKit 负责设备对象和驱动边界，硬件层提供传感器、无线、屏幕、相机、音频和安全芯片等真实能力。

以定位请求为例，App 调用 Core Location 并注册回调。App 代码只知道请求定位、授权状态和返回的坐标结果。它看不到 GNSS、Wi-Fi 扫描、蜂窝基站、motion sensor、sensor fusion 和 modem 之间的内部调度。framework 把高层请求转换成系统服务能理解的消息，系统服务负责检查调用方身份、用户授权、后台状态和精度请求，再决定是否启动硬件采样或复用缓存结果。

下面这张图只表达能力路径的责任层级。它不声明 Apple 私有 daemon 的完整内部函数，也不把某个具体系统版本的私有实现当成固定事实。

这条路径有两个方向。请求方向从 App 往下走，逐层把“我要当前位置”翻译成服务请求、权限判断、资源调度和硬件访问。返回方向从硬件和系统服务往上走，逐层把采样结果、错误、授权状态、降级原因或超时状态翻译成 framework 回调。读 Apple 架构时，应先问这次请求在哪一层被接受、在哪一层被判断、在哪一层被调度、在哪一层被拒绝。

这个模型同样适用于相机、麦克风、蓝牙、NFC、Keychain、Secure Enclave、推送和后台任务。相机请求可能从 AVFoundation 进入媒体服务，蓝牙请求从 Core Bluetooth 进入蓝牙服务，Keychain 请求从 Security framework 进入安全服务。入口 API 不同，责任链相同：App 没有绕过 framework 和系统服务直接访问硬件的正常路径。

公开资料的边界也应按这张图理解。XNU 公开源码能支撑 Mach、BSD、VM、I/O 基础和安全接口的通用理解；XPC 文档能支撑进程间服务通信模型；DriverKit 文档能支撑用户态驱动边界；具体 iOS 系统服务实现和硬件 firmware 细节通常只表现为公开 API 行为、日志信号、权限提示和错误码。

166.2 App Layer：Bundle、Process、Sandbox、Entitlement

App 层的第一件事是建立身份。Apple 平台用 bundle identity、签名证书、Team ID、provisioning profile 和 embedded entitlement 把一个安装包绑定为可执行主体。Bundle 是应用资源和可执行文件的打包边界，process 是代码运行边界，sandbox container 是文件和系统资源隔离边界，entitlement 是受控能力声明。

定位请求在 App 层至少经过三类声明。第一类是 Bundle ID 和签名身份，它告诉系统“谁在请求”。第二类是隐私用途说明，例如 Info.plist 中的位置用途字符串，它告诉系统“为什么向用户请求”。第三类是运行时请求动作，例如启动定位 manager、设置精度、申请前台或后台位置能力，它告诉 framework“现在要什么结果”。这些声明缺少任意一类，后续层都会得到不同输入。

Sandbox 的工作定义是：系统给 App 进程设置一组资源访问规则，使它只能访问自己的容器、被授权的共享区域和通过系统 API 获得的能力。iOS App 默认运行在严格沙箱中；macOS App 的 App Sandbox 也通过 entitlement 和容器约束文件、网络、硬件和系统服务访问。Sandbox 关注的是进程能否触碰资源边界，隐私授权关注的是用户是否允许访问某类敏感数据，二者在系统服务层经常一起参与判断。

Entitlement 的工作定义是：签名中携带的能力开关，用来声明 App 是否具备访问某类受控系统能力的资格。Apple 的 Entitlements 机制把开发者账号、profile、App ID、系统服务检查点连接起来。它和用户授权分工不同。某个能力需要 entitlement 时，用户点允许也无法替代签名中的资格；某个能力需要用户隐私授权时，拥有 entitlement 也无法跳过提示和授权状态。

在定位贯穿材料中，App 层能控制的是发起请求、声明用途、选择精度、处理回调和适配后台模式。App 层不能控制系统实际选择 GNSS、Wi-Fi、蜂窝或融合定位，也不能保证每次都有新鲜坐标。定位结果缺失时，先检查 App 层输入是否完整：Bundle ID 是否匹配，签名和 profile 是否有效，用途说明是否存在，授权请求是否发出，后台模式是否声明，进程是否处于允许接收回调的生命周期状态。

这一层的用户可见失败通常很直接。用途说明缺失可能导致系统拒绝启动隐私请求；用户拒绝位置权限后，App 得到拒绝状态；后台模式缺失时，前台可用的能力在进入后台后收缩；App 主线程阻塞时，定位回调即使已到达进程，也可能延迟表现到界面。App 层排查的关键证据是授权状态、错误回调、生命周期状态和自身配置，而非硬件寄存器或内核对象。

166.3 Framework Layer 作为系统能力公开入口

Framework 层把系统能力包装成开发者可使用的对象、方法、delegate、completion handler、async API 和错误码。UIKit 管理界面和生命周期，AVFoundation 管理媒体采集与播放，Core Location 管理定位，Core Bluetooth 管理蓝牙，Security 管理 Keychain 和加密对象。这些 framework 是 public API surface，也是 App 与私有系统实现之间的稳定边界。

Framework 的第一项职责是把 App 意图转换成系统请求。Core Location 把“请求当前位置”组织成 manager 配置、授权状态查询、精度要求、回调目标和错误处理。App 看到的是对象方法，系统服务收到的是带有调用方身份、请求参数和连接上下文的消息。这个转换让 Apple 可以在不暴露私有 daemon 接口的前提下维护 API 稳定性。

Framework 的第二项职责是把系统结果转换成 App 可处理的语义。硬件侧可能产生原始时间戳、信号质量、缓存结果、融合结果和失败原因；framework 往往把这些内容转成位置对象、授权状态、精度信息、错误码和 delegate 回调。App 由此获得稳定语义，但也失去底层调度细节。定位回调慢，App 应先判断 framework 层给出的授权状态、错误对象、精度标记和回调时序，再推断下层原因。

Framework 的第三项职责是维护平台策略的开发者边界。公开 API 会把私有实现细节压缩成少量可承诺行为，例如“请求授权”“开始更新”“停止更新”“错误回调”。这一点对阅读 Apple 架构很关键。读者看到一个 framework 方法时，应把它看成能力入口，而非直接系统调用。它通常会进入系统服务、检查策略、注册会话，并在后续异步返回。

下面的对照表给出同一类路径中的常见入口。表格中的后端服务名称只表达责任角色，具体进程名和内部接口以系统版本与公开可观察信号为边界。

App 行为	Public framework	典型后端责任	App 可见结果
请求位置	Core Location	位置服务、隐私授权、传感器和无线调度	授权状态、坐标、精度、错误
拍照或录像	AVFoundation	媒体服务、相机仲裁、ISP 和 buffer 管理	预览、照片、视频、采集错误
蓝牙扫描	Core Bluetooth	蓝牙服务、无线硬件、后台扫描策略	设备发现、连接状态、回调延迟
保存秘密	Security	Keychain 服务、访问组、数据保护	item 成功、认证失败、访问拒绝
认证用户	LocalAuthentication	生物认证服务、Secure Enclave 协同	成功、取消、锁定、策略失败

Framework 层的排查顺序也有稳定模式：先看 public API 使用是否满足文档约束，再看授权状态和错误码，再看生命周期和后台策略，再看系统服务是否可能因为资源、隐私、功耗或硬件状态降级。这个顺序能让读者在缺少私有源码的情况下仍然建立可验证判断。

166.4 XPC / Daemon 作为 Framework 后端服务通道

XPC / daemon 层是 Apple 平台能力路径的服务中枢。Framework 运行在 App 进程内，但它通常不持有全局硬件状态，也不适合直接管理多 App 资源竞争。系统 daemon 运行在更高权限或专门权限的上下文中，负责维护设备会话、服务状态、策略数据库、硬件访问队列和跨进程仲裁。

XPC 的工作定义是：Apple 平台用于进程间服务通信的机制之一，它把客户端请求、参数、reply、错误和连接生命周期组织成可管理的通信关系。底层往往依赖 Mach port 和消息传递。Framework 通过 XPC 或相邻的系统 IPC 机制把请求交给 daemon；daemon 通过连接上下文识别调用者，并把结果异步返回给 framework。

在定位贯穿材料中，framework 后端可能连接位置相关系统服务。这个服务需要知道调用者是谁、是否有前台界面、是否已经获得用户授权、是否声明后台位置、当前系统定位开关是否打开、低电量或低数据环境是否影响采样、是否已有可复用位置结果。App 进程只提交请求，服务进程才拥有跨 App 全局状态和硬件调度视角。

Daemon 识别调用者时，常见依据包括 code signing identity、entitlement、sandbox profile、audit token、进程 ID、bundle identifier 和当前会话状态。Audit token 可以把一条 IPC 消息绑定回发送进程的内核身份信息。服务使用这些信息做策略判断，能减少客户端伪造“我是某个 App”这类风险。具体字段组合由服务实现决定，公开层面需要掌握的是：身份判断发生在服务边界，App 自己传入的普通字符串不能成为可信身份来源。

这一层也是失败隔离层。App 崩溃时，daemon 仍然能保持系统状态；daemon 崩溃或重启时，App 看到的通常是连接失效、回调中断、错误返回或需要重新建立会话；硬件暂时不可用时，daemon 可以返回缓存、降级精度、排队等待或直接拒绝。Framework 把这些下层变化翻译成开发者 API 的错误与状态。

XPC / daemon 层排查要看四类证据。第一是连接是否建立，例如请求是否发出、reply 是否回来。第二是身份是否通过，例如 entitlement、sandbox、隐私授权和 bundle identity。第三是资源是否被仲裁，例如相机被占用、蓝牙扫描被后台策略收缩、定位被系统关闭。第四是服务是否健康，例如服务重启、连接 invalidation、状态丢失和超时。把这四类证据分开，能防止把所有问题混成“系统限制”。

166.5 XNU 作为进程、内存、IPC、文件、网络和驱动基础

XNU 是 Apple 平台的内核基础，公开 XNU README 将其描述为 Darwin 的内核，用于 macOS 和 iOS，并由 Mach、FreeBSD 组件和 IOKit 组成。对本章来说，XNU 的意义在于提供通用底座：进程和线程由内核调度，虚拟内存由内核管理，Mach port 和消息支撑大量 IPC，BSD 层提供进程、文件、socket 和网络语义，安全接口和 MAC policy 参与访问控制，I/O 子系统连接驱动对象和设备服务。

Mach 部分可用来理解 task、thread、port、message 和 VM。Task 可以看成进程资源容器，thread 是调度实体，port 是通信和能力引用，message 是跨边界传递数据的基本形式，VM 管理地址空间映射和内存权限。当 framework 通过 XPC 联系系统服务时，App 看到的是高级通信 API，内核侧需要支撑端口、消息、调度、内存复制或映射等基础动作。

BSD 部分可用来理解进程、文件、网络和 POSIX 接口。App 读写自己的容器文件、通过 socket 建立网络连接、打开系统允许的文件描述符、接收信号或错误码，都落在 BSD 语义之内。定位请求本身通常通过 framework 和 daemon 完成，但定位结果展示、缓存写入、网络辅助定位、日志记录和进程生命周期仍然依赖 BSD 层提供的文件、网络和进程基础。

VM 部分影响 App 可见性能和稳定性。定位请求可能引发 framework 对象创建、回调队列调度、地图数据加载和 UI 更新；内存压力上升时，系统可能压缩内存、回收缓存、终止后台进程或让 App 在恢复后重新建立服务会话。App 看到的是回调中断、状态丢失或重新授权路径；底层则是内核内存策略、进程优先级和系统生命周期策略共同作用。

XNU 的安全接口提供底层裁决能力，但 Apple 平台的访问控制分散在多个层级。Sandbox profile 可以约束系统调用和文件访问；daemon 可以根据 entitlement 和隐私授权拒绝服务；framework 可以在 public API 层提前返回错误；内核可以在进程、文件、socket、Mach port 或 I/O 边界执行更底层的权限判断。一次能力拒绝需要定位实际执行点，不能把所有拒绝都归到内核。

XNU 层排查的关键是识别问题是否已经低于服务语义。若 App 得到明确的定位授权拒绝，判断点在隐私和服务层；若进程被系统终止，判断点涉及内存、生命周期和 jetsam 类策略；若 IPC 连接断开，判断点涉及服务进程、Mach/XPC 连接和进程状态；若文件或网络访问失败，判断点可能落到 sandbox、BSD 权限或 network policy。XNU 提供基础能力，但用户可见错误经常由上层服务先塑形。

166.6 IOKit / DriverKit 作为设备驱动与硬件访问边界

IOKit / DriverKit 层把硬件设备包装成系统可管理的对象和服务。IOKit 是 XNU 体系中的驱动对象模型，负责设备匹配、驱动生命周期、I/O 请求和硬件服务抽象。DriverKit 则把一部分驱动移到用户空间，用更强的故障隔离和受控接口管理设备访问。对移动 OS 阅读来说，这一层回答“系统服务最终如何碰到设备能力”。

定位请求涉及的硬件能力可能包含 GNSS、Wi-Fi、蜂窝、蓝牙、motion sensor、气压计和低功耗协处理器。App 不会逐个打开这些设备。位置服务根据授权、精度、电量、环境信号和系统策略选择采样来源；驱动层把设备中断、buffer、firmware 命令、timestamp 和数据质量反馈给上层服务。App 得到的只是位置对象和精度描述。

驱动层的核心约束是 ownership 和 isolation。Ownership 表示谁能配置设备、谁能启动采样、谁能读取 buffer、谁能关闭设备。Isolation 表示驱动或硬件异常如何限制在局部范围内，减少对 App、system service 或内核其他部分的影响。用户态 DriverKit 能把部分驱动故障转化为服务失效或设备重建；内核态驱动故障则可能导致更严重的系统稳定性问题。具体设备采用哪种驱动形态取决于平台和设备类型。

这一层还承担功耗和时序约束。硬件采样会消耗电量，开启无线扫描会影响射频和隐私策略，持续高精度定位会增加热和电源压力。系统服务与驱动层协作时，需要在精度、延迟、功耗、后台公平性和用户可见体验之间取舍。App 请求“最高精度”只是输入参数，系统仍可根据设备状态和策略返回较低精度、延迟结果或错误。

IOKit / DriverKit 的可观测信号通常间接出现。App 可以看到设备不可用、权限状态、会话中断、精度变化和回调节奏；系统日志、诊断工具或平台文档可能暴露更细粒度线索。章节级阅读不要求读者打开驱动源码。更可靠的判断方式是把 App 结果和服务层策略联系起来：硬件可用性、功耗状态、后台状态、其他 App 竞争、系统设置和权限状态共同决定最终输出。

这层的边界结论是：Apple 把硬件设备纳入受控服务体系，驱动提供设备操作能力，daemon 管理跨 App 资源和策略，framework 提供开发者语义。App 访问到的是“系统批准后的能力”，而非硬件设备本身。

166.7 App 到硬件能力的 Apple 标准路径

App 到硬件能力的标准路径可以写成一个可复用判断顺序：先定位 public framework 入口，再定位 App 身份和声明，再定位系统服务边界，再定位权限与策略检查，再定位内核和驱动基础，最后解释用户可见结果。这个顺序适合在缺少私有源码时阅读 Apple 平台行为。

以定位请求为例，第一步看入口 API。Core Location 的对象、授权请求、精度配置和回调接口说明 App 想要什么。第二步看 App 身份和声明。Bundle ID、签名、用途说明、后台模式和生命周期决定请求是否具备进入服务层的基本条件。第三步看服务边界。framework 后端连接位置服务，服务使用系统状态和 caller identity 做判断。第四步看策略。TCC 隐私授权、系统定位开关、后台限制、低功耗状态、精度策略和硬件可用性都会影响结果。第五步看下层资源。XNU 提供进程、IPC、内存和网络基础，驱动和硬件提供采样来源。

这个顺序可以迁移到其他能力。相机路径中，入口换成 AVFoundation，服务换成媒体相关系统服务，策略换成相机权限、前后台状态、设备占用和热限制，硬件换成 sensor、ISP、buffer 和 display preview。蓝牙路径中，入口换成 Core Bluetooth，策略换成蓝牙权限、后台扫描条件、无线状态和功耗预算，硬件换成蓝牙控制器和射频资源。Keychain 路径中，入口换成 Security framework，策略换成 access group、data protection、认证状态和 Secure Enclave 协同，硬件路径更多体现为密钥保护和安全处理器边界。

用户可见失败也能按同一顺序归因。授权弹窗不出现，先看 App 是否调用了授权请求、用途说明是否满足系统要求、当前授权状态是否已固定。授权允许后仍无坐标，继续看服务是否可用、系统定位开关是否开启、精度是否被收缩、设备是否有足够环境信号。进入后台后回调停止，重点看生命周期、后台模式、系统功耗策略和服务对后台会话的保留条件。App 被系统终止，判断点转向内存压力、后台优先级和进程恢复。

这一路径还提供一个证据分级。公开 API 和错误码是最强的 App 侧证据；Apple 开发者文档和公开 XNU 源码支撑通用架构判断；系统日志和行为观察可支持服务层推断；对私有 daemon 函数名、硬件 firmware 流程和未公开策略的判断应保留不确定性。工程分析需要把“我看到了什么”和“我推断了什么”分开。

标准路径的最终输出是一张责任边界图，而非单一原因句。一次定位失败可能由用户拒绝、用途说明缺失、后台策略收缩、服务连接失效、硬件信号差、低功耗状态或 App 自身线程阻塞导致。稳定排查依赖层级化证据，不依赖猜测某个私有函数。

166.8 Apple 软硬件一体化对系统路径的影响

Apple 软硬件一体化让能力路径更加集中。硬件设计、系统 framework、系统 daemon、内核基础、驱动模型、App Store 分发、签名体系和隐私策略由同一平台控制。对开发者来说，这带来更稳定的 public API 和更一致的策略体验；对系统架构来说，这让能力开放程度、后台规则、隐私提示、硬件调度和性能预算可以被统一收束。

一体化首先影响硬件能力的封装方式。Apple 可以把 camera、ISP、Neural Engine、Secure Enclave、sensor hub、display engine 和 wireless subsystem 包装成 framework 层稳定能力。开发者调用 AVFoundation、Core ML、Security、Core Location 或 Metal 时，看到的是 Apple 设计好的能力表面。硬件内部寄存器、firmware 协议和驱动队列大多被封在系统边界内。

一体化其次影响策略一致性。权限提示、隐私指示器、后台执行、通知、定位精度、相机占用、蓝牙扫描和 Keychain 访问都可以由系统统一制定规则。App Store 审核、签名证书、entitlement 申请和运行时服务检查形成同一条能力准入链。一个 App 想访问后台定位，既要在工程配置里声明，也要通过签名和审核边界，还要在运行时获得用户授权，并持续受系统功耗和生命周期策略约束。

一体化还影响故障恢复。系统可以把 App 崩溃、服务重启、驱动重建、硬件不可用和用户撤权分别映射成不同用户可见行为。App 崩溃不应破坏全局定位服务；位置服务重启后，App 可能需要重建 manager 状态；用户撤销权限后，framework 应给出可处理的授权状态；硬件暂时不可用时，系统可以返回错误、缓存或延迟回调。分层恢复让用户体验更稳定，也让开发者必须按状态机写代码。

一体化的代价是内部路径透明度较低。Android 平台可以通过 AOSP、HAL、vendor log 和开放设备树看到更多可替换边界；Apple 平台公开的是 API 契约、部分 Darwin / XNU 基础、DriverKit 文档和开发者行为规则。读 Apple 架构时，可靠做法是围绕 public API、系统策略、可观察错误、公开源码边界和合理推断建立模型。

本章主问题到这里收束为一个判断：Apple full stack 的能力路径稳定性来自集中控制和层级封装。App 通过 framework 发起请求，系统服务持有状态和策略，XNU 提供基础资源，IOKit / DriverKit 管理设备边界，硬件能力由平台统一包装。理解这条路径后，读者就能把一个 App 可见现象放回对应责任层，而非把结果简单归因给“iOS 限制”或“硬件问题”。

最小自检任务

一个 iOS App 在前台调用 Core Location 请求当前位置。用户已经允许定位权限，但界面长时间没有显示新坐标。请按 Apple full stack 能力路径写出排查顺序，要求覆盖 App 层、framework 层、XPC / daemon 层、XNU 层、IOKit / DriverKit / hardware 层，并说明每层可能产生的用户可见结果。

答案要点

先看 App 层输入：Bundle ID、签名、用途说明、授权请求、定位 manager 生命周期、回调队列和 UI 主线程状态。若 App 未正确发起请求、manager 被释放、主线程阻塞或界面状态未更新，用户看到的是无坐标或界面延迟。

再看 framework 层语义：Core Location 当前授权状态、精度设置、错误回调、缓存结果和回调时序。若 framework 已经返回拒绝、受限、低精度或错误对象，应优先按公开 API 语义处理。

再看 XPC / daemon 层：位置服务需要识别调用者、检查 TCC 授权、系统定位开关、前后台状态和服务健康。若服务连接失效、授权状态变化、后台策略收缩或服务重启，App 可能看到回调中断、错误返回、精度下降或需要重新建立会话。

再看 XNU 层：进程调度、内存压力、IPC、文件和网络基础会影响服务连接、回调送达和 App 存活。若进程被系统终止、连接断开或网络辅助定位受限，用户看到的是状态丢失、无新结果或需要重新进入页面。

最后看 IOKit / DriverKit / hardware 层：GNSS、Wi-Fi、蜂窝、motion sensor 和低功耗协处理器共同影响定位质量。若硬件信号差、无线状态受限、功耗策略收缩或设备暂时不可用，用户看到的是长时间无结果、精度较低、位置延迟或错误回调。完整结论应把可见现象归到具体层级和证据，而非直接假定单一原因。

本章知识点总结

• 能力路径：Apple full stack 以 App、framework、XPC / daemon、XNU、IOKit / DriverKit、hardware 的顺序组织能力调用。
• App 身份：Bundle ID、签名、profile、sandbox 和 entitlement 共同决定 App 进入系统服务的基础资格。
• 权限分工：Entitlement 表示签名携带的能力资格，隐私授权表示用户对敏感数据访问的运行时许可。
• Framework 入口：UIKit、AVFoundation、Core Location、Core Bluetooth 和 Security 等 framework 把系统能力包装成稳定 public API。
• 服务中枢：System daemon 持有跨 App 状态、资源仲裁、策略数据库和硬件调度视角。
• XPC 通道：Framework 常通过 XPC 或相邻 IPC 机制把请求交给服务，并通过连接上下文传递调用方身份。
• XNU 基础：Mach、BSD、VM、security 和 I/O 子系统提供进程、内存、IPC、文件、网络和驱动基础。
• 驱动边界：IOKit / DriverKit 把设备包装成系统可管理对象，App 访问的是系统批准后的能力。
• 硬件封装：Apple 把传感器、无线、相机、安全芯片和显示能力收束到 framework 与服务边界后再开放给 App。
• 失败归因：定位、相机、蓝牙和 Keychain 失败都应按入口、身份、服务、策略、内核、驱动和硬件顺序定位。
• 证据边界：公开 API、Apple 文档、XNU 源码、系统行为和私有实现推断应分层使用。
• 一体化影响：Apple 软硬件统一控制提升路径稳定性，也降低内部实现透明度，使 public API 和可观察行为成为主要分析入口。