Файл qmlc что это
Я немного запутался по поводу компилятора qtquick, кеширования JIT qml и того, что доступно (а что нет) в версии qt 5.8 с открытым исходным кодом (соответственно 5.9).
По сути, я хочу защитить мои файлы .qml и .js от чтения в моей сборке релиза. Я запустил новый пример проекта QtQuick без редактирования какого-либо кода. Я следовал этим инструкциям и добавил CONFIG + = qtquickcompiler в файл .pro, но это не имеет никакого эффекта ,
Мои файлы .qml встроены в .exe (в Windows), но если посмотреть в исполняемом файле, например, с помощью notepad ++ я все еще вижу исходный код файлов .qml.
С другой стороны, если я не использую QRC для своих файлов .qml, файлы .qmlc создаются для каждого из моих .qml во время выполнения. Эти файлы не (легко?) Читаемые. Но я не нахожу способ использовать только файлы .qmlc без отправки файлов .qml в мою сборку (и я не думаю, что это должно было быть так).
Подходя к моему вопросу: есть ли способ защитить мои файлы .qml и .js с помощью версии qt с открытым исходным кодом? И в чем разница между компилятором qtquick и новым JIT .qmlc?
4 ответа
Нет, так и должно было быть, но потом они отказались от этих планов и заменили их кешированием.
Я не думаю, что вы сможете повторно использовать .qmlc файлы на другом компьютере, так как IIRC они не переносимы архитектурой.
В будущем должна быть возможность предварительно скомпилировать .qml в .qmlc заранее и объединить их в двоичный файл приложения.
Если ваши файлы находятся в файловой системе, то нет способа защитить их от чтения, обратный инжиниринг или подделан.
С помощью компилятора код QML преобразуется в код C ++, который затем компилируется в собственный двоичный файл. Кроме того, в прошлый раз, когда я проверял, если вы идете за компилятором, это «или / или» ситуация, если вы используете скомпилированный qml, вы можете использовать только скомпилированный qml, поэтому не смешивайте с обычными файлами qml. Это также заранее, и требует коммерческой лицензии.
В отличие от этого, кэширование qml выполняется точно вовремя (возможно, в будущем раньше), не требует коммерческой лицензии и не имеет ограничений, которые не позволяют использовать обычные файлы qml. Я не знаю деталей реализации, но это, конечно, не код qml, переведенный на C ++ и затем скомпилированный, как это происходит на стороне клиента и не требует наличия установленного компилятора Qt или даже C ++. На самом деле это не похоже на байт-код, так как IIRC не двоично совместим между платформами, это больше похоже на кэширование результата обработки файла qml, чтобы не делать это каждый раз.
Как указано в этом ответе, при некоторой дополнительной работе может оказаться возможным реализовать приличный уровень защиты, например зашифрованный QML файлы или бинарные ресурсы, но я до сих пор не копался в этом.
Наконец, если вы установите сжатие для файла qrc с низким порогом, это несколько запутает код QML в исполняемом двоичном файле, но даже в этом случае это обычное сжатие zip, поэтому, если ваш код действительно стоит украсть, он не будет предотвратить это, просто сделайте это немного менее тривиальным.
Обновленный ответ: Начиная с Qt 5.11, быстрый компилятор qt также доступен в версии с открытым исходным кодом:
я, конечно, понимаю, вопрос ламерский и глупый. но честно, понятия не имею, что это за файлы, для чего нужны и как появились (предположительно появились после установки игры Сегун2 Тотальная Война, но не уверен)
это дата-диск (не системный), соответственно на нем таких файлов быть не должно. хочу удалить их, но не знаю не испорчу ли чего
А зачем было в корень диска что-либо вообще устанавливать? А то это не вопрос ламерский, а действия изначально. Почему бы не в папочку отдельную для каждой софтинки утанавливать, как все нормальные люди?
Добавлено через 53 секунды
FeyFre
Оно их в корень диска само НЕ распаковывает при установке, это можно только вручную сделать
ПУК - Последняя Удачная Конфигурация.
(с) veroni4ka Штандартенфюрер СС, это баг инсталлятора vcredist_x86_2008.exe! Инсталлятор самораспаковывается не во временную папку, а куда-нибудь а пальцем мимо. Там очередной какой-нибудь багнутый SFX-ZIP, который должен был распаковать во временную папку пакет Windows Installer, и пнуть его. Между прочим, этот пакет при установке какраз и не спрашивает куда устанавливаться, ибо выбора всё-равно нет - только в WinSxS да и всё тут. Мелкомягки позже исправили это, но было уже поздно.
Так что не нужно человека учить зря, он никакими своими действиями не смог повлиять на это. (Не каждый юзер является нахватавшимся знаний что-бы заставить компоненты винды плясать под свою дудку).
Вот список файлов которые оно могло оставить и которые можно спокойно тереть.
ПУК - Последняя Удачная Конфигурация.
(с) veroni4ka Штандартенфюрер СС, да, Мелкомягкие баги иногда исправляют(о чудо!). У меня тоже ЭТО уже ложится в подобные директории(и тоже не затираются иногда), ибо я всё-таки нашел нормальный установщик.
Штандартенфюрер СС
всегда указываю пути куда что распаковать или установить. оно само так сделалось
Руководство по оптимизации производительности QML Profiler
Оптимизация производительности - важный шаг в разработке программы.
Мы определенно не хотим, чтобы разработанная программа показывала лаги, лучше, чтобы везде было гладко, шелковисто.
Для программ на C ++ у нас есть много способов оптимизировать производительность, например Visual Studio Profiler.
Для программ QML (QtQuick) мы можем выбрать QML Profiler, который является функцией QtCreator.
Итак, что такое QML Profiler, официальное описание выглядит следующим образом:
You can use the QML Profiler to find causes for typical performance problems in your applications, such as slowness and unresponsive, stuttering user interfaces. Typical causes include executing too much JavaScript in too few frames. All JavaScript must return before the GUI thread can proceed, and frames are delayed or dropped if the GUI thread is not ready.
Другими словами, основная функция QML Profiler - помогать нам решать типичные проблемы производительности в программе, проще говоря, помогает нам оптимизировать производительность.
Примечание: Эта оптимизация производительности здесь относится только к QML. Вообще говоря, это интерфейс. Он также может содержать некоторый код логики интерфейса (JS). Для C ++ профилировщик QML вряд ли может помочь. В большинстве случаев его можно использовать в слоте который может быть вызван в QML.Функция отнимает много времени.
Соображения времени
Как разработчик программы, вы должны стремиться поддерживать частоту обновления механизма рендеринга на уровне 60 кадров в секунду, что означает, что между каждым кадром есть около 16 мсек. Этот период времени включает отрисовку базовых примитивов на графическом оборудовании. Конкретное содержание выглядит следующим образом:
- По возможности используйте асинхронное программирование, управляемое событиями.
- Используйте рабочие потоки для обработки важных вещей.Например, QML типа WorkerScript запускает новый поток.
- Не повторяйте цикл событий вручную.
- Время выполнения функционального блока на кадр не должно превышать нескольких миллисекунд.
++ Если вы не обращаете внимания на упомянутый выше контент, это приведет к пропуску кадров и повлияет на взаимодействие с пользователем. ++
Примечание:
Анализ производительности
С помощью QML Profiler мы быстро понимаем основные условия и трудоемкие детали работы программы (с точностью до микросекунд), включая, помимо прочего:
Как использовать инструменты анализа производительности QML
Открытие функций QML Profiler началось с Qt 5.7, и раньше оно было доступно только в корпоративной версии, то есть в экономичной версии.
Шаги по использованию
- Откройте Qt Creator
Qt5.7 или выше устанавливается по умолчанию. - Откройте проект QML
Выберите режим отладки:
После запуска инструмента подождите, пока программа запустится, и поработайте некоторое время. затем щелкнитеStopКнопка для остановки QML Profiler.
Просмотр временной шкалы
Здесь мы можем просмотреть затраты времени на каждую деталь с точки зрения временной оси. Начальной точкой временной шкалы является время создания экземпляра QQmlApplication. Мы можем не увидеть нулевую точку, потому что при создании экземпляра QQmlApplication до обработки первого элемента может потребоваться другое время.
В представлении слева направо находятся все записи QML Profiler от начала до конца. Чем меньше блок, тем короче время, а чем больше блок, тем больше время. Блоки здесь имеют определенную взаимосвязь вложенности, а объекты блоков ниже принадлежат объектам выше. Например, Windows <> может также иметь вложенные отношения, такие как Item <>.
- Просмотр подробной информации
Щелкните цветовую область левой кнопкой мыши, чтобы просмотреть подробную информацию, а именно:
Взгляните на следующий пример:
Мы видим, что время создания изображения занимает 78,7 мс, а соответствующий файл кода - main.qml с 37 строками.
- Развернуть по типу события
В различных типах событий слева мы можем нажать кнопку "Развернуть", чтобы увидеть развернутые подробные данные и более четко увидеть соответствие данных, но когда Когда данных много, они будут более беспорядочными, поэтому используйте их по мере необходимости.
- Кнопка масштабирования
С левой стороны есть увеличительное стекло, с помощью которого можно увеличивать масштаб представления. Это очень полезно для анализа длинного профилировщика QML или для просмотра данных определенной точки деталь.
Изображение, используемое в QML, по умолчанию кэшируется. Здесь будут отображаться все кэшированные изображения, включая количество пикселей, используемых в кеше, а также такую информацию, как время, затраченное на загрузку изображения, и имя файла. (Изображения, которые не кэшируются, также будут отображаться, но не будут записаны в лестничной диаграмме кеша)
Это показывает затраты времени на каждый этап рендеринга. Если мы обнаружим, что анимация программы зависает, в дополнение к зависанию, вызванному блокировкой некоторых функций, мы также можем проанализировать трудоемкие затраты на рендеринг, чтобы увидеть, объем рендеринга слишком велик. Вызвано заикание.
Здесь мы в основном сосредотачиваемся на данных рендеринга рендеринга, которые представляют процесс отправки данных OpenGL в графический процессор. Видеть конец рендеринга Рендеринг в основном означает, что фрейм закончил рендеринг и скоро будет отображаться.
Кроме того, есть данные Glyph Upload, которые представляют собой загрузку шаблона глифов. Если ваша программа встроена и содержит много символов, загрузка Glyph может снизить производительность. Способ уменьшить эти накладные расходы состоит в основном в сокращении количества слов, например замене текста (текста или метки) изображениями (изображение).
Отобразите использование памяти.Если наблюдается большой рост памяти, проверьте, много ли здесь инициализируется или создано много ненужных компонентов.
Отображение событий пользовательского ввода, таких как события мыши и клавиатуры
Покажите момент времени вывода отладки, если вам нужно сравнить вывод отладки и соответствующее событие QML, тогда это будет очень полезно
Показывает, выполняется ли анимация, и FPS анимации. Многопоточная информация также будет отображаться во время многопоточного рендеринга. Если мы обнаружим, что FPS ниже 18, возможно заметное зависание изображения. FPS от 30 до 60 в целом можно считать плавным.
Показывает время, необходимое для компиляции. Я хочу поговорить об этом здесь. Начиная с Qt5.8, QtQuick представил механизм qmlc, который значительно сократил время компиляции, в основном с нескольких сотен миллисекунд до десятков или даже десяти миллисекунд. Я уже опубликовал статью о csdn, чтобы поговорить об этом раньше, и я помещу ссылку здесь:
Время создания дисплея, как правило, также является основной частью оптимизации запуска.
Отображение времени привязки
Отображение времени обработки сигнала
Покажите, сколько времени занимает выполнение JS. Если слот C ++ вызывается в QML, тогда также будет время, но только общее время, затраченное функцией слота, и текущий статус C ++ здесь не отображается.
Просмотр диаграммы
Выберите вкладку «Статистика» следующим образом:
Здесь мы можем видеть каждую деталь, такую как количество компиляций, созданий, привязок, JavaScript или обработки сигналов, а также время, которое они потребляют.
В дополнение к временной шкале, с помощью визуального наблюдения, здесь мы можем быстро увидеть, что занимает больше всего времени, отсортировав проценты.
Просмотр пламени
Выберите вкладку «График пламени».
Здесь мы можем увидеть более краткую статистику QML и JS. Что также интуитивно подсказывает нам некоторые отношения вложенности.
Таким образом, это три основные функциональные области, составляющие QML Profiler. Анализ производительности нашей программы в основном вращается вокруг этих трех пунктов.
Рекомендации по оптимизации производительности
Если у программы есть очевидные проблемы с медленной загрузкой, вы можете сначала посмотреть создание, найти большой блок, отложить загрузку или загрузить его асинхронно. Пусть первым отобразится первый интерфейс. Особенно для картинок загрузка картинок идет относительно медленно, постарайтесь выбрать картинку с подходящим разрешением и не слишком большую. Для вещей, которые не будут отображаться в первый раз, постарайтесь не загружать их в первый раз.
Если у программы есть очевидные проблемы с задержкой, вы можете увидеть, не слишком ли много рендеринга, например, слишком много клипов. Или есть много визуально невидимых элементов, таких как Items с xy, равным -1000, которые не скрыты. Эти элементы все равно будут отображаться, и по-прежнему будут накладные расходы на производительность. Для этих элементов вы можете установить для видимых значение false и скрыть их напрямую. Это не займет много времени на рендеринг. Исключением является то, что для сцен с анимацией рекомендуется контролировать время каждого кадра в пределах 16 мс, чтобы поддерживать плавный интерфейс на уровне 60 кадров в секунду.
Что касается дальнейших подробностей оптимизации производительности, я не буду здесь распространяться, я опубликую отдельную статью позже.В этой статье рассказывается только об основах QML Profiler. Для получения дополнительной информации о QML Profiler вы можете перейти на официальный сайт, чтобы просмотреть:
Добрый день, все никак не пойму. Как профит от этого QML, что в нем можно сделать такого, что нельзя сделать в Qt. Интерфейсы, сигналы, слоты. Может я что-то очень важное не понимаю? Подскажите пожалуйста, не знаю, изучать мне QML или нет, может действительно там что-то скрыто такое?
Почему так не было сделано изначально — загадка. Возможно Nokia хотела снизить порог вхождения в разработку мобильных приложений, разбавив C++ с помощью JavaScript'а.
кдешники как раз пилят попытку совместить qml с обычными виджетами
Или у KDE'шников имеется собственное решение?
Пример из моего кода:
Есть список. В списке есть возможность мультивыбора. onClicked вызывается при нажатии на элемент списка. Если открыта панель мультивыбора, у элемента переключается состояние выбран/не выбран. Если панель закрыта, происходит переход на экран со свойствами элемента. Как это сделать без использования JS?Не понял, что такое панель мультивыбора.
Нет. Это я в виду и имел - я почему то думал что KDAB связан с кедами - по первой букве же. Ну и новость эту я на planetkde прочитал.
Это не избавляет от JS. Там используется тот же QML, только вместо виджетов Qt Quick и Qt Quick Controls используются виджеты Qt Widgets. Связи между ними все так же пишутся на JS.
Это мобильный интерфейс. При долгом нажатии на элемент списка снизу выезжает панель с числом выбранных элементов и при нажатии на элементы переключается их статус выбора, вместо перехода на следующий экран. Для реализации этого нужно добавить дополнительною логику в обработчик onClicked у элемента списка.
Про мобильные ничего не скажу, я тока для десктопа его использовал.
Кдешники пилят стиль для Qt Quick Controls 2, который использует QStyle для отрисовки и мимикрирует под Qt Widgets.
Виджеты не тормозят.
Неважно, десктоп или нет. Если программа достаточно сложная, то при разработке появляется море ситуаций, когда нужно при определенном действии изменить состояние других QML-объектов, и это сложно сделать с помощью property bindings или states. В таком случае приходится использовать логику на JS. Загляни хотя бы в код той же плазмы - практически в каждом QML-файле есть логика на JS, где-то в несколько строк, где-то больше. От этого никуда не деться.
Я понимаю, что сейчас это не избавит от JavaScript. Но это хотя бы даст нормальную связку существующих технологий.
Как было сказано выше, когда ещё QML только-только зарождался, они могли сделать этот DSL с помощью кодогенерации на стороне moc или похожей утилиты и весь QML был бы по типу Vala с минимальным оверхедом.
Сейчас же в стране QtQuick царит какой-то беспорядок: одни системные GUI-контролы чего стоят. Вместо того, чтобы допилить, их просто выбрасывают и пилят заново новые. Уже третий или четвёртый набор так.
А логика тормозит. Особенно, если интерфейс с ней в одном потоке. Это я тебе как пользователь mutt говорю.
Последнее исправление: kirk_johnson 25.05.18 20:49:41 (всего исправлений: 1)
Если достаточно сложная, то да. Но если там действительно несколько строк, то и насрать.
Стилями то не обойтись - контролы очень много чего не умеют. Те же таблицы, простые и тривью и так далее. Да и лейауты виджетные мне куда милее - в них есть стречинг (не помню так ли назвал - короче коэффициенты растяжения при ресайзе)
И кто мешает вынести логику?
KDAB сильно связан с Qt, т.к. это серьёзная компания у которой большая часть бизнеса зависит от этого фреймворка.
Кажется они самые активные коммитеры в Qt, чуть ли не опережают саму The Qt Company. Ну и конечно они выступают на всяких Qt/KDE тусовках от лица своей компании. Но называть их KDE'шниками вряд ли правильно.
Ещё KDAB замутили крутое средство интроспекции Qt- и QML-приложений — GammaRay, много раз выручал.
P.S. А planetkde просто ретранслирует всю около Qt-движуху (точнее репостит с planetqt).
EXL ★★★★★ ( 25.05.18 20:53:24 )Последнее исправление: EXL 25.05.18 21:02:03 (всего исправлений: 1)
Это уже о другом разговор. Мы с тобой говорили о том, что qml тормозит. Однако мы только что выяснили, что дело может быть не только в нем.
Как это сделать без использования JS?
Это-то понятно. Проблема в том, что в обработчике onClicked мне нужен доступ к другим QML-объектам. Если я хочу чтобы он был полностью на C++, мне придётся писать кучу лапши, т.к. доступ к QML- объектам из C++ (а не наоборот) реализован очень неудобно, именно потому, что в QML такие ситуации by design принято разруливать с помощью JS.
Однако мы только что выяснили, что дело может быть не только в нем.
Хватит разговаривать с голосами в голове. Тормозит QML. ТЧК.
Хватит разговаривать с голосами в голове. Тормозит QML. ТЧК.
Пруфы, Билли, нам нужны пруфы!
Если из QML кода постоянно выносить логику в кресты, то от QML остаётся лишь одна декларативщина. Но если нам нужна только декларативщина, то зачем нам тяжёлый QML, который в своём нутре использует V4 JavaScript Engine? А раз нам такое не нужно, то почему QML получился таким, а не простым декларативным DSL, который бы отдельная утилита разворачивала в компактный C++-класс со всеми заданными свойствами и условиями, как это делает тот же uic только в упрощённой форме и GUI only? QML ведь как ни крути, всё равно строится поверх C++/Qt API в своих модулях.
Проблема в том, то QML позиционируется разработчиками Qt как инструмент для написания любых интерфейсов, т.е. любой сложности. А в сложных интерфейсах (да дело даже не в сложности самого интерфейса, а в логике, т.е. действиях, которые происходят при взаимодействии с ним) без логики на JS не обойтись, потому что UI-элементы тоже должны взаимодействовать между собой, и часто это должно описываться достаточно сложной логикой, для которой простых property bindings и states недостаточно. Для этого в QML и сделали встроенную поддержку JS. Т.е. утверждение, что в QML интерфейс полностью отделен от логики - миф. На деле он отделен только от бекэндовой логики, которая пишется на C++ или другом ЯП. Логика же самого интерфейса пишется на JS.
Логика же самого интерфейса пишется на JS.
Я не говорю, что интерфейс пишется на JS. Логика взаимодейтсвия между UI-элементами пишется на JS.
Я не говорю, что интерфейс пишется на JS. Логика взаимодейтсвия между UI-элементами пишется на JS.
Окей, да, согласен.
А логика тормозит (c)
При этом до сих пор нет стабильно поддерживаемых контроллов из коробки и все костыляют свои собственные. Сколько там всяких наборов было за один только Qt 5 было анонсировано?
Компилер у него давно. Просто в платной версии :)
uic по сути решает другие задачи, нежели QML. Он позволяет поределить иерархию, расположение контролов относительно друг друга, их внешний вид и т.п. Но он не позволяет определить логику взаимодействия контролов друг с другом - а это тоже немалая часть создания интерфейса. Эту логику приходилось писать на C++. А разработчики QML хотели упростить написание интерфейсной логики, перевести ее на другой язык, чтобы интерфейсы могли писать и те, кто плохо знает C++. В случае варианта с кодогенерацией всю эту логику пришлось бы транслировать в C++, что создало бы дополнительные сложности. А JS многим знаком, и для внутриQMLной логики решено было использовать именно его. Т.е. интерфейс мы пишем на QML + JS, а бэкенд на C++.
А насчет тормозов - я такого не заметил (если все делать грамотно). Основные претензии у к QML у меня это JS (можно было бы использовать более строгий язык, хоть даже свой собственный) и непригодность Qt Quick для написания десктопных интерфейсов.
Последнее исправление: equeim 25.05.18 21:52:14 (всего исправлений: 2)
Компилер у него давно. Просто в платной версии :)
На одном стуле JIT прогретый, на другом мы пришли к компиляции в С++ но с оверхедом.
EXL ★★★★★ ( 25.05.18 21:52:39 )Последнее исправление: EXL 25.05.18 21:52:47 (всего исправлений: 1)
На одном стуле JIT прогретый, на другом мы пришли к компиляции в С++ но с оверхедом.
Не, компилер в байткод. Не в C++ :D
Я так и не понял, зачем оно теперь, когда qml при первом запуске кешируется тебе в
/.cache. Видимо шоп поменьше мусорить.
Последнее исправление: kirk_johnson 25.05.18 21:54:36 (всего исправлений: 2)
можно было бы использовать более строгий язык, хоть даже свой собственный
Я считаю, что кодогенерация туда и просится. И язык можно было бы строгий сделать, посмотри на ту же Vala, которая что-то примерное делает. Это было бы логично, ведь весь этот QML всё равно просто абстракция поверх С++ API. Если QML-элементы превращаются в обычные C++-классы, то почему ниточка, которая их всех соединяет, является JavaScript'ом с оверхедом на динамическую типизацию и пр.?
разработчики QML хотели упростить написание интерфейсной логики . а JS многим знаком
Т.е. интерфейс мы пишем на QML + JS, а бэкенд на C++.
Если было бы так гладко. Но в итоге человеку, пишущему на QML всё равно нужно знать С++, потому что рано или поздно с ним придётся столкнуться.
uic по сути решает другие задачи, нежели QML. Он позволяет поределить иерархию, расположение контролов относительно друг друга, их внешний вид и т.п. Но он не позволяет определить логику взаимодействия контролов друг с другом
Это ты рассуждаешь в контексте сегодняшней ситуации с QtWidgets (кстати uic позволяет прокидывать и кастомные классы, что весьма полезно). Но если представить улучшенный uic, который читает не XML'ку, а декларативный и строгий DSL с логикой и затем транслирует его в C++, оставляя ниточки для тех кто занимается backend'ом, то вырисовывается куда более стройная концепция QtQuick. Чёрт возьми, её зачатки уже и так есть, взять хотя бы названия слотов вида void on_ИМЯОБЪЕКТА_СИГНАЛ() , которые автоматически разрешаются без задания слота/сигнала.
непригодность Qt Quick для написания десктопных интерфейсов.
В чём именно это заключается? Вот если рассматривать сам язык QML, его синтаксис, то он очень удобен для написания интерфейсов любой сложности. Это если смотреть в отрыве от реализации.
Как это сделать без использования JS?
выкинуть неочевидный UI и сделать как у нормальных людей?
аа, беру свои слова обратно. на мобилках нормального интерфейса я ни разу не видел
Читайте также: