📚 课程目录第3章需求分析（下）

3. 需求分析（下）：编写需求规格说明书（SRS）、定义接口需求（HIDL/AIDL）、性能需求（延迟、功耗）、安全需求

在完成用户需求与系统用例的梳理后，需求分析进入工程化阶段。本阶段的核心产出是需求规格说明书（SRS），它将模糊的“想要什么”转化为精确的“要做什么”。同时，针对 Camera HAL 的嵌入式特性，必须明确定义接口契约（HIDL/AIDL）、性能指标（延迟/功耗）以及安全基线。

3.1 需求规格说明书（SRS）的编写

SRS 是项目团队与客户之间的“唯一真理”。一份优秀的 SRS 必须满足 正确性、无歧义、完整性、一致性、可验证性 五大原则。对于 Camera HAL 项目，SRS 通常包含以下核心章节：

章节	内容要点	Camera HAL 示例
1. 引言	项目背景、定义、缩写（如 ISP、HAL、AE/AWB）	定义“预览延迟”为从 Sensor 曝光到 SurfaceFlinger 显示的第一帧时间
2. 总体描述	产品视角、用户特征、约束条件	硬件平台为 Qualcomm SM8550，OS 版本 Android 14
3. 外部接口需求	用户、硬件、软件、通信接口	HAL 必须暴露 AIDL 接口供 CameraService 调用
4. 系统功能	用例驱动的功能分解	支持 3 路并发：预览 + 拍照 + 视频
5. 性能需求	延迟、吞吐量、功耗、资源占用	预览延迟 ≤ 100ms，功耗 ≤ 350mW
6. 安全需求	数据保护、访问控制、加密	Camera 数据流必须经过 TEE 加密通道
7. 质量属性	可靠性、可维护性、可移植性	HAL 升级需兼容前向 ABI

工程提示： 在 SRS 中，每个需求条目必须附带唯一的 需求 ID（如 REQ-CAM-PERF-001），以便在后续设计、测试和变更追踪中精确追溯。

3.2 定义接口需求：HIDL 与 AIDL 的选择

在 Android Camera 架构中，HAL 与 Framework 的通信接口经历了从 HIDL 到 AIDL 的演进。选择哪种接口语言，直接影响系统的稳定性、性能与可维护性。

3.2.1 HIDL vs AIDL 对比

特性	HIDL (HAL Interface Definition Language)	AIDL (Android Interface Definition Language)
设计目标	HAL 与 Framework 进程间解耦	通用 Binder 通信，统一 Android 生态
稳定性	强（通过 @VintfStability 保证 ABI）	强（通过 @VintfStability 或 @JavaOnlyStableParcelable）
性能	中等（需经过 hwservicemanager）	高（直接 Binder 调用，减少中间层）
代码生成	生成 C++ 客户端/服务端骨架	生成 Java/Kotlin 或 NDK C++ 代码
推荐场景	传统 HAL 实现（Android 8-12）	新项目或迁移项目（Android 13+）

3.2.2 AIDL 接口定义示例

以下是一个简化的 Camera HAL AIDL 接口片段，定义了核心的 configureStreams 方法：

// ICameraDevice.aidl
package vendor.camera.hardware;

import vendor.camera.hardware.StreamConfiguration;
import vendor.camera.hardware.CameraMetadata;

interface ICameraDevice {
    /**
     * 配置 Camera 数据流管道。
     * @param config 包含流类型、分辨率、格式等参数。
     * @return 操作状态码（0 表示成功）。
     */
    int configureStreams(in StreamConfiguration config);

    /**
     * 请求捕获单帧图像。
     * @param settings 3A 参数与效果设置。
     * @return 捕获帧的唯一标识符。
     */
    long capture(in CameraMetadata settings);

    /**
     * 关闭设备并释放资源。
     */
    void close();
}

避坑指南： 定义接口时，务必明确 in / out / inout 方向标记。对于 Camera 这类大数据量场景，优先使用 in 传递描述符，避免在 Binder 事务中直接传递大块数据（如 YUV 帧），应通过 SharedMemory 或 NativeHandle 传递。

3.3 性能需求：延迟与功耗

Camera HAL 的性能需求是嵌入式系统中最苛刻的维度之一。延迟和功耗直接影响用户体验和产品续航。

3.3.1 延迟需求分解

延迟指标必须分解到每个子模块，才能指导设计和测试。以下是一个典型的 Camera 流水线延迟预算：

3.3.2 功耗需求分解

功耗需求通常以 mW 为单位，按 Camera 工作模式分别定义：

工作模式	典型功耗预算	关键优化点
预览（30fps）	≤ 350 mW	降低 ISP 时钟、使用低功耗 Sensor 模式
拍照（单帧）	≤ 500 mW（峰值）	限制 CPU/GPU 参与，硬件直通
视频录制（1080p@30）	≤ 450 mW	开启硬件编码器，关闭预览叠加层
待机（Standby）	≤ 5 mW	关闭 MCLK，Sensor 进入软件 standby

  关键指标： 在 SRS 中，性能需求必须附带 测量条件。例如：“在 25°C 室温、屏幕亮度 200nit、Wi-Fi 关闭、仅 Camera 应用运行的条件下，预览延迟 ≤ 100ms，功耗 ≤ 350mW。”

3.4 安全需求

Camera 是隐私敏感设备，安全需求必须贯穿 HAL 设计始终。主要关注以下三个维度：

3.4.1 数据流安全

加密传输： 从 Sensor 到 HAL 的原始数据（RAW/Bayer）必须通过硬件加密通道（如 Qualcomm SPU）传输。
内存隔离： 使用 dma-buf 的 DMA_BUF_IOCTL_SYNC 确保非 Camera 进程无法直接访问帧缓冲区。
安全回放： 视频录制时，关键帧（I-frame）必须添加数字水印，防止篡改。

3.4.2 访问控制

权限模型： 严格遵循 Android CAMERA 权限组，HAL 层不绕过 Framework 直接打开 Sensor。
多用户隔离： 在支持多用户的设备上，不同用户的数据流必须使用不同的 CameraDevice 实例，禁止共享。
物理安全： 对于可旋转/可拆卸 Camera，HAL 必须检测物理连接状态，在断开时立即停止数据流。

3.4.3 安全需求检查表

需求 ID	描述	验证方法
REQ-SEC-001	所有 Camera 数据流必须经过 TEE 加密	抓取总线数据，验证加密头
REQ-SEC-002	HAL 必须拒绝未授权进程的 open() 调用	使用 adb shell 模拟未授权调用
REQ-SEC-003	预览帧缓冲区必须在 100ms 内清零	内存 dump 检测残留数据
REQ-SEC-004	固件升级必须签名验证	注入未签名固件，验证拒绝

3.5 需求可追溯性矩阵（RTM）

为了确保每个需求都被实现和测试，必须建立 需求可追溯性矩阵。RTM 将 SRS 中的需求 ID 映射到设计文档、代码模块和测试用例。

3.6 本章小结

SRS 是项目基线，必须包含功能、接口、性能、安全四大维度，每个需求有唯一 ID。
接口需求 优先选择 AIDL（Android 13+），利用 Binder 的高性能和统一生态。
性能需求 必须分解到子模块（延迟预算）和不同工作模式（功耗预算），并附带测量条件。
安全需求 覆盖数据加密、访问控制和物理安全，通过 RTM 确保可追溯。
下一阶段将基于 SRS 进行 架构设计，将需求转化为具体的模块划分和组件交互。