Phase 1: 硬件探针与能力分级 -- 设计意图

为什么选择这种方案

CFDesktop 的目标设备跨度极大——从 528MHz 单核 Cortex-A7 (IMX6ULL) 到 8 核 Cortex-A76 (RK3588)，性能差距超过 20 倍。如果用一套渲染和动画策略覆盖所有设备，要么在低端设备上卡顿，要么在高端设备上浪费算力。因此我们在系统启动时执行一次硬件探针，输出三级档位（Low/Mid/High），后续所有模块（主题引擎、动画管理器、渲染后端）根据档位自动裁剪行为。

选择三级而非更细的分级（如五级或连续分数），是因为三级足以覆盖我们的目标硬件矩阵，且每级对应一组明确的能力策略（禁用动画/基础动画/全动画），避免了策略配置的指数膨胀。评分采用加权累加制：CPU 核数和频率、GPU 硬件加速、内存容量各占一定权重，阈值设为 60/120 分两档切分。

检测方法按平台区分：Linux 通过 /proc/cpuinfo、/proc/meminfo、/dev/dri/、/sys/class/net/ 等 sysfs 路径直接读取；Windows 通过 WMI 查询。GPU 检测额外尝试创建 OpenGL 上下文获取驱动信息和扩展列表。所有检测结果缓存在 HardwareInfo 结构体中，避免重复检测。

用户或系统集成商可通过 setDeviceConfigOverride() API 强制覆盖自动检测结果，也可提供自定义检测脚本（输出 JSON）用于扩展硬件识别。这保证了在特殊硬件（如定制板卡）上的灵活性。

关键决策

决策	理由	被否决的替代方案
三级档位 (Low/Mid/High)	覆盖目标硬件矩阵、策略配置简洁、避免过度细分	五级或连续分数（策略组合爆炸）、两级（粒度不够）
加权评分算法 (CPU+GPU+Memory)	各维度独立评分、阈值明确、易于调试	机器学习模型（过重、训练数据不足）、纯特征匹配（不通用）
运行时检测 + 缓存	一次检测、全局复用、性能开销可控	编译时硬编码（无法适配新硬件）、每次查询都检测（性能浪费）
策略引擎按档位返回策略结构体	上层模块只需读策略、不关心检测细节	上层模块自行解读硬件信息（逻辑分散、重复代码）
setDeviceConfigOverride() API 覆盖	灵活、不依赖系统路径、适配嵌入式部署	读取 /etc/CFDesktop/device.conf（需要 root 权限、路径不可移植）

当前状态

已实现 -- CPU/GPU/Memory/Network 检测器、三级评分算法、策略引擎、用户覆盖 API 均已完成。详见 document/design_stage/status/。