1. 课程导入
在Qt Quick应用开发中，界面流畅度往往比功能完整度更早被用户感知。一个功能齐全但滑动卡顿、动画掉帧、启动迟缓的应用，会被直接判定为“不好用”。QML以声明式语法大幅降低了界面开发门槛，但声明式并不等于自动高性能：绑定表达式、属性变更通知、场景图节点、渲染线程与GPU提交，每一层都可能成为瓶颈。本课程的目标，是让你从“能写出界面”进阶到“能写出流畅界面”，并具备定位与量化性能问题的能力。
学习目标：从现象到根因的闭环能力
本课程围绕四个可验证的能力层次展开。第一层是观测能力：能够使用Qt Creator的QML Profiler、GammaRay、QSG_RENDER_TIMING等工具，采集帧时间、绑定求值次数、绘制调用等数据。第二层是归因能力：能把“掉帧”拆解为JavaScript求值过重、绑定链过长、过度重绘、纹理上传频繁或渲染线程阻塞等具体类别。第三层是优化能力：掌握Loader异步加载、Repeater替换为ListView、visible与opacity的取舍、ShaderEffect缓存、图层合成等常用手段。第四层是验证能力：用优化前后的帧率、帧耗时分布、内存占用等指标证明改动有效，而不是凭感觉判断。
核心概念：理解QML性能的五个关键词
- 绑定（Binding）：属性之间的依赖表达式。绑定让代码简洁，但每次依赖属性变化都会触发重新求值，长绑定链会形成级联更新。
- 场景图（Scene Graph）：QML元素在渲染前被转换为场景图节点，节点结构、材质与裁剪状态直接影响绘制批次。
- 渲染线程与同步：GUI线程负责JavaScript与属性更新，渲染线程负责场景图遍历与提交，两者通过同步点交换数据，同步点过多会造成阻塞。
- 批处理（Batching）：相同材质的相邻节点可合并为一次绘制调用，减少draw call是提升GPU效率的关键。
- 帧预算（Frame Budget）：60Hz下每帧约16.6ms，120Hz下约8.3ms。所有CPU与GPU工作必须在该预算内完成。
这五个概念构成了后续所有章节的分析语言。当你看到“界面卡了一下”，应当能迅速把它翻译成：是某次绑定求值超时，还是场景图节点数量突增，抑或纹理上传阻塞了渲染线程。
整体知识框架：从语言层到硬件层
本课程的知识框架按“由近及远”的顺序组织：最上层是QML语言与绑定机制，中间是Qt Quick的布局、模型视图与动画系统，下层是场景图与渲染管线，最底层是OpenGL/Vulkan/Metal等图形API与GPU行为。性能问题往往表现为上层现象，根因却在下层。因此课程不会孤立讲语法，而是始终把语法选择与渲染代价关联起来。
方法流程：一次完整的性能优化闭环
面对一个卡顿界面，建议按以下流程推进，避免“边猜边改”。
- 建立基线：在目标设备上运行，记录平均帧率、95分位帧耗时、启动时间与内存峰值。
- 复现问题：明确触发条件，例如“快速滑动列表时掉帧”或“切换页面时白屏300ms”。
- 采集数据：用QML Profiler查看JavaScript与绑定耗时，用GammaRay查看场景图节点与绘制调用。
- 定位热点：区分是CPU侧（绑定、JS、布局）还是GPU侧（填充率、纹理、draw call）。
- 实施优化：一次只改一个变量，便于归因。
- 回归验证：对比基线指标，确认无功能回归与新的性能回退。
# 常用环境变量：输出渲染时间信息
export QSG_RENDER_TIMING=1
export QSG_VISUALIZE=batches # 可视化批处理情况
export QML_IMPORT_TRACE=1 # 排查导入开销
# 运行应用后观察控制台输出的帧时间与批次统计案例场景：一个典型列表卡顿的拆解
假设一个商品列表使用Repeater加Column布局，包含200个带阴影和圆角的卡片。滑动时帧率从60降到25。按框架逐层排查：语言层发现每个卡片有12个绑定，其中3个依赖父级宽度，形成级联；组件层发现Repeater一次性创建全部200个委托，且未做可见性裁剪；渲染层发现阴影使用ShaderEffect且未缓存，每帧重新计算；硬件层发现draw call超过400，远超批处理能力。优化路径随之清晰：改用ListView按需创建委托，阴影改用预渲染纹理或BorderImage，减少绑定层级，最终帧率回到55以上。这个案例说明，性能问题很少是单点，而是多层叠加。
常见误区与复盘
| 误区 | 表现 | 正确做法 |
|---|---|---|
| 凭感觉优化 | 改了很多地方，帧率没变或更差 | 先测量基线，再定位热点 |
| 盲目使用visible: false | 元素仍参与绑定求值，只是不绘制 | 用Loader或destroy释放资源 |
| 过度使用ShaderEffect | GPU填充率飙升，移动端发热 | 优先用图片或缓存图层 |
| 忽略绑定链 | 一个属性变化触发上百次求值 | 用只读属性或C++后端聚合 |
| 只在桌面调试 | 桌面流畅，真机卡顿 | 始终在目标设备上验证 |
接下来的章节将沿着上述框架逐层展开：先讲绑定与JavaScript的代价，再讲组件加载与模型视图，然后深入场景图与渲染线程，最后落到工具链与真机调优。你不需要一次记住所有细节，但应当先建立“测量—定位—优化—验证”的思维习惯，这比任何单点技巧都更重要。