4、Qt Quick on MCU 架构与渲染原理

Qt Quick on MCU 的核心挑战在于：如何在仅有几百 KB RAM、几十 MHz 主频、且通常不具备 GPU 的微控制器上，流畅运行基于 QML 声明的用户界面。要回答这个问题，必须深入理解 Qt Quick 的场景图（Scene Graph）架构、渲染线程模型以及 CPU/GPU 渲染路径的取舍。本章将拆解 Qt Quick on MCU 的渲染管线，剖析其与桌面版 Qt Quick 的本质差异，并给出在资源受限环境下优化渲染性能的系统性方法。

4.1 场景图（Scene Graph）核心原理

Qt Quick 的渲染基础是场景图——一种将 QML 声明式元素转换为可高效绘制的节点树结构。与传统的立即模式（Immediate Mode）绘图不同，场景图采用保留模式（Retained Mode）：QML 对象在首次创建时被编译为场景图节点，后续帧只需更新变化的部分，而非全部重绘。

在 MCU 环境中，场景图的构建必须更加精简。桌面版 Qt Quick 允许每个 QML 元素对应多个场景图节点（如边框、阴影、背景分别独立），但在 MCU 上，每个节点都意味着额外的内存开销和遍历时间。因此，Qt Quick on MCU 的 QML 编译器会执行节点合并优化：将相邻且样式相同的 Rectangle 合并为一个绘制指令，将静态文本缓存为位图，将不透明元素的子节点直接拍平到父节点中。

对比维度	桌面 Qt Quick	Qt Quick on MCU
节点粒度	细粒度，一个元素可拆多个节点	粗粒度，强制合并同类项
渲染指令	可延迟到 GPU 批次	立即生成，减少存储
纹理管理	动态纹理上传	预编译位图 + 图集
内存分配	允许运行时分配	启动时预分配，避免碎片

4.2 渲染线程模型与 CPU/GPU 路径选择

桌面 Qt Quick 通常使用两个线程：GUI 线程处理事件和 QML 状态变化，渲染线程独立执行 OpenGL 调用。但 MCU 上多线程意味着额外的栈空间（每个线程至少 4KB）和同步开销，因此 Qt Quick on MCU 默认采用单线程协作式渲染：GUI 线程处理完一批事件后，立即在同一线程内执行渲染，两者交替进行。

渲染路径的选择取决于目标硬件是否具备 GPU。对于无 GPU 的 MCU（如 Cortex-M7 系列），Qt Quick on MCU 使用软件光栅化器，将场景图直接绘制到帧缓冲。该路径下，所有绘制操作由 CPU 完成，性能瓶颈在于像素填充率和内存带宽。对于集成 GPU 的 MCU（如 Cortex-M55 + Ethos-U55 或部分高端型号），可启用 OpenGL ES 2.0 后端，将纹理上传至 GPU 显存，由 GPU 执行顶点变换和片段着色。

// 渲染路径选择示例（qmlproject 配置）
// 软件渲染路径（默认）
QQuickWindow::setRenderLoop(QQuickWindow::BasicRenderLoop);
// 硬件加速路径（需硬件支持）
QQuickWindow::setGraphicsApi(QSGRendererInterface::OpenGL);

4.3 资源受限环境下的渲染性能优化

优化渲染性能需要从三个层面入手：减少绘制工作量、降低内存带宽消耗、优化 CPU 负载。以下方法按优先级排序，适用于大多数 MCU 项目。

1. 局部刷新（Dirty Rectangles）：仅重绘发生变化的区域。Qt Quick on MCU 自动跟踪场景图的 dirty 节点，但开发者应避免使用全屏动画或频繁改变整个窗口的 opacity。
2. 纹理图集（Texture Atlas）：将所有静态图片在编译期合并为一张大纹理，运行时通过 UV 坐标引用。这减少了纹理绑定次数和内存碎片。
3. 色彩深度裁剪：如果屏幕仅需 16 位色，使用 RGB565 帧缓冲而非 RGBA8888，可将内存带宽减半。
4. 避免每帧创建对象：在 QML 中避免在信号处理器中动态创建 Component，这会导致场景图频繁重建。
5. 使用 Item 的 visible 属性：将不可见元素的 visible 设为 false，使其从场景图中移除，而非仅 opacity=0（后者仍参与渲染）。

优化手段	预期收益	实现成本	适用场景
局部刷新	帧时间降低 30-50%	低（框架自动）	静态背景 + 动态前景
纹理图集	绘制调用减少 50%+	中（需编译期处理）	图标、按钮、小图片
RGB565	带宽减半	低（配置即可）	无渐变、无半透明
预分配对象池	避免运行时卡顿	中（需代码重构）	列表滚动、频繁增删

4.4 实战案例：智能手表表盘渲染优化

某智能手表项目采用 Cortex-M7 @ 200MHz，1MB RAM，无 GPU，屏幕为 240×240 RGB565。初始实现使用桌面 Qt Quick 习惯编写 QML，导致帧率仅 12 FPS，CPU 占用 85%。

初始现象：表盘包含秒针动画（每秒 6 次更新）、时针/分针（每分钟更新）、背景渐变、数字刻度、蓝牙图标（状态变化）。

分析过程：通过 Qt Profiler 发现，每秒 6 次的秒针更新触发了整个表盘重绘，因为秒针的 rotation 变化导致其父 Item 的 boundingRect 扩大，进而污染了背景区域。同时，背景渐变使用了 LinearGradient，每次重绘都执行渐变计算。

优化步骤：

1. 将背景渐变预渲染为一张 240×240 的静态纹理，替换为 Image 元素。
2. 将秒针、时针、分针分别放入独立的 Item 中，并设置 clip: false，避免其旋转影响兄弟节点。
3. 将数字刻度合并为一张纹理图集，减少绘制调用。
4. 启用局部刷新，确认只有秒针所在区域被标记为 dirty。
5. 将帧缓冲从 RGBA8888 改为 RGB565，内存带宽减半。

结果对比：优化后帧率稳定在 30 FPS（受限于屏幕刷新率），CPU 占用降至 42%。内存占用从 180KB 降至 120KB（纹理图集 + RGB565）。

4.5 常见误区与总结

误区一：认为 GPU 一定比 CPU 快。在 MCU 上，GPU 的驱动开销和纹理上传可能抵消其并行优势，必须实测对比。

误区二：过度使用 opacity 和 scale 动画。这些属性会触发场景图节点的重新合成，成本远高于修改 x/y 坐标。

误区三：忽略帧缓冲格式。RGB565 与 RGBA8888 的带宽差异在 240×240 屏幕上看似微小，但在 60 FPS 下每秒相差 13.8MB 内存流量，足以影响整体系统性能。

误区四：在 QML 中大量使用 JavaScript 计算。MCU 的 JS 引擎性能有限，应将复杂计算移至 C++ 端或预计算。