4. 选型需求分析
嵌入式GUI框架选型失败，往往不是因为候选框架“不够好”，而是因为需求没有被结构化地拆开。很多团队在选型时只盯着“界面好不好看”或“社区热不热”，却忽略了功能边界、性能上限、硬件约束、团队能力、许可证与长期维护这六个维度之间的相互制约。本章给出一套可落地的需求分析方法，把模糊的“我们想要一个GUI”转化为可比较、可验证、可决策的选型输入。
一、核心原理：六维需求模型
选型需求分析的本质，是把产品目标翻译成对GUI框架的约束条件。六个维度并非并列清单，而是存在优先级和耦合关系：功能需求决定“能不能做”，性能需求决定“跑不跑得动”，硬件资源决定“放不放得下”，团队能力决定“做不做得快”，许可证决定“能不能合法用”，长期维护决定“三年后还改不改得动”。
建议用“必须满足 / 尽量满足 / 可妥协”三档来标注每一条需求。必须满足项构成硬门槛，任何候选框架只要不满足其中一条，就应直接淘汰，而不是靠打分加权“抢救”。
二、方法流程：从产品目标到选型矩阵
建议按以下五步推进，每一步都产出可评审的文档，而不是停留在口头讨论。
- 功能需求清单化：列出所有界面形态（仪表盘、列表、弹窗、图表、视频播放）、交互方式（触摸、按键、旋钮、语音）、动态效果（转场、进度、实时曲线）以及国际化、主题切换、无障碍等要求。区分“首版必须”和“后续迭代”。
- 性能指标量化：把“流畅”翻译成具体数字，例如主界面刷新率≥30fps、触摸响应延迟≤80ms、动画掉帧率≤5%、冷启动到首屏≤1.5s。没有数字的性能需求无法验收。
- 硬件资源盘点：确认MCU主频、Flash与RAM余量、是否带GPU或2D加速、显示接口（RGB/MIPI/SPI）、色深与分辨率、是否支持外部SDRAM。这些直接决定候选框架的可行集合。
- 团队能力评估：统计团队熟悉的语言（C/C++/Rust/JS）、是否有GUI框架使用经验、能否阅读和修改框架源码、是否有专职UI设计与动效人员。
- 许可证与维护审查：确认许可证类型是否与产品分发方式兼容，评估社区活跃度、版本发布节奏、商业支持渠道、文档与示例质量、历史遗留问题修复速度。
关键原则：先做“淘汰式筛选”，再做“加权打分”。硬门槛不满足的框架不进入打分环节，避免用高分掩盖致命缺陷。
三、案例/场景：智能家居中控屏选型
某团队开发一款7英寸智能家居中控屏，MCU为Cortex-A7双核1.2GHz，512MB DDR3，Flash 4GB，带2D图形加速，运行Linux。产品要求：主界面60fps滑动、支持中文与英文、有实时温湿度曲线、支持OTA升级、预计年出货5万台。
按六维模型分析：功能上需要图表、动画、多语言；性能上要求60fps和低延迟；硬件资源充足但需控制内存占用；团队熟悉C++和Qt，无Web前端经验；许可证要求可闭源分发；长期维护要求至少5年安全更新。最终候选为Qt for Device Creation、LVGL（Linux后端）和Flutter Embedded。通过硬门槛筛选，Flutter Embedded因团队无Dart经验且商业支持成本高被降权，Qt因许可证费用与团队经验匹配进入终选，LVGL作为轻量备选。
| 需求维度 | 具体指标 | 优先级 | 验证方式 |
|---|---|---|---|
| 功能需求 | 图表、动画、多语言、OTA界面 | 必须 | 原型Demo验证 |
| 性能需求 | 60fps、触摸延迟≤80ms | 必须 | 目标板实测 |
| 硬件资源 | RAM占用≤120MB、Flash≤200MB | 必须 | 内存分析工具 |
| 团队能力 | C++熟练、无Dart经验 | 尽量 | 技能矩阵评估 |
| 许可证 | 允许闭源商业分发 | 必须 | 法务审查 |
| 长期维护 | 5年安全更新、活跃社区 | 尽量 | 版本历史与Issue分析 |
四、误区与复盘
常见误区一：把“功能多”当成“功能合适”。框架支持100种控件，但项目只需要8种，多出来的能力会带来学习成本和内存开销。
常见误区二：忽略许可证的传染性。GPL类许可证要求衍生作品开源，若产品需要闭源分发，必须在选型早期排除，而不是等到集成完成才发现。
常见误区三：用团队“愿意学”替代“学得会”。新框架的学习曲线若超过项目排期，会直接导致交付风险。建议用两周原型验证真实上手速度。
常见误区四：只看当前版本，不看维护节奏。一个两年未更新的框架，即使功能匹配，也可能在芯片迭代或安全漏洞面前失去支持。
复盘时建议回答三个问题：硬门槛是否被真正遵守？性能指标是否在目标硬件上实测过？许可证与维护风险是否由法务和架构师共同签字确认？只有把需求分析做成可追溯的决策记录，后续框架迁移或版本升级时才有依据可查。
选型需求分析检查清单（可复制到评审文档）
[ ] 功能需求已区分首版/迭代，并标注必须/尽量/可妥协
[ ] 性能指标已量化到帧率、延迟、内存、启动时间
[ ] 硬件资源已确认Flash/RAM/GPU/显示接口余量
[ ] 团队能力已评估语言、框架经验、源码修改能力
[ ] 许可证已确认与产品分发方式兼容
[ ] 长期维护已评估社区活跃度、版本节奏、商业支持
[ ] 硬门槛不满足的候选框架已直接淘汰
[ ] 所有结论有实测数据或书面依据，而非口头判断需求分析不是选型前的“ paperwork”，而是把工程风险提前暴露的过程。六维模型的价值在于：它让团队在写第一行GUI代码之前，就已经知道哪些框架根本不该进入候选名单，哪些指标必须在目标板上实测，哪些风险需要法务和架构师共同确认。做到这一点，选型就从“凭感觉”变成了“有依据的工程决策”。