Производительность QML: профилирование, частые ошибки, оптимизация рендеринга

Введение

Привязки (статья 481), анимации (статья 487) и системы частиц (статья 493) — все они потребляют вычислительные ресурсы, и в этой статье разберём, как профилировать QML-приложения (продолжая тему профилирования основного цикла статей) и какие типичные ошибки чаще всего приводят к снижению производительности интерфейса.

Концепция

QML Profiler (входящий в состав Qt Creator) показывает детальную картину выполнения QML-приложения во времени — время вычисления отдельных привязок, частоту срабатывания обработчиков сигналов, и кадровую частоту рендеринга сцены — это даёт объективную основу для выявления конкретных, измеренных узких мест вместо предположений о том, что именно вызывает замедление. Наиболее типичные причины снижения производительности QML включают избыточно сложные или часто пересчитываемые привязки (статья 481), создание чрезмерного количества визуальных объектов одновременно (статьи 484, 488 — упущенная виртуализация), и неоптимальное использование изображений (избыточное разрешение, отсутствие кеширования декодированных изображений).

Пример кода: Производительность QML

// Демонстрация дорогой, часто пересчитываемой привязки — антипаттерн
Item {
    property real mouseX: 0
    property real mouseY: 0

    MouseArea {
        anchors.fill: parent
        onPositionChanged: function(mouse) { mouseX = mouse.x; mouseY = mouse.y }
    }

    // ПЛОХО — сложное, дорогое вычисление пересчитывается при КАЖДОМ движении мыши
    Text {
        text: expensiveCalculation(mouseX, mouseY) // вызывается очень часто при движении мыши

        function expensiveCalculation(x, y) {
            let result = 0
            for (let i = 0; i < 100000; i++) { result += Math.sin(x * i) * Math.cos(y * i) }
            return result.toFixed(2)
        }
    }
}

// Оптимизация — троттлинг частоты пересчёта через Timer вместо прямой привязки к часто меняющемуся значению
Item {
    property real mouseX: 0
    property real mouseY: 0

    MouseArea {
        anchors.fill: parent
        onPositionChanged: function(mouse) { mouseX = mouse.x; mouseY = mouse.y }
    }

    Timer {
        interval: 100 // пересчёт максимум 10 раз в секунду, а не при каждом микро-движении мыши
        running: true; repeat: true
        onTriggered: resultText.text = expensiveCalculation(mouseX, mouseY)
    }

    Text { id: resultText }
}

// Кеширование декодированного растрового представления для сложных, статичных визуальных элементов
Item {
    layer.enabled: true  // элемент рендерится в текстуру один раз и переиспользуется
    layer.smooth: true   // вместо повторной перерисовки всех вложенных элементов при каждом кадре

    Column {
        // Множество сложных, но РЕДКО изменяющихся визуальных элементов
        Repeater { model: 50; delegate: Text { text: "Статичный элемент " + index } }
    }
}

Пояснения к коду

Первый пример показывает классический антипаттерн — привязка text: expensiveCalculation(mouseX, mouseY) пересчитывается при каждом изменении mouseX/mouseY, что для движения мыши означает десятки или сотни пересчётов дорогой функции в секунду, заметно нагружая основной поток приложения. Версия с Timer показывает практичное решение — троттлинг (искусственное ограничение частоты) пересчёта через таймер с фиксированным интервалом, что снижает фактическую частоту дорогих вычислений до приемлемого уровня (10 раз в секунду в примере), достаточного для визуального восприятия, но значительно более экономного по ресурсам по сравнению с пересчётом при каждом, даже самом незначительном движении мыши. layer.enabled: true показывает технику кеширования рендеринга — элемент с этим свойством рендерится в отдельную текстуру один раз, и эта текстура переиспользуется для последующих кадров без необходимости заново перерисовывать все вложенные, сложные дочерние элементы, что особенно выгодно для статичных или редко изменяющихся, но визуально сложных частей интерфейса.

Подводные камни

Профилирование производительности только в среде разработки (Qt Creator на мощном десктопе), без проверки реального поведения на целевом, часто менее производительном оборудовании (мобильные устройства, embedded-платформы) — производительность, кажущаяся приемлемой на мощной разработческой машине, может оказаться неприемлемой на реальном целевом устройстве, и финальная проверка производительности должна выполняться именно на представительном для конечных пользователей оборудовании, а не только в среде разработки.
Применение layer.enabled: true к часто, динамически изменяющимся элементам — кеширование в текстуру выгодно именно для статичных или редко меняющихся элементов, и применение этой техники к элементу, чьё визуальное содержимое часто меняется, приводит к повторному, частому перерендериванию кешированной текстуры при каждом изменении, что может оказаться даже менее эффективным, чем обычный, не кешированный рендеринг, из-за дополнительных накладных расходов на управление этой текстурой.
Игнорирование разрешения загружаемых изображений относительно их реального отображаемого размера — загрузка изображения существенно большего разрешения, чем требуется для его реального отображаемого размера на экране (без явного указания sourceSize для уменьшения изображения при декодировании), тратит избыточную память и время декодирования на детализацию, которая физически не может быть видна при уменьшенном отображении изображения.
Преждевременная, не основанная на реальном профилировании оптимизация производительности, добавляющая сложность кода (троттлинг, кеширование рендеринга) для частей интерфейса, не являющихся реальным узким местом производительности согласно объективным измерениям — аналогично общему принципу профилирования из основного цикла статей, оптимизация должна следовать за объективными данными профилировщика о реальных узких местах, а не интуитивными предположениями о том, что «вероятно» медленно, что может привести к усложнению кода без реального улучшения воспринимаемой производительности там, где это действительно важно.