性能优化与真机调试

# 第 14 章性能优化与真机调试

本章定位：从"能跑"到"跑得快且不出事"。前面 13 章教了 QML 从语法到渲染后端的全部知识，本章把它们串成一套可操作的生产级优化清单——启动加速、渲染诊断、内存画像、CPU 热点定位、SSH+GDBServer 远程调试与崩溃转储分析。读完本章，你能把 ARM 板上 8 秒冷启动降到 1 秒、把 1000 Draw Call 压到 5 个、用 heaptrack 抓出 512MB 内存里的 300MB 泄漏。

# 目录介绍

14.1 案例引入
14.2 启动速度优化
14.3 渲染诊断
14.4 内存优化
14.5 真机远程调试
14.6 HMI 全流程
14.7 新手陷阱
14.8 速查表

# 14.1 案例引入

# 14.1.1 HMI 启动慢

某工控 HMI 设备（i.MX8 + 2GB RAM + eMMC 存储）上电到界面显示用了 8 秒，竞品硬件配置更低的设备只要 1.5 秒。客户投诉"开机太慢"——工程师拍了一张启动时序图：

0.0s  ─── 内核启动
1.2s  ─── systemd 到达 /sbin/init
1.5s  ─── 启动 myapp（竞品此时已经显示界面）
2.0s  ─── Qt 库加载（libQt6Core.so 10MB + libQt6Quick.so 8MB + ...）
4.8s  ─── QML 解析 + 编译（50 个 .qml 文件）
6.2s  ─── 首帧渲染（大量 Image 解码 + 绑定求值）
8.0s  ─── 用户看到界面 ← 竞品 1.5s 就看到了

# 14.1.2 根因分析

总启动时间 8000ms:
├── Qt .so 加载         2000ms ── 静态编译 → 0ms
├── QML 解析+编译 (V4)   2800ms ── qmlcachegen 预编译 → 300ms
├── Image 解码            1800ms ── 预解码 + 缩小尺寸 → 200ms
└── 首帧渲染 + 绑定求值   1400ms ── Splash Screen + 惰性加载 → < 100ms
─────────────────────────────────────────────────
优化后总启动: < 1000ms

# 14.1.3 三大问题

问题	在哪节回答
启动的 8 秒花在哪？怎么从 8s 压到 1s？	§14.2 + §14.6
Profiler 火焰图上怎么看"哪个绑定拖累了帧率"？	§14.3
ARM 板上崩溃了怎么拿到调用栈？	§14.5

# 14.2 启动速度优化

# 14.2.1 启动耗时分解

# 精确测量各阶段耗时
QT_DEBUG_PLUGINS=1 time ./myapp -platform eglfs 2>&1 | grep -E "loaded|QML|cache"

阶段	典型耗时	优化手段	优化后
内核 + systemd	1.2s	裁剪内核、禁用不需要的服务	0.8s
Qt .so 加载	2.0s	静态链接 / `LD_BIND_NOW=0`	0~0.5s
QML 解析+编译	2.8s	`qmlcachegen` 预编译	0.3s
Image 解码	1.8s	预解码 + `sourceSize` 缩小 + 异步	0.2s
首帧渲染	1.4s	Splash Screen + Loader 惰性加载	< 0.1s
总计	~8s		< 1.5s

# 14.2.2 预编译 Splash

# 构建时预编译 QML 为字节码——跳过运行时的 V4 解析
qmlcachegen --resource main.qrc -o main.qmlc
# 50 个 .qml: 2800ms → 300ms

// Splash Screen——启动即显示静态图，掩盖加载时间
Window {
    visible: true; color: "black"
    Image {
        anchors.centerIn: parent
        source: "qrc:/splash.png"       // 预处理的静态图——瞬间显示
    }

    // 真正的界面异步加载
    Loader {
        id: mainLoader
        anchors.fill: parent
        asynchronous: true
        source: "MainDashboard.qml"
        onStatusChanged: {
            if (status === Loader.Ready) {
                splashImage.visible = false  // 主界面就绪→隐藏 splash
            }
        }
    }

    Image { id: splashImage; source: "qrc:/splash.png" }
}

// 用户感知: splash 在 0.3s 出现 → 主界面在 1.0s 切换
// 实际加载时间仍然是 1.2s——但用户感知的是 0.3s

# 14.2.3 静态与预加载

# 静态编译 Qt——取消动态库加载耗时
./configure -static -release -opengl es2 -eglfs ...
# .so 加载: 2000ms → 0ms（二进制增大至 30-50 MB）

# systemd 预加载——设备启动时后台预先加载 Qt 库到 page cache
# /etc/systemd/system/qt-preload.service
[Service]
Type=oneshot
ExecStart=/bin/sh -c "cat /usr/lib/libQt6*.so.* > /dev/null"
# → 下次 myapp 启动时 .so 已在 page cache → 加载时间 < 500ms

# 14.2.4 动态链接深入

静态编译虽然彻底——但有些场景（OTA 热更新、LGPL 合规）不能静态链接。此时延迟绑定和 prelink 是折中方案：

延迟绑定（Lazy Binding）的代价

Linux 默认 LD_BIND_NOW=0（延迟绑定），启动时 PLT 表项指向 _dl_runtime_resolve，第一次调用时才解析符号地址：

非延迟绑定 (LD_BIND_NOW=1):         延迟绑定 (LD_BIND_NOW=0, 默认):
process startup                     process startup
  ├── ld.so 解析全部 NEEDED           ├── ld.so 只记录 PLT 表
  │   ├── libQt6Core.so  → 1200 符号    │   (跳过符号解析——快)
  │   ├── libQt6Quick.so → 800 符号     ├── main() 入口
  │   └── ... 总计 5000+ 符号           ├── 第一次调 QApplication::exec()
  ├── 启动慢 (1-2s)                      │   └── _dl_runtime_resolve("exec")
  └── 运行时无额外开销                    │       └── 查找符号 → 改写 PLT 表项
                                        └── 后续调用开销 = 0 (PLT 已补全)

延迟绑定的好处是启动快——但嵌入式上的代价是抖动放大：第一帧渲染时密集调用 Qt API，每个未绑定的符号都触发一次 _dl_runtime_resolve，额外增加 200-500ms。

# 强制立即绑定——启动变慢但帧间无抖动
export LD_BIND_NOW=1

# 测量绑定开销
LD_DEBUG=bindings ./myapp 2>&1 | wc -l   # 统计绑定次数

prelink 预链接——在构建时解析符号地址，运行时直接跳转：

# ARM 板上运行 prelink——修改 .so 的 PLT 表为预定地址
prelink -av /opt/myapp/lib/*.so
# 原理: 提前计算 GOT 地址 → 运行时 ld.so 不解析 → 每个符号省 ~100ns
# 限制: 各 .so 加载地址必须固定 (ASLR 关闭或 -fPIE 编译)

方案	启动耗时	运行时抖动	适用
静态链接	0ms（.so加载）	零	单设备部署、不可热更新
`LD_BIND_NOW=1`	1-2s	零	帧率敏感场景
默认延迟绑定	0.3-0.8s	首帧 +200-500ms	桌面、不敏感场景
prelink	0.3-0.5s	<50ms	固定部署、无 ASLR

# 14.3 渲染诊断

# 14.3.1 可视化调试

QSG_VISUALIZE 是 Scene Graph 内置的"X 光眼"——把抽象的渲染过程画成可见的色块：

# 批处理分组——每一色 = 一个独立 batch
export QSG_VISUALIZE=batches
# 优化目标: 色块越少越好（同色 = 同 batch = 合批成功）

# overdraw 热力图——颜色越红 = 同一像素被绘制次数越多
export QSG_VISUALIZE=overdraw
# 优化目标: 红色越少越好

# 脏区域——红色 = 本帧需要更新的部分（其他不变）
export QSG_VISUALIZE=changes
# 优化目标: 红色越少越好（只动画需要变的属性）

# 裁剪区域——绿色框 = clip: true 的裁剪范围
export QSG_VISUALIZE=clip

./myapp -platform eglfs

模式	看什么	优化目标
`batches`	色块数（同色=同batch）	减少 Draw Call
`overdraw`	红色热力（红=多次重绘）	减少层叠
`changes`	红色区域（红=整帧重画）	减少绑定更新
`clip`	绿色边框（裁剪范围）	该裁的裁、不该裁的别裁

# 14.3.2 火焰图分析

Qt Creator → Analyze → QML Profiler → 连接目标进程
时间线火焰图:
├── Painting           ← 渲染耗时（应 < 16.6ms/帧）
│   └── 点击展开→看到每个 QSGNode 的绘制时间
├── Compiling          ← QML 编译（仅启动期）
├── Creating           ← 对象创建（Loader/createObject）
├── Binding            ← 绑定求值时间 ← 最常见的帧率杀手
│   └── 点击展开→看到具体哪个 binding 表达式耗时最长
├── HandlingSignal     ← 信号处理时间
└── JavaScript         ← V4 执行时间

典型火焰图解读——Binding 时间线占比 40%：

→ 展开 Binding → 看到 "gauge.value: parent.speed * 3.6 / maxSpeed * 270 - 135"
   → 这个绑定表达式每帧被求值 8 次（被 8 个属性依赖）
   → 修复: readonly property real angle: speed * 3.6 / maxSpeed * 270 - 135
     → 绑定求值只算一次 → Binding 占比降到 5%

# 14.3.3 ListView 提速

这是第 2 章案例的完整重现——每步优化对照 Profiler 数据：

// 版本 0（反例）: 1000 Draw Call, 22 fps, Binding 42ms/帧
ListView {
    model: 500
    delegate: Rectangle {
        width: 100; height: 100; color: "blue"
        Rectangle {
            anchors.centerIn: parent
            width: 50; height: 50; color: "red"; rotation: 45
        }
    }
}

优化步骤	改动	Draw Call	FPS	Binding 耗时
0 反例	—	~1000	22	42ms
1 去 rotation	删 `rotation: 45`	5	58	42ms
2 + reuseItems	`reuseItems: true`	5	60	3ms
3 + 异步 delegate	`Loader { asynchronous: true }`	5	60	1ms
4 + Image Atlas	多图→单图集	1	60	< 1ms

案例知识融合：①Draw Call 从 1000→5 靠的是第 2 章 §2.3 的批处理铁律；②Binding 耗时从 42ms→3ms 靠的是 delegate 复用池（不再每帧创建新绑定）；③最终 1 Draw Call 靠的是 Image Atlas 把所有小图合并为一张大图。

# 14.3.4 帧计时

QSG_RENDER_TIMING 是比 QSG_VISUALIZE 更精密的"秒表"——它以微秒粒度分解每一帧的耗时：

export QSG_RENDER_TIMING=1
export QSG_RENDER_TIMING_LOG_FILE=/tmp/frames.csv
./myapp -platform eglfs
# 输出到日志文件，每帧一行 CSV

一帧的完整时间预算（60fps = 16.6ms/帧）：

帧耗时分解（ARM i.MX8, 仪表盘界面, QSG_RENDER_TIMING=1）:

sync_time:    2.1ms ← GUI 线程同步→Render 线程（属性变更写入 QSGNode）
render_time:  9.8ms ← Render Thread 实际 OpenGL 绘制
swap_time:    1.2ms ← eglSwapBuffers（等待 VSync）
────────────────────
frame_total: 13.1ms ← 距离 16.6ms 预算还剩 3.5ms

// 正常情况: render_time < 10ms → 有空间加动画
// 危险线:   render_time > 14ms → 开始掉帧
// 崩溃线:   render_time > 16.6ms → 稳定掉帧（用户感知）

探索性问题——为什么 swap_time 偶尔飙升到 8ms？

诊断链：

swap_time 从 1.2ms 跳到 8ms → 超过了 eglSwapBuffers 正常等待 1 个 VSync 的 16.6ms？
  ↓ 不对——swap_time 最大应该是 1 个 VSync 周期
  ↓ 除非: GPU 队列积压——DRM page flip 前的帧还没渲染完
  ↓ 用 QSG_RENDER_TIMING 的 render_time 列验证:
    → render_time 在 swap_time 飙升的前一帧 > 20ms
    → 根因: 某一帧渲染超过了 16.6ms，导致下一帧 swap 要等 GPU 排空
    → 就像高速公路上的一脚刹车——后续车队都要减速

帧预算分配建议（嵌入式 60fps）：

组件	预算	超预算排查
sync_time	< 3ms	减少脏属性数、合并小 QML 文件
render_time	< 11ms	减少 Draw Call / overdraw / shader 复杂度
swap_time	< 2ms	检查 VSync 是否正确、GPU 频率是否降频
binding_eval	< 1ms	readonly property、减少绑定深度

# 14.4 内存优化

# 14.4.1 内存画像

# 安装 heaptrack
sudo apt install heaptrack heaptrack-gui

# 启动应用 + 记录内存分配
heaptrack ./myapp -platform eglfs

# 运行 5 分钟后正常退出 → 生成 .gz 报告文件
heaptrack_gui heaptrack.myapp.XXXXX.gz

报告解读：

Peak RSS: 285 MB ← 峰值物理内存（检查是否接近板子的 512MB）
Peak heap: 320 MB ← 峰值堆内存（峰值 RSS - 堆 = 代码段 + 栈）

Top allocations:
  42%  → QImage::QImage()        ← Image 解码
  18%  → ListModel::append()      ← JS 堆内数据
  12%  → QQmlBinding::evaluate()  ← 绑定求值临时对象
   8%  → QString::fromUtf8()      ← 文本处理

# 14.4.2 图片与懒加载

// ❌ 反例: 20 张 1920×1080 PNG 全部解码
Repeater {
    model: 20
    Image { source: "bg_" + index + ".png" }
}
// → 20 × 1920×1080×4 = 158 MB 仅图片内存！

// ✅ 正例: 预缩放到目标尺寸
Image {
    source: "bg_0.png"
    sourceSize: Qt.size(400, 300)   // 解码时直接缩到 400×300
    // → 400×300×4 = 0.5 MB 单张图片内存
}

// ✅ Loader 懒加载——不活跃页面不创建对象树
SwipeView {
    currentIndex: 0
    Repeater {
        model: ["仪表","导航","音乐","设置","空调"]
        Loader {
            active: SwipeView.isCurrentItem  // 仅当前页激活
            sourceComponent: tabComponents[index]
        }
    }
}

# 14.4.3 Valgrind 检测泄漏

# 交叉编译 Valgrind 或使用板载版本
valgrind --leak-check=full --show-leak-kinds=all ./myapp -platform eglfs

# 输出示例:
# ==1234== 16 bytes in 1 blocks are definitely lost in loss record 42 of 87
# ==1234==    at 0x484682F: operator new(unsigned int) (vg_replace_malloc.c:483)
# ==1234==    by 0x4C9A3E7: MyItem::updatePaintNode(QSGNode*, ...) ← 每帧 new 但没 delete

快速定位——查看 definitely lost 和 indirectly lost，前者是确定泄漏、后者是被泄漏对象间接持有的内存。

# 14.4.4 图片缓存与解码

Image 内存问题不只在"图片太大"——还在于 Qt 的图片缓存策略和解码线程池：

QPixmapCache 全局缓存

Qt 默认开启 QPixmapCache——所有通过 qrc:/ 加载的图片在第一次解码后会缓存为 GPU 纹理。这意味着：

// 场景: 同一张 bg.png 出现在 5 个 Tab 页面
// ❌ 误区: 以为 "5 个 Image 对象 = 5 份 GPU 纹理 = 5 倍内存"
Repeater { model: 5; Image { source: "bg.png" } }

// ✅ 实际: QPixmapCache 命中——只有 1 份 GPU 纹理被 5 个 Image 共享
// 验证: QPixmapCache::cacheLimit() 返回缓存上限 (默认 10MB)
//       超过上限时 LRU 淘汰旧纹理——所以高频切换页面可能"重新加载"

// C++ 侧控制缓存大小
QPixmapCache::setCacheLimit(20480);  // 20 MB——嵌入式 512MB 内存下的推荐

解码线程池——QT_IMAGE_DECODE_THREADS 控制并行解码数：

# 默认 = CPU 核心数。嵌入式 ARM 板通常 4 核，默认 4 线程
# 如果同时加载 50 张小图 → 4 个线程并行解码 → 内存峰值 > 预期
export QT_IMAGE_DECODE_THREADS=2    # 限制 2 线程——降低内存峰值

# 完全关闭异步解码（所有解码在 GUI 线程——小图场景）
export QT_IMAGE_DECODE_THREADS=0

QML Image 解码时机决策表：

属性	解码时机	内存行为	推荐
无 `asynchronous`	同步——阻塞 GUI 线程	Pixmap 直接进缓存	首帧关键图（splash）
`asynchronous: true`	后台线程池	纹理在线程间拷贝	非首屏图片
`sourceSize`	解码时缩小	节省 10-50×	所有已知尺寸的图
`cache: false`	不存缓存	每次重新解码	低频、大图

探索性诊断——"应用用了 10 分钟后内存翻了三倍"

不是泄漏——heaptrack 显示峰值稳定。根因排查：

1. 检查 QPixmapCache::cacheLimit() → 10MB 默认
   → 5 分钟滑动浏览图片后 LRU 淘汰 + 新图插入 → 缓存颠簸

2. 检查 Image 是否写了 sourceSize → 很多图没写
   → 原图 1920×1080 被解码为 GPU 纹理 1920×1080
   → 但实际显示区域只有 100×100

3. 检查 cache 策略 → 全是默认 cache: true
   → 浏览过的 200 张图全部在缓存 → 缓存放不下也赖着不走

修复:
  QPixmapCache::setCacheLimit(51200)  // 加大到 50MB
  Image { sourceSize: Qt.size(100,100); cache: false }  // 按需加载不缓存

# 14.5 真机远程调试

# 14.5.1 远程 GDB

# ARM 板上——启动 gdbserver（监听在 2345 端口）
gdbserver :2345 ./myapp -platform eglfs
# Process myapp created; pid = 1234
# Listening on port 2345

# x86 开发机上——连接
arm-linux-gnueabihf-gdb ./myapp      # 用交叉编译工具链的 gdb
(gdb) target remote 192.168.1.100:2345
(gdb) break main.cpp:42               # 设断点
(gdb) continue                        # 继续执行
# → 在 ARM 板上触发断点时，gdb 同步停下

(gdb) bt                              # 打印调用栈
(gdb) info threads                    # 所有线程状态
(gdb) thread 2                        # 切换到 Render Thread
(gdb) bt                              # 查看 Render Thread 的调用栈
(gdb) print speedValue                # 打印变量值

# 14.5.2 崩溃分析

# ARM 板上——开启 core dump
ulimit -c unlimited
echo "/var/crash/core.%e.%p.%t" > /proc/sys/kernel/core_pattern
./myapp -platform eglfs             # 让它崩溃 → 生成 /var/crash/core.myapp.1234.xxx

# x86 开发机上——用 gdb 分析 core dump
scp root@192.168.1.100:/var/crash/core.myapp.* .
arm-linux-gnueabihf-gdb ./myapp core.myapp.1234.xxx
(gdb) bt full                       # 完整调用栈 + 所有局部变量值
(gdb) info registers                # CPU 寄存器状态（崩溃瞬间）
(gdb) frame 3                       # 切换到调用栈第 3 层
(gdb) print *this                   # 打印当前对象的完整状态

从 core dump 反推崩溃原因——典型崩溃场景：

(gdb) bt
#0  0x76a4c3e8 in QSGNode::parent() const (this=0x0)   ← 空指针解引用！
#1  0x76b12a44 in QQuickItem::updatePaintNode(...)
#2  0x76b13450 in QSGRenderer::syncAndRender()

→ 根因: updatePaintNode 返回了 nullptr，但调用方没检查
→ 修复: 确保 updatePaintNode 永远返回有效的 QSGNode*

# 14.5.3 自定义日志系统

#include <QFile>
#include <QTextStream>
#include <QMutex>

static QMutex logMutex;
static QFile logFile("/var/log/myapp.log");

void customMessageHandler(QtMsgType type, const QMessageLogContext& ctx,
                          const QString& msg) {
    QMutexLocker lock(&logMutex);
    QString timestamp = QDateTime::currentDateTime().toString("hh:mm:ss.zzz");
    QString level;
    switch (type) {
        case QtDebugMsg:    level = "DEBUG"; break;
        case QtInfoMsg:     level = "INFO";  break;
        case QtWarningMsg:  level = "WARN";  break;
        case QtCriticalMsg: level = "CRIT";  break;
        case QtFatalMsg:    level = "FATAL"; break;
    }

    QString line = QString("[%1] [%2] %3:%4 - %5\n")
        .arg(timestamp, level, ctx.file, QString::number(ctx.line), msg);

    // 双输出：文件 + stderr（串口）
    logFile.write(line.toUtf8());
    logFile.flush();
    fprintf(stderr, "%s", qPrintable(line));
}

// main()
qInstallMessageHandler(customMessageHandler);
logFile.open(QIODevice::Append | QIODevice::Text);

# 14.5.4 CPU 热点分析

gdb 能看"卡在哪"，perf 能看"为什么卡"——它是 Linux 内核的 CPU 采样分析器，不需要插桩代码：

# ARM 板上安装 perf（通常由内核提供）
# 检查: ls /boot/config-$(uname -r) | xargs grep CONFIG_PERF_EVENTS

# 采样 10 秒——记录所有 CPU 热点
perf record -g -p $(pidof myapp) -- sleep 10
# -g: 记录调用栈   -p: 指定进程

# 生成报告——按函数排序
perf report --stdio | head -40

典型输出解读（ARM 板 i.MX8）：

Samples: 85K of 'cycles', Event count: 48231500000

Overhead  Symbol
  18.23%  [.] QSGBatchRenderer::Renderer::renderBatches
          └── QSGRenderer::renderScene
              └── QQuickWindowPrivate::renderSceneGraph
                   (75K samples—— Render Thread 占比最高)

  12.41%  [.] V4::Moth::VME::interpret
          └── QQmlBinding::evaluate
              └── QQmlNotifier::emitNotify
                   (52K samples—— Binding 求值是 JS 热点)

   8.15%  [.] eglSwapBuffers
          └── drmModePageFlip
              └── (等待 VSync——正常)

   7.62%  [.] QImage::convertToFormat
          └── QQuickImageBase::pixmap
              └── (Image 解码——占用了不该占的 Render Thread)

perf 热点到优化的映射：

perf 热点	含义	优化动作
`QSGBatchRenderer` > 40%	Draw Call 过多	合并图层 / 减少批处理断点
`V4::Moth::VME` > 15%	JS 绑定求值重	`readonly` / C++ Model / 减少深层绑定
`QImage::convertToFormat`	Image 解码在渲染路径	`sourceSize` / 预解码 / 异步加载
`drmModePageFlip` > 20%	GPU 等待时间过长	降低渲染复杂度 / 检查 GPU 频率
`malloc/free` 高频出现	分配/释放抖动	对象池 / 预分配 / `QVector::reserve`

嵌入式 perf 部署要点：

# 方案 A: 板载 perf（内核自带——推荐）
# 确认内核编译了 perf
zcat /proc/config.gz | grep PERF_EVENTS
# → CONFIG_PERF_EVENTS=y → 可以直接用

# 方案 B: 交叉编译 perf
# 从内核源码 tools/perf/ 交叉编译
make -C tools/perf CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64
# 拷贝到 /usr/bin/

# 方案 C: simpleperf (Android/受限环境)
# Google 的简化版 perf——无需内核符号表

# 14.6 HMI 全流程

下面把前面 13 章的知识点浓缩到同一个工控 HMI 项目里——从启动到渲染到内存到远程调试，一镜到底。

# 14.6.1 启动脚本

#!/bin/bash
# 工控 HMI 启动优化全流程脚本

echo "=== Step 1: 内核 + systemd 精简 ==="
systemctl disable bluetooth.service NetworkManager.service
# → 内核启动: 1.2s → 0.8s

echo "=== Step 2: QML 预编译 ==="
qmlcachegen --resource main.qrc -o main.qmlc
# → 跳过 V4 解析: 2.8s → 0.3s（见第 2.7.3 节 JIT 编译缓存）

echo "=== Step 3: 图片预缩放 ==="
for img in assets/*.png; do
    convert "$img" -resize 400x300 "assets_thumb/$(basename $img)"
done
# → Image 解码: 1.8s → 0.2s（见第 5.3 节 Image sourceSize 详解）

echo "=== Step 4: Splash Screen ==="
# main.qml 第一帧是静态 splash.png → 用户感知 0.3s（见第 14.2.2 节）

echo "=== Step 5: systemd 预加载 ==="
systemctl enable qt-preload.service
# → Qt .so 已在 page cache → 加载: 2.0s → 0.5s

echo "总启动: 0.8 + 0.3 + 0.2 + 0.5 ≈ 1.8s（用户感知 0.3s）"

# 14.6.2 运行时渲染优化

启动脚本只解决了"首帧快"，但用户操作时卡不卡，取决于 Scene Graph 与绑定的协作——这部分原理在第 2 章 §2.3-2.4 和本章 §14.3：

// 仪表盘主页面——知识点串联
Window {
    visible: true; color: "black"
    
    // 【第 5 章 布局】：anchors 响应式适配
    Item {
        anchors.fill: parent
        anchors.margins: 20
        
        // 【第 2.8 章 性能】异步加载非首屏 Tab
        Loader { id: navLoader; asynchronous: true; source: "NavView.qml" }
        
        // 【第 4 章 绑定】关键动画属性用 readonly 避免重复求值
        readonly property real speedAngle: speed * 3.6 / maxSpeed * 270 - 135
        
        // 【第 8 章 动画】GPU 友好的 transform 替代 CPU 布局动画
        Item {
            rotation: speedAngle
            Behavior on rotation { RotationAnimation { duration: 150; easing.type: Easing.OutCubic } }
        }
        
        // 【第 7 章 模型视图】C++ Model 而不是 ListModel
        ListView {
            model: canModel  // C++ QAbstractListModel
            reuseItems: true // 【第 7.3 节】复用池避免重复创建绑定
            delegate: CanDelegate { }
        }
    }
    
    // 【第 13 章 后端】EGLFS 独占屏幕
    Component.onCompleted: {
        console.log("Platform:", Qt.platform.pluginName)  // eglfs
    }
}

# 14.6.3 诊断闭环

结合本章 §14.3-14.5 工具链，完整的排查→修复流程：

用户反馈：仪表盘指针抖动
  ↓
Step 1: QSG_VISUALIZE=batches → 看到一帧 87 个 batch（见 §2.3.3 批处理原理）
  ↓
Step 2: Profiler → Binding 时间线显示 "speedAngle" 每帧被 5 个 Item 重复求值 5 次
  ↓
Step 3: 修复 → 改为 readonly property，绑定只算一次 → Batch 降到 4 个
  ↓
Step 4: QSG_VISUALIZE=overdraw → 发现背景层被仪表盘完全覆盖却仍在绘制
  ↓
Step 5: 修复 → 仪表盘区域加 clip: true → Draw Call 再减 40%
  ↓
Step 6: 真机复测 → gdbserver 远程连接 ARM 板（见 §14.5.1）→ heaptrack 确认内存无泄漏
  ↓
Done: 抖动消失，CPU 从 90% 降到 23%

# 14.6.4 知识串连

问题	涉及章节	诊断工具	优化手段
启动慢	第 2.7 章引擎加载	启动耗时分解	qmlcachegen + Splash + 静态链接
动画卡顿	第 8 章 GPU vs CPU	QSG_VISUALIZE	transform 替代 width/height
列表滑动掉帧	第 7 章模型视图	Profiler Binding 火焰图	C++ Model + reuseItems
内存泄漏	第 5.3/第 10 章	heaptrack	Image sourceSize + Loader 懒加载
崩溃无迹	第 14.5 章	core dump + gdb	开启 ulimit -c unlimited
双屏撕裂	第 13 章 EGLFS	dmesg + 驱动日志	FORCEVSYNC=1 + 匹配 eglfs backend
点击穿透	第 6 章事件系统	手动复现	mouse.accepted + FocusScope 隔离
绑定死亡	第 4 章绑定原理	打印 x.__qmlBinding	Qt.binding() 恢复

# 14.6.5 端到端排查剧本

最后，把全书知识压缩到现场排障四步法——当客户说"设备卡"时，这是标准响应流程：

客户反馈: "仪表盘用了一小时后开始卡，重启恢复"
────────────────────────────────────────────
▍Step 1: 量化"卡"的含义（不要被主观描述误导）

  $ adb shell  # 或 ssh root@192.168.1.100
  root@arm64:~# cat /proc/loadavg
  3.21 2.15 1.82          ← 1分钟负载 3.21（四核——不严重）

  root@arm64:~# grep -E "^Swap|^Mem" /proc/meminfo
  MemTotal: 2097152 kB
  MemAvailable: 184320 kB ← 可用只剩 184MB（危险——512MB 板子）

  root@arm64:~# pgrep myapp | xargs cat /proc/{}/status | grep VmRSS
  VmRSS: 421832 kB        ← 421MB / 512MB = 82%！接近 OOM 了

  结论: "卡"是内存吃紧导致的 swap，不是渲染问题
────────────────────────────────────────────
▍Step 2: 如果是内存问题→定位泄漏源

  root@arm64:~# heaptrack -p $(pidof myapp) -o /tmp/heap.gz &
  # 运行 10 分钟后 kill heaptrack → 拉到桌面分析

  heaptrack_gui /tmp/heap.gz:
  Top allocations (累计):
    38% → QQuickText::cacheImg() ← 文本缓存！（不正常）
    22% → QCanBusFrame::payload()
    12% → QImage::convertToFormat()

  探索: QQuickText 为什么占了 38%？
  → QML 中是否有 Text { text: realtimeValue.toFixed(6) } 在 60fps 更新？
  → 每次 text 变化 → QQuickText 重新光栅化 → 新 QImage 缓存 → 旧的不回收

  修复: Text { text: realtimeValue.toFixed(1) }  // 精度减到 1 位
         + Timer { interval: 200; onTriggered: updateDisplay() }
           // 降低更新频率——不需要每帧更新显示的文本
────────────────────────────────────────────
▍Step 3: 如果是帧率问题→perf + QSG 组合拳

  root@arm64:~# export QSG_RENDER_TIMING=1
  root@arm64:~# perf record -g -p $(pidof myapp) -- sleep 10
  root@arm64:~# perf report --stdio | head -20

  → 18% QSGBatchRenderer::renderBatches ← Draw Call
  → 12% V4::Moth::VME::interpret       ← Binding
  →  8% eglSwapBuffers                  ← VSync 等待（正常）

  root@arm64:~# export QSG_VISUALIZE=batches
  → 看到 120+ 个色块 ← Draw Call 过多

  交叉验证: Profiler Binding 时间线 → 点击展开
  → speedAngle 绑定被 8 个 Item 每帧重复求值 8 次

  修复: readonly property real angle: ... (只算一次)
        + 合并背景图层 (减少 batch)
        → Draw Call 120→6, FPS 42→60
────────────────────────────────────────────
▍Step 4: 如果是崩溃问题→core dump 三步曲

  ulimit -c unlimited
  echo "/var/crash/core.%e.%p" > /proc/sys/kernel/core_pattern
  # 等待崩溃...

  arm-linux-gnueabihf-gdb ./myapp /var/crash/core.myapp.1234
  (gdb) bt
  #0  QSGNode::parent() const (this=0x0)        ← 空指针
  #1  QQuickItem::updatePaintNode(...)
  #2  QSGRenderer::syncAndRender()

  (gdb) frame 1
  (gdb) print this->m_paintNode                  ← 未初始化
  (gdb) print this->m_componentComplete          ← false!
  → 根因: Component.onCompleted 之前调了 update()

  修复: updatePaintNode 入口加 if(!m_ready) return oldNode;

工具组合决策树：

设备"卡"
  ├─ 内存 RSS > 70% → heaptrack + QPixmapCache
  ├─ CPU 负载 > 2×核心数 → perf + QSG_RENDER_TIMING
  ├─ 帧率 < 30fps → QSG_VISUALIZE + Profiler
  ├─ 崩溃随机     → ulimit -c unlimited + gdb bt full
  └─ 一切正常但用户说卡 → QSG_VISUALIZE=changes（看脏区是否疯狂刷新）

# 14.7 新手陷阱

#	陷阱	说明	修复
1	`QSG_VISUALIZE=batches` 看到全是同色→以为没 bug	同色只说明同 batch——不代表 Draw Call 少	同时检查 `batches` 和 `overdraw`
2	Profiler 只在 x86 桌面上跑	桌面性能和 ARM 板完全不同	必须真机 Profiling（TCP 远程连接）
3	`qmlcachegen` 之后不改代码	改 QML 不重新运行 `qmlcachegen` → 缓存失效	构建脚本每次编译前自动运行
4	core dump 没开启→崩溃无迹可寻	`ulimit -c 0` 默认关闭	`ulimit -c unlimited` + 设置 core_pattern
5	heaptrack 结果只看峰值不看趋势	峰值 OK 但内存持续上涨 = 泄漏	看 heaptrack 的 "leaked" 标签

# 14.8 速查表

概念	一句话
qmlcachegen	QML 预编译——.qml → .qmlc 字节码，启动 +30~50%
QSG_VISUALIZE	Scene Graph 可视化——batches/overdraw/changes/clip
Qt Quick Profiler	火焰图时间线——Painting/Binding/JS 热点定位
heaptrack	内存画像——峰值/分配热点/泄漏检测
Valgrind	C++ 内存泄漏检测——definitely/indirectly lost
gdbserver	ARM 远程调试——TCP 2345，交叉 gdb 连接
core dump	崩溃快照——bt full 看调用栈 + 局部变量
qInstallMessageHandler	自定义全局日志——文件 + 串口双输出
systemd preload	系统启动时后台预读 Qt .so 到 page cache
sourceSize	Image 解码时缩放到目标尺寸——内存省 10-50×

核心哲学：

性能优化 = 测量 → 定位 → 修复 → 再测量。

QSG_VISUALIZE 是眼睛，Profiler 是显微镜，heaptrack 是 X 光，
gdbserver + core dump 是尸检报告。

没有工具的性能优化 = 猜谜。
有了工具 = 精准手术。

下一篇：返回 QML 入门总目录 (opens new window)

上次更新: 2026/07/12, 19:39:51

← 嵌入式渲染后端 QT核心库实践→