4. QML引擎与JavaScript性能
QML 的性能问题往往不在“绘制”本身，而在“驱动绘制的数据流”。属性绑定、信号处理与 JavaScript 表达式共同构成了 QML 的运行时逻辑层，它们决定了界面何时重算、重算多少次、以及每次重算的代价。理解 QML 引擎如何求值绑定、如何触发信号、如何执行 JavaScript，是优化交互流畅度的前提。
一、核心原理：绑定表达式是一条“依赖—求值—通知”链
QML 的属性绑定不是一次性赋值，而是一个持续存在的表达式。引擎在首次求值时记录该表达式读取了哪些属性（依赖收集），当任一依赖属性发生变化时，引擎将该绑定标记为“脏”，并在合适的时机重新求值，再把新结果写回目标属性，进而可能触发下一级绑定或信号。这个过程可以概括为：依赖收集 → 变更通知 → 脏标记 → 重新求值 → 属性写入 → 级联传播。
因此，绑定的成本由三部分决定：表达式本身的复杂度、依赖属性的变更频率、以及级联传播的深度。一个看似简单的绑定，如果依赖了一个每帧都在变化的属性，就会变成每帧执行的“隐形循环”。
二、方法流程：从绑定到信号的优化路径
优化 QML 逻辑层，可以按以下顺序排查与改造：
- 识别高频绑定：找出依赖动画属性、鼠标位置、定时器、传感器数据的绑定，这些是重算热点。
- 降低表达式复杂度：把多步计算、字符串拼接、数组遍历从绑定中移出，改为在信号处理器中一次性计算并缓存。
- 减少级联深度：避免 A 绑定 B、B 绑定 C、C 又绑定 A 的长链，必要时用中间属性或 C++ 侧聚合。
- 控制信号频率：对高频信号做节流或合并，避免每次微小变化都触发完整重算。
- 用 C++ 承担重计算：把复杂算法、数据过滤、排序放到 C++ 模型或工具类中，QML 只做展示绑定。
关键判断：如果一个绑定表达式在 1 秒内被求值超过 60 次，它就已经进入了“每帧路径”，必须优先优化。
三、案例与场景：一个高频绑定的改造
假设有一个实时仪表盘，指针角度绑定到传感器值，同时文本显示格式化后的数值：
// 改造前：绑定中做格式化与判断
Text {
text: "温度: " + sensor.value.toFixed(2) + " °C"
color: sensor.value > 80 ? "red" : "green"
}
当 sensor.value 每秒变化上百次时，字符串拼接、toFixed、三元判断都会在每次变化时执行。改造方式是把格式化结果缓存到中间属性，并只在必要时更新：
// 改造后：信号处理器中计算，绑定只读结果
property string displayText: ""
property color displayColor: "green"
Connections {
target: sensor
function onValueChanged() {
displayText = "温度: " + sensor.value.toFixed(2) + " °C"
displayColor = sensor.value > 80 ? "red" : "green"
}
}
Text {
text: displayText
color: displayColor
}
这样，Text 的绑定只读取两个简单属性，重算成本大幅降低；复杂逻辑集中在信号处理器中，也更容易做节流。
四、常见陷阱与复盘清单
| 陷阱 | 表现 | 优化方向 |
|---|---|---|
| 绑定中调用函数 | 每次依赖变化都重新执行函数，函数内可能还有循环 | 改为信号处理器中调用，或缓存结果 |
| 绑定依赖动画属性 | 动画每帧变化，绑定每帧重算 | 用 Behavior 或 C++ 侧插值，减少 QML 绑定 |
| 信号处理器中做重计算 | 高频信号触发大量 JavaScript 执行 | 节流、合并、移到 C++ 线程 |
| 循环绑定 | A 改 B、B 改 A，引擎反复求值 | 打破循环，引入单向数据流 |
过度使用 eval 或动态属性 |
JavaScript 引擎无法优化，解释执行变慢 | 改用静态属性与函数 |
复盘要点：QML 绑定是声明式的，但声明式不等于零成本。每一次绑定求值都是一次 JavaScript 执行，每一次信号触发都可能引发级联。优化的核心不是“少写绑定”，而是“让绑定只做轻量读取，把重计算放到可控的时机”。
在实际项目中，建议用 QML Profiler 观察绑定求值次数与 JavaScript 执行时间，优先处理那些“每秒执行数百次”的绑定和信号处理器。把高频、重计算的逻辑下沉到 C++，把 QML 留给展示与轻量交互，才能让界面在复杂数据流下依然保持稳定帧率。