2. 车载HMI基础概念
说实话，刚入行那会儿，我对工具链的理解就是「设计师用Sketch画图，开发用QT写代码」。直到我在一个量产项目里，看到设计稿和最终车机上的效果差了十万八千里——字体不对、动效卡顿、资源包大到刷不进MCU。那次之后我才明白，工具链不是简单的「画图→开发」，而是一整套从创意到硬件的工程流水线。
这一章，咱们就把这条流水线从头到尾捋一遍。我会结合自己踩过的坑，聊聊每个环节该用什么工具，以及怎么选型才不翻车。
2.1 从设计到代码：HMI开发的完整流程
一个典型的车载HMI项目，大致会经历下面这几个阶段。我习惯把它分成「设计侧」和「工程侧」两段来看。
| 阶段 | 核心产出 | 常用工具 | 我的经验 |
|---|---|---|---|
| 1. 用户研究与交互定义 | 用户画像、任务流、线框图 | Figma、Sketch、Axure | 别急着画高保真，先把逻辑走通 |
| 2. 视觉设计 | 高保真UI稿、设计规范、组件库 | Figma、Sketch、Adobe XD | 一定要建组件库，不然改稿改到哭 |
| 3. 动效与交互原型 | 动效demo、转场逻辑、状态机 | After Effects、ProtoPie、Principle | 动效参数要量化，别只给「丝滑」这种词 |
| 4. 工程化设计与资源导出 | 切图、字体、图标、资源清单 | Figma插件、Sketch插件、Zeplin | 导出规范必须写进合同，否则开发会骂人 |
| 5. 嵌入式开发与集成 | 可运行HMI二进制、资源包 | QT、Kanzi、Unity、CGI Studio | 性能摸底要趁早，别等集成阶段才发现跑不动 |
| 6. 测试与标定 | 测试报告、性能数据、bug修复 | QAC、Vector CANoe、自研工具 | HMI测试一定要上实车，模拟器骗不了人 |
核心观点：工具链的本质是「信息传递的管道」。设计侧的信息（颜色、尺寸、动效参数）要无损地传递到工程侧。管道堵了，车机上的UI就「失真」。
2.2 常用工具深度对比
市面上工具很多，但真正在车载领域站稳脚跟的，就那么几个。我按「设计工具」和「开发工具」两类来拆。
2.2.1 设计侧：Figma vs Sketch
这两个是绕不开的。我个人现在主用Figma，但Sketch也有它的铁粉。
| 对比维度 | Figma | Sketch |
|---|---|---|
| 平台 | Web + 客户端（跨平台） | 仅macOS |
| 协作方式 | 实时多人协作，天然优势 | 需插件或第三方工具 |
| 组件与样式 | 强，支持变量和条件逻辑 | 成熟，但生态略封闭 |
| 车载适配 | 插件丰富，可导出Kanzi/Unity格式 | 需手动转换，流程稍长 |
| 离线使用 | 支持，但功能受限 | 完全离线，适合涉密项目 |
我的建议：如果团队超过3人，或者有异地协作需求，直接上Figma。如果是个人项目或涉密项目，Sketch更稳妥。我曾经在一个项目里用Figma做设计，开发用Kanzi，中间通过插件自动同步，效率提升很明显。
2.2.2 开发侧：QT vs Kanzi vs Unity
这才是重头戏。选错开发工具，后面全是坑。
| 对比维度 | QT (QML/Qt Quick) | Kanzi (Rightware) | Unity (UI Toolkit) |
|---|---|---|---|
| 渲染引擎 | 基于OpenGL/ES，自研 | 自研3D引擎，针对车载优化 | Unity 3D引擎，通用性强 |
| 开发语言 | QML + C++ | 可视化脚本 + C++ | C# + 可视化编辑器 |
| 3D能力 | 中等，需额外集成 | 强，原生支持3D HMI | 极强，但需做性能裁剪 |
| 性能 | 优秀，轻量级 | 优秀，针对嵌入式优化 | 中等，需大量优化 |
| 生态与社区 | 成熟，文档丰富 | 中等，厂商支持为主 | 庞大，但车载资料少 |
| 典型应用 | 仪表盘、中控、Linux系统 | 高端仪表、3D HMI、虚拟座舱 | 全景显示、游戏化HMI、概念车 |
| 学习曲线 | 中等（QML易学，C++难） | 中等（可视化为主） | 陡峭（需懂3D和性能优化） |
避坑指南：我曾经在一个项目里选了Unity做仪表盘，结果发现启动时间超过5秒，内存占用飙到800MB。后来换回Kanzi，启动时间压到1.2秒，内存控制在200MB以内。所以，不是功能越强越好，而是「够用+稳定」才是王道。
2.3 工具选型策略：我总结的「三看」原则
选工具没有银弹。我这些年总结了一套方法，叫「三看」：看硬件、看团队、看场景。
- 看硬件平台：MCU还是MPU？内存多大？GPU支持什么？如果是低端MCU，QT是首选；如果是高端MPU+独立GPU，Kanzi或Unity可以考虑。
- 看团队构成：团队是设计师多还是开发多？设计师多，选Figma+Kanzi的组合，可视化程度高；开发多，选Sketch+QT的组合，控制力强。
- 看项目阶段：预研/概念车，可以大胆用Unity，效果炸裂；量产项目，老老实实QT或Kanzi，稳定压倒一切。
一个真实的选型案例：去年我参与的一个项目，硬件是瑞萨R-Car H3，内存4GB，团队5个设计师+8个开发。我们最终选了Figma（设计）+ Kanzi（开发）。理由是：Figma的组件库可以一键导出Kanzi资源，设计师能直接在Kanzi Studio里调整布局，开发只负责逻辑和性能优化。整个流程从设计到集成，缩短了约30%的时间。
2.4 工具链全景图：一张SVG说清楚
下面这张图，是我自己梳理的HMI工具链全景。它把设计侧、工程侧、以及中间的「桥梁」工具都串起来了。你想想看，从设计师的创意到车机上的像素，中间要经过多少道工序？
2.5 选型决策速查表
最后，我整理了一个速查表。遇到选型纠结的时候，直接对着这个表看，基本不会跑偏。
| 项目类型 | 推荐设计工具 | 推荐开发工具 | 理由 |
|---|---|---|---|
| 量产仪表盘（2D为主） | Figma | QT (QML) | 稳定、轻量、生态成熟 |
| 高端3D虚拟座舱 | Figma + AE | Kanzi | 3D能力强，针对车载优化 |
| 概念车/预研项目 | Sketch + AE | Unity | 效果炸裂，灵活性高 |
| 中控娱乐系统 | Figma | QT 或 Kanzi | 看硬件性能，中低端用QT |
| HUD/AR-HUD | Figma + 专用工具 | Kanzi 或 自研 | 需要特殊的光学标定支持 |
一个小技巧：选型时别只看工具本身，还要看「工具链的闭合度」。比如Figma+Kanzi的组合，有官方插件可以直接同步组件；Sketch+QT的组合，就需要手动导出资源，中间容易出错。闭合度越高，流程越顺，后期扯皮越少。
嗯，工具链总览就聊到这儿。记住一句话：工具是死的，流程是活的。选对工具，能让你的HMI项目事半功倍；但真正决定项目成败的，是工具背后的人——设计师和工程师怎么协作，信息怎么传递，这才是核心。