Chapter 9: Mobile SoC Component Map
手机系统架构从这一章进入硬件平台。前几章已经把移动 OS 看成 App、Framework、System Service、Kernel、Driver 和 Hardware 之间的责任链；本章把最底层的 Hardware 展开成 SoC 组件图。读完本章后，读者应能把一次 App 可见行为追踪到 CPU、GPU、NPU、ISP、modem、memory controller、security engine、I/O controller 等硬件角色，并判断系统服务为什么会把某些硬件能力包装成权限、会话、队列、缓冲区、功耗预算和失败结果。
本章的贯穿材料是一条相机路径：用户打开相机 App，看到实时取景，按下快门，系统做夜景增强，把照片写入加密存储，随后通过蜂窝网络或 Wi-Fi 上传到云端。这条路径会经过图像传感器、ISP、DRAM、CPU、GPU、NPU、storage controller、security engine、display pipeline、modem 和系统服务层。它足够具体，可以让硬件组件图从静态名词变成可追踪的数据流和控制流。
SoC 组件图的核心结论是：手机硬件能力先在芯片内部被拆成专用执行单元和共享资源，再由 firmware、driver、HAL 或 daemon、system service 和 framework API 逐层包装。App 调用相机 API 时看到的是权限、session、surface、callback 和错误码；系统内部处理的是传感器时序、ISP pipeline、buffer ownership、DMA、内存带宽、温控状态、文件加密和网络射频状态。
本章只建立组件地图和读法。后续章节会继续展开 CPU 调度、GPU 显示、NPU、ISP、modem、存储、电源和温控。本章要先让读者形成一个稳定判断顺序：先定位 App 行为使用了哪些硬件能力，再定位这些能力经过哪些系统边界，最后根据延迟、功耗、权限、带宽和热状态判断瓶颈位置。
9.1 SoC 作为手机硬件平台核心
SoC（System on Chip，片上系统）是手机硬件平台的核心，因为它把主要计算单元、媒体处理单元、安全单元、内存访问入口和外设控制入口集中在同一颗芯片或同一套芯片封装关系中。对移动 OS 来说，SoC 提供的能力包括通用执行、图形渲染、机器学习推理、图像处理、无线通信、加密、显示输出、传感器接入和存储访问。系统服务在上层做权限、生命周期和资源仲裁，底层能够执行这些策略，依赖 SoC 内部存在可调度、可隔离、可限速、可计量的硬件资源。
在相机贯穿路径中，App 按下快门后，图像传感器先输出原始像素数据，ISP 做去马赛克、降噪、白平衡、HDR 合成等图像信号处理，NPU 或 GPU 可能参与人像分割、夜景增强和场景识别，CPU 负责调度请求、执行控制逻辑和处理部分应用层算法，DRAM 承载中间 buffer，storage controller 负责写入闪存，security engine 参与文件加密，modem 或 Wi-Fi 模块负责上传。单独看其中任何一个组件都无法解释“拍照慢、预览卡、发热、上传耗电”这类用户可见结果；组件之间的连接关系才是移动 OS 读法的起点。
下面的图描述本章使用的 SoC 能力地图。它只表达责任关系和数据通路，真实芯片版图需以具体 SoC 文档为准。
这张图的读法是先看谁产生数据，再看谁拥有控制权。图像传感器产生原始图像数据，但 App 没有直接控制传感器时序；Framework API 接收 App 请求，System Service 持有设备状态和权限判断，HAL 或 daemon 把平台公开能力转成供应商或系统内部接口，driver 再控制 I/O controller、ISP、DMA 和中断。CPU 在这条路径中承担协调角色，DRAM 和 memory controller 承担中间结果交换角色，专用单元承担高吞吐或低功耗任务。
SoC 作为核心硬件平台，还意味着多个能力共享同一组全系统约束。相机预览、屏幕刷新、后台上传和机器学习增强会同时竞争内存带宽、功耗预算和热容量。移动 OS 的很多策略看起来发生在 Framework 或 System Service 层，例如后台限制、相机占用、帧率降低、上传推迟；它们最终都要落到 SoC 资源是否可用、是否过热、是否有足够带宽和是否允许当前调用者访问对应硬件能力。
9.2 CPU、GPU、NPU、ISP、Modem 的职责划分
理解 SoC 组件图时，第一步是区分各计算单元解决的问题类型。CPU 适合执行分支多、控制复杂、任务形态变化大的通用代码；GPU 适合大量并行的图形和向量计算；NPU 适合固定算子图或模型推理；ISP 适合相机原始信号到可显示图像的固定图像 pipeline；modem 适合蜂窝基带协议、射频状态管理和网络注册。职责划分越清楚，越容易判断一次性能问题属于通用调度、图形负载、AI 推理、图像 pipeline、无线通信还是共享资源争用。
| 组件 | 主要输入 | 主要工作 | 输出给系统的结果 | 相机路径中的表现 |
|---|---|---|---|---|
| CPU | 线程、系统调用、服务请求、中断处理 | 调度控制逻辑、执行应用代码、驱动管理、协议栈上层处理 | 任务完成、状态更新、错误返回、回调触发 | 创建相机会话、处理回调、调度拍照请求、执行部分后处理 |
| GPU | 图形命令、纹理、shader、合成任务 | 渲染 UI、处理图像纹理、执行部分通用并行计算、参与系统合成 | frame、layer、drawable、display buffer | 绘制取景界面、处理预览纹理、参与滤镜和最终显示 |
| NPU | 模型、tensor、量化权重、输入 buffer | 执行神经网络推理和部分 AI 加速任务 | 推理结果、mask、embedding、增强参数 | 人像分割、夜景增强、场景识别、实时美颜 |
| ISP | sensor raw、曝光参数、镜头参数、3A 状态 | 去马赛克、降噪、自动曝光、自动白平衡、自动对焦、HDR 合成 | YUV/RGB frame、metadata、统计结果 | 生成预览帧、输出拍照帧、提供曝光和对焦状态 |
| Modem | 射频信号、SIM/eSIM 状态、网络协议数据 | 蜂窝注册、数据收发、信令处理、功率控制 | 网络连接状态、吞吐、延迟、掉线原因 | 照片上传、弱网重试、蜂窝功耗上升 |
CPU 的角色容易被误读为“所有计算都由 CPU 完成”。在手机 SoC 中，CPU 更像请求协调者和异常处理者。相机 App 触发拍照时，CPU 上的应用线程、系统服务线程和驱动相关线程会建立 session、提交 request、等待 fence、接收回调、更新 UI 状态。实际像素吞吐由 ISP、GPU、NPU 和 DMA 承担。CPU 占用过高会造成回调延迟和 UI 卡顿，但像素处理慢通常还要检查 ISP pipeline、NPU 推理耗时、内存带宽和热限速。
GPU 的核心职责是把 buffer 变成用户可见画面。预览帧从 ISP 或 camera HAL 进入图形系统后，GPU 可能把纹理绘制到取景界面，也可能参与滤镜、颜色变换、缩放和系统合成。GPU 与 display engine、surface、layer、fence 等对象相连，所以“相机预览卡顿”既可能来自图像帧生成慢，也可能来自 GPU 合成排队、display pipeline 等待、App 主线程提交不及时或内存带宽不足。
NPU 的职责是把模型推理放到更适合的专用硬件上。Apple 的公开 Core ML 页面说明 Core ML 会利用 CPU、GPU 和 Neural Engine 来优化设备端性能、内存占用和功耗；Android 侧也存在 NNAPI、厂商加速器和应用框架之间的抽象关系。对系统读法而言，关键点是 NPU 任务通常通过 framework、runtime 或 vendor driver 被调度，App 看到的是推理 API、模型兼容性和性能报告，底层则是 tensor buffer、算子支持、内存布局和功耗状态。
ISP 是相机路径中最容易被低估的专用单元。相机传感器输出的 raw 数据需要经过镜头校正、去马赛克、降噪、HDR、曝光和白平衡等处理，才能成为预览、拍照和录像可使用的 frame。ISP 的存在让高帧率预览和高质量拍照在移动功耗预算内成立。系统服务对相机能力的封装，例如支持哪些分辨率、哪些帧率、哪些 HDR 模式、是否支持并发相机，最终都要落到 sensor、ISP、memory bandwidth 和 HAL 能力描述。
Modem 的职责属于通信硬件和协议栈边界。相机拍照本身可以离线完成，但照片上传会把 modem、Wi-Fi、射频功率、网络策略和后台传输策略纳入同一条路径。弱信号、频繁重传、蜂窝切换和后台限制会改变上传延迟，也会增加功耗和热压力。移动 OS 在这类路径中会把网络状态、用户设置、后台策略和电源状态共同用于调度。
9.3 Memory、Storage、Sensor 与主计算单元的连接关系
SoC 内部组件之间的真实瓶颈常常出现在数据移动上。CPU、GPU、NPU、ISP、modem 和 security engine 都需要访问内存或特定 buffer；sensor 和 storage 通过 I/O controller、DMA 和驱动队列进入系统；memory controller、cache、interconnect 和 IOMMU 决定数据能否按时到达目标单元。读移动 OS 时，看到“硬件加速”这个词以后，还要继续追问：输入 buffer 在哪里，谁负责写入，谁负责读取，是否需要复制，是否跨越安全边界，完成信号由哪个 fence、interrupt 或 callback 表达。
相机预览是一条典型数据通路。Image sensor 通过相机接口把 raw frame 送到 ISP，ISP 把处理后的 frame 写入 DRAM 中的 buffer，camera HAL 或系统内部 camera daemon 管理 buffer 队列，图形系统把其中一部分 buffer 作为预览纹理交给 GPU 和 display pipeline。CPU 主要更新描述符、提交 request、处理 metadata 和回调。高吞吐路径通过 DMA 传输数据，可以减少 CPU 参与大块内存搬运的开销，但 DMA 同样受 IOMMU、缓存一致性、内存带宽和 buffer 生命周期约束。
Storage 与相机路径的关系发生在拍照完成之后。最终照片通常需要编码、写入文件系统，并进入平台的数据保护或文件加密路径。Apple 公开的 Platform Security 文档说明 Secure Enclave 集成在 SoC 中，隔离于主处理器，并与 AES Engine 等硬件共同支撑数据保护；Android 设备也会通过内核、加密模块、key management、TEE 或安全硬件构造设备密钥和文件加密路径。对上层 App 来说，保存照片只是写入媒体库；对系统来说，它涉及文件权限、媒体索引、storage controller、flash wear、加密 key、DMA path 和后台同步。
Sensor hub 是另一类连接关系。手机里的加速度计、陀螺仪、磁力计、接近传感器和环境光传感器经常需要低功耗常驻工作。把这些采样任务全部交给主 CPU 会增加唤醒次数和功耗，因此 SoC 或平台常提供低功耗 sensor hub、always-on processor 或类似控制单元。相机路径里，陀螺仪数据可以用于防抖，环境光可以影响曝光策略，设备姿态可以影响 UI 旋转和照片 metadata。系统向 App 暴露的是传感器事件或相机 metadata，底层则是低功耗采样、batching、interrupt 和唤醒策略。
内存连接关系还决定了多硬件协同的成本。夜景模式可能需要多帧 raw 或 YUV buffer，ISP 输出后由 NPU 做语义增强，GPU 做预览或后处理显示，CPU 管理合成参数和用户交互。如果每个阶段都复制整张高分辨率图片，内存带宽和功耗会迅速上升。稳定的系统设计会把 buffer ownership、zero-copy、shared memory、fence 和生命周期管理放在核心位置，让多个硬件单元围绕同一批受控 buffer 协作。
一个可复用判断顺序是：先确认数据生产者，例如 sensor、network、storage 或 App；再确认主要处理者，例如 ISP、NPU、GPU、CPU 或 modem；接着确认数据是否进入共享 DRAM；然后确认是否存在 DMA、IOMMU、cache flush、fence 和 callback；最后把延迟归因到计算单元、内存带宽、队列等待、权限拒绝、热限制或后台策略。这个顺序比单纯记忆硬件名称更接近移动 OS 的实际排查方式。
9.4 硬件能力与系统能力的映射入口
硬件能力进入移动 OS 后，会被重新包装成系统能力。图像传感器、ISP、NPU、modem 和 security engine 本身只是硬件资源；App 能使用的是相机 API、机器学习 API、网络 API、文件 API、权限弹窗、后台任务接口和错误回调。中间的映射入口通常包括 firmware、kernel driver、HAL 或 daemon、system service 和 framework。Android 公开的 Architecture overview 把 system service、HAL、ART 和 kernel 等放在同一架构说明中，HAL overview 说明 HAL 通过标准接口隔离硬件供应商实现和更高层系统。Apple 公开材料则更多从 framework、security 和开发者 API 描述硬件能力，很多 daemon、driver 和 ISP 细节属于平台内部实现边界。
相机路径可以拆成一条映射链：App 请求相机权限并创建 capture session；Framework API 把请求转成平台内部对象；System Service 或 daemon 检查调用者身份、前后台状态、隐私指示器、设备占用和策略；HAL 或内部 driver-facing 接口把抽象 request 转成 sensor、ISP 和 buffer 配置；Kernel driver 处理设备节点、中断、DMA、IOMMU 和电源状态；硬件执行后把 frame、metadata、error 和 fence 返回。App 最终看到的是预览帧、拍照结果、权限失败、设备占用、超时或质量降级。
Android 的映射入口更适合用公开分层来阅读。Camera2 或 CameraX 这类 App 入口向下连接 framework，framework 通过 CameraService 等系统服务持有设备状态和权限判断，camera provider HAL 表达厂商相机实现，kernel driver 与 sensor、ISP、IOMMU 和 power domain 交互。公开 AOSP 文档中还存在 AIDL HAL、HIDL 历史接口、VINTF、GKI 和 vendor boundary 等材料，用来说明 Android 如何在多 SoC、多 OEM、多供应商组合中维持系统更新和硬件适配。
Apple 平台的映射入口应按公开边界表达。App 使用 AVFoundation、Core ML、Metal、Network、Photos、Security 等公开 framework；系统内部通过 daemon、entitlement、sandbox、driver framework、XNU 和硬件协同完成资源调度。Apple 的 Secure Enclave 公开文档明确说明 Secure Enclave 是集成在 Apple SoC 中的独立安全子系统，并说明它与 Boot ROM、AES Engine、受保护内存和 Secure Neural Engine 等组件的关系；相机 ISP、具体 daemon 和私有 driver 的完整路径则需要以公开 API 行为、公开安全文档和可观察平台行为为边界来推断。
硬件能力映射成系统能力后，会增加三个系统属性。第一是身份属性：系统要知道调用者是谁，是否有权限、entitlement、前台状态和用户授权。第二是调度属性：系统要把硬件访问变成 session、stream、queue、buffer 和 deadline。第三是策略属性：系统要根据电量、温度、隐私、网络、后台状态和设备占用决定是否执行、排队、降级或返回错误。硬件规格只说明“能做什么”，系统能力还要说明“谁在什么状态下可以用、使用多久、失败如何表达”。
这也是阅读移动 OS 时最关键的跨层转换。硬件工程师描述 ISP 时会说吞吐、bit depth、HDR、pipeline 和 sensor interface；App 开发者描述相机时会说权限、preview、capture、callback 和 error；系统架构读法要把这两组语言连接起来。一次相机能力失败，可能发生在权限记录、服务仲裁、HAL capability、driver power-up、sensor init、ISP buffer、NPU 任务、storage 加密写入或 modem 上传路径上。
9.5 SoC 集成度对功耗、延迟和系统架构的影响
SoC 高集成度直接改变移动 OS 的策略形态。把 CPU、GPU、NPU、ISP、memory controller、security engine 和 I/O controller 放到紧密协同的芯片平台上，可以缩短数据路径、降低接口开销、提高专用任务能效，并让系统在更细粒度上控制电源域和时钟。代价是多个单元共享内存、封装热容量、电池瞬时电流和系统调度预算。移动 OS 因此需要同时管理性能、功耗、温度、隐私和用户可见体验。
延迟收益首先来自数据路径缩短。相机预览需要稳定地把 frame 从 sensor 送到 ISP，再送到 display pipeline。SoC 内部互连、DMA 和共享 buffer 可以让这条路径减少 CPU 参与大块数据搬运的次数。GPU 取纹理、display engine 扫描输出、NPU 读取 tensor、ISP 写入 frame，都可以围绕共享 DRAM 和受控 buffer 完成协作。系统在上层表现为低预览延迟、少拷贝图形路径和更稳定的 frame deadline。
功耗收益来自专用单元和低功耗岛。ISP 用固定 pipeline 处理高分辨率图像，通常比 CPU 用通用指令处理整帧图像更适合移动功耗预算。NPU 在支持的模型和算子范围内执行推理，可以降低 CPU 或 GPU 的持续负载。Sensor hub 在主 CPU 休眠时继续采样步数、姿态和环境信息，可以减少系统唤醒次数。Security engine 在存储 DMA 路径中执行加解密，可以把数据保护从纯软件开销转成硬件路径。
集成也会放大共享资源瓶颈。夜景拍摄可能同时占用 ISP、NPU、CPU、GPU、DRAM 和 storage；后台上传同时拉起 modem 或 Wi-Fi；屏幕高亮和高刷新率继续增加 display power；这些负载都在同一个设备热容量和电池电流限制下运行。当温度上升后，系统可能降低 CPU/GPU 频率、收缩相机帧率、降低屏幕亮度、延迟后台上传或切换到低功耗图像处理路径。用户看到的是拍照保存慢、预览帧率下降、上传变慢或设备发热。
系统架构也会因为高集成度而更强调“能力代理”。App 无法直接选择 ISP pipeline、NPU core、modem power state 或 AES engine；它只能请求相机模式、模型推理、网络上传或文件保存。System Service 和 daemon 需要把这些请求统一放入当前设备状态中决策。相机服务要知道是否已有其他 App 占用相机，电源服务要知道当前热状态，网络服务要知道后台传输策略，媒体服务要知道 buffer 和 codec 状态，安全服务要知道 key 是否可用。高集成度让硬件协同更强，也让系统服务的仲裁责任更重。
判断 SoC 集成度影响时，可以使用三个问题。第一，数据是否在芯片内部以共享 buffer 方式流动，这决定延迟和带宽压力。第二，任务是否被分配到专用单元，这决定能效和兼容性边界。第三，当前负载是否触发功耗或热策略，这决定系统会给 App 正常结果、降级结果还是错误结果。相机路径中的“预览顺畅但拍照保存慢”通常指向 ISP 到 NPU、编码、storage 或加密写入阶段；“预览和 UI 同时卡”更可能涉及 CPU/GPU 调度、内存带宽或热限速；“上传后发热明显”则要把 modem、网络重试、屏幕和后台策略一起纳入判断。
9.6 Android / Apple 平台对 SoC 能力的不同封装方式
Android 和 Apple 平台面对的是同一个系统问题：把 SoC 的硬件能力封装成 App 可使用、系统可仲裁、用户可理解、平台可更新的能力。差异主要来自生态结构。Android 要支持多 SoC vendor、多 OEM、多相机模组、多 modem 组合和不同系统镜像更新节奏，因此公开架构更强调 HAL、vendor boundary、VINTF、GKI、AIDL/HIDL 演进和兼容性测试。Apple 控制硬件、SoC、系统软件、framework 和分发规则的范围更集中，因此公开 API 更强调统一 framework、entitlement、sandbox、隐私提示、设备端能力和 Apple Silicon 协同。
| 维度 | Android 封装方式 | Apple 封装方式 | 读源码或文档时的判断点 |
|---|---|---|---|
| App 入口 | Android framework API、Jetpack wrapper、permission API | AVFoundation、Core ML、Metal、Photos、Network、Security 等 framework | 先定位公开 API 和用户授权状态 |
| 系统服务 | system_server 内服务、native service、SurfaceFlinger、media/camera/audio 相关服务 | system daemon、XPC service、framework 内部服务、WindowServer/Core Animation 等公开可观察边界 | 观察谁持有设备状态和资源仲裁权 |
| 硬件抽象 | HAL、AIDL/HIDL、vendor service、VINTF、vendor partition | 私有 driver / daemon 边界、DriverKit/IOKit 公开材料、Apple Silicon 协同 | 区分公开事实和平台内部实现推断 |
| 内核与驱动 | Linux kernel、GKI、vendor modules、device tree / boot config | XNU、DriverKit/IOKit 公开组件、Apple 私有驱动 | 看硬件描述、驱动边界和更新责任 |
| 安全能力 | permission、SELinux、TEE/StrongBox/KeyMint 等设备实现 | entitlement、sandbox、Secure Enclave、Data Protection | 看身份、密钥、隔离和用户可见授权 |
| 失败表现 | permission denied、HAL error、service crash、vendor bug、thermal 降级 | authorization failure、entitlement 限制、daemon 错误、thermal state、私有能力收缩 | 把错误放回能力链中的责任主体 |
Android 的多厂商结构让 HAL 成为 SoC 能力进入系统的主要边界。以相机为例，Android framework 需要给 App 一个相对稳定的 API，但不同设备的 sensor、ISP、多摄组合、调参算法和 NPU 能力差异很大。HAL 将这些差异收敛成标准接口和 capability 描述，System Service 再基于这些描述建立 session、stream 和 request。这样做的工程收益是系统上层可以在不同硬件上保持相同 API 形态；工程成本是 vendor 实现、HAL 版本、内核模块、firmware 和系统更新之间要维持兼容关系。
Apple 的垂直整合让 SoC 能力更多通过统一 framework 和系统策略呈现。App 使用 AVFoundation 拍照、使用 Core ML 运行模型、使用 Metal 做图形和计算、使用 Security 和 Data Protection 相关 API 处理密钥与数据保护。底层是否由 ISP、Neural Engine、GPU、Secure Enclave 或其他专用单元执行，通常由系统根据设备型号、系统版本、模型支持、权限、功耗和热状态决定。公开文档能确认一些硬件安全与开发框架关系，例如 Secure Enclave 与 Core ML 对 Apple silicon 的利用；完整私有路径需要保持边界意识。
两类平台的比较应落到同一组责任链上。App 意图都是请求某项能力；Framework 都把能力塑造成 API；系统服务或 daemon 都要检查身份、权限、生命周期和资源占用；硬件抽象或私有内部接口都要把请求转成 driver 和 firmware 可执行的配置；内核、驱动和硬件都要处理 buffer、interrupt、DMA、电源域和错误；用户最终看到预览、照片、提示、延迟、发热、耗电或失败。品牌差异只是外层组织方式，系统问题仍然是能力路径与资源仲裁。
阅读 Android 资料时，可以沿着公开接口向下找：App API、framework manager、system service、HAL、vendor service、kernel driver、device tree、firmware。阅读 Apple 资料时，可以沿着公开 API 和公开安全材料向下推：framework、authorization/entitlement、daemon 或系统服务边界、XNU/DriverKit/IOKit 公开组件、Apple Silicon 安全或机器学习文档、可观察平台行为。两种读法都要在每一步标注证据类型：公开 API、公开系统文档、开源组件、设备行为、合理推断或私有实现边界。
本章最终建立的 SoC 读法是：硬件组件图用来定位能力来源，系统分层用来定位控制权，App 可见行为用来验证路径是否闭合。相机拍摄、AI 增强、加密保存和网络上传的体验差异，既来自 SoC 内部组件职责，也来自移动 OS 对硬件能力的封装、仲裁和降级策略。
最小自检任务
题目：一个相机 App 在同一台手机上出现三种现象：实时取景基本顺畅，按下快门到照片保存完成的时间偏长；开启夜景后设备温度上升更快；使用蜂窝网络自动上传照片时，后台上传经常推迟。请按照本章的 SoC 组件图写出这三种现象分别可能经过哪些硬件单元、系统边界和策略检查点，并给出初步归因顺序。
答案要点
实时取景顺畅说明 sensor、ISP、camera buffer、GPU/display pipeline 至少能稳定完成预览路径。按下快门到保存偏长，应继续检查多帧拍摄、ISP 输出、NPU 或 GPU 后处理、编码、DRAM 带宽、storage controller、文件系统写入和加密路径。这里的关键边界是 Framework capture request、camera service 或 daemon、HAL / driver、ISP、NPU、storage 与 security engine。
夜景导致温度上升更快，说明负载从单帧预览扩展到多帧合成、降噪、AI 增强和更长时间的 ISP / NPU / GPU / CPU 协同。初步归因顺序应先看是否存在长时间高分辨率多帧处理，再看 NPU 或 GPU 后处理耗时，再看内存带宽和热策略是否触发降频、帧率降低或保存延迟。
后台蜂窝上传推迟，主要进入 modem、网络服务、后台任务策略、电源策略和热策略。照片已经保存完成后，瓶颈从相机硬件转向网络连接、蜂窝信号、数据策略、后台执行预算、充电和温控状态。用户可见结果可能是上传排队、仅 Wi-Fi 上传、弱网重试、通知延迟或系统在前台重新打开 App 后继续同步。
完整答案应把三种现象放在同一条责任链中：App 意图发起请求，Framework 建立 API 对象，系统服务检查权限和状态，HAL / daemon 连接硬件实现，kernel driver 与 SoC 单元处理 buffer 和中断，电源与温控服务决定是否降级，最终结果通过回调、错误码、UI 状态或后台任务状态返回。
本章知识点总结
- SoC 核心：SoC 把手机主要计算、媒体、安全、通信、内存和 I/O 能力组织成系统可调度的硬件平台。
- 能力地图：CPU、GPU、NPU、ISP、modem、memory controller、security engine 和 I/O controller 应放在同一张能力图中理解。
- CPU 角色：CPU 主要承担控制逻辑、线程调度、服务请求、驱动管理和异常处理。
- GPU 角色：GPU 负责图形渲染、纹理处理、部分并行计算和系统合成相关工作。
- NPU 角色：NPU 面向模型推理和 AI 加速，受模型算子、buffer 格式、内存布局和功耗状态约束。
- ISP 角色：ISP 把 sensor raw 数据处理成预览、拍照和录像可使用的 frame 与 metadata。
- Modem 角色：modem 负责蜂窝通信、射频状态、协议处理和数据收发，并直接影响上传延迟和功耗。
- 数据通路：移动硬件瓶颈常出现在 buffer ownership、DMA、IOMMU、cache、fence 和内存带宽上。
- 系统映射：硬件能力要经过 firmware、driver、HAL 或 daemon、system service 和 framework API 才成为 App 可用能力。
- 策略属性：系统能力同时包含调用者身份、资源调度、功耗温控、隐私授权和失败返回。
- 集成收益：SoC 集成可以降低数据移动开销、提升专用任务能效，并支持低功耗常驻能力。
- 共享瓶颈：高集成度也会让相机、显示、AI、网络和存储共同竞争带宽、热容量和电池电流预算。
- Android 封装：Android 通过 HAL、vendor boundary、VINTF、GKI 和系统服务组织多厂商 SoC 能力。
- Apple 封装：Apple 通过统一 framework、entitlement、daemon、XNU、Secure Enclave 和 Apple Silicon 协同呈现 SoC 能力。
- 读法顺序：先定位 App 行为使用的硬件能力，再定位系统边界，最后根据延迟、功耗、权限、带宽和热状态判断责任主体。