Marcus Voß
Hendrik Timmermann

Geschätzte Lesezeit 12 Minuten

Techblog

Duell der Giganten: Ein Vergleich zwischen Qt und Flutter

Die Entwicklung von Benutzeroberflächen hat in den letzten Jahren einen rasanten Fortschritt durchlebt. Zwei herausragende Frameworks stehen im Mittelpunkt dieser Revolution: QT und Flutter. In diesem Artikel werfen wir einen genauen Blick darauf, welche dieser beiden Frameworks die Nase vorn hat und ob Flutter als Alternative zu QT im Embedded-Bereich taugt.

Was sind QT und Flutter?

QT und Flutter sind Frameworks zur plattformunabhängigen Entwicklung von modernen Benutzeroberflächen. QT wurde in den frühen 90ern von den Norwegern Eirik Chambe-Eng und Haavard Nord für Desktop-Anwendungen entwickelt. Flutter erschien erst 2018 und hat sich seitdem eine riesige Fanbase aufgebaut, unter anderem weil es sich gut für die Entwicklung von plattformübergreifenden Mobil-Apps eignet. Im Zusammenhang mit Embedded-Systemen wird derzeit jedoch selten Flutter verwendet, sondern eher QT.

QT und Flutter: ein Vergleich

QT wird schon seit langem bei der Entwicklung von Embedded-Systemen eingesetzt und hat sich in diesem Kontext als äußerst robustes und zuverlässiges Framework erwiesen. Aus diesem Grund ist es häufig die erste Wahl und hat sich sozusagen als „Standard-Framework“ etabliert, auf das man gerne zurückgreift. QT bietet eine breite Palette an Funktionen und vordefinierten Bibliotheken, was die Entwicklung komplexer Benutzeroberflächen (UIs) erleichtert.

Trotz dieser Stärken sollten bei der Entscheidung für QT einige Faktoren berücksichtigt werden -insbesondere im Hinblick auf das Lizenzmodell. Obwohl es eine Open-Source-Version gibt, erfordert die Nutzung in Embedded-Applikationen oft den Erwerb einer kommerziellen Lizenz. Das kann in bestimmten Projekten eine finanzielle Hürde darstellen. Darüber hinaus ist die Entwicklung von QT-Applikationen in C++ oder QML komplexer als man es heutzutage von moderneren Programmiersprachen oder aus dem Webbereich kennt.

Lizensierung

  • Dual Licensing (Kommerziell, LGPLv3, GPL2, GPL3)
  • Keine Vermischung von Open-Source-Lizensierten QT-Projekten und kommerziell lizensierten QT-Projekten
  • Open-Source Lizenz nur möglich auf embedded Linux nicht auf Mikrokontrollern
  • Professional oder Enterprise Lizenz je nach Einsatzszenario

Unterstütze Plattformen

  • Mikrocontroller (nur mit kommerzieller Lizenz)
  • Windows, Linux, MacOS, Embedded Linux (32 und 64 Bit, Open Source / Kommerziell)

Kosten

  • Kosten pro Device
  • Kosten pro Entwicklungslizenz

Flutter scheint eine attraktive Alternative sein. Es ermöglicht die Entwicklung reaktionsschneller und ästhetisch ansprechender UIs und ist besonders für Projekte geeignet, die schnelle Entwicklungszyklen und Flexibilität erfordern. Zum Beispiel beschleunigt das Hot-Reload Feature von Flutter den Entwicklungsprozess erheblich, da es Änderungen am Code in Echtzeit sichtbar macht. Hinzu kommt, dass Flutter unter der BSD-Lizenz steht, was eine kostenlose Nutzung auch in kommerziellen Closed-Source Projekten ermöglicht.

Lizensierung

  • Flutter steht unter der offenen BSD-Lizenz

Unterstütze Plattformen

  • Android, iOS
  • Windows, MacOS, Linux (offiziell nur 64bit)
  • Web
  • Embedded (wip/beta/experimentell)

Kosten

  • Die Verwendung von Flutter ist kostenfrei

Flutter ist ein von Google entwickeltes Framework und mit über 2 Mio. aktiven Usern eines der meistgenutzten weltweit für die Cross-Plattform-Entwicklung. Obwohl es traditionell weniger im Embedded-Bereich genutzt wurde, zeigen vereinzelte Unternehmen wie Toyota, dass auch in diesem Kontext Potenzial besteht.

Der Automobilhersteller setzte erfolgreich Flutter’s Embedder API ein, um seine Linux-basierten Infotainmentsysteme zu verbessern und profitierte dabei von Flutter’s effizienter Entwicklungsumgebung sowie der Möglichkeit, plattformübergreifende Anwendungen mit einer einheitlichen Codebasis zu erstellen (hier mehr dazu).
Aus diesem Grund haben wir uns dazu entschlossen die beiden Frameworks zu vergleichen, um zu untersuchen, inwieweit Flutter aktuell als Alternative zu QT im Embedded-Bereich geeignet ist.

Auf diesen Plattformen vergleichen wir QT und Flutter

Für unseren Vergleich haben wir uns bewusst dazu entschieden, zwei verschiedene Testplattformen herzunehmen. Eine repräsentiert das Best-Case-Szenario und dient als Referenzplattform. Die andere stellt eine realistische Plattform dar, die von den Anforderungen und der Performance her eher der gängigen Hardware in der Praxis entspricht. Beide Plattformen verfügen über einen kapazitiven Touchscreen mit 800×480 Pixeln.

Die Best-Case Referenz stellt der gerade neu erschiene Raspberry Pi 5 dar. Als Betriebssystem verwenden wir die neueste Version des Raspberry Pi OS, die auf der 64-Bit-Version von Debian bookworm basiert. Anschließend muss noch mit apt-get QT5 sowie Flutter installiert werden.

Als realitätsnähere Plattform diente ein STM32MP157F-DK2. Im Gegensatz zum Raspberry Pi, für den ein vorgefertigtes Linux-Image als Basis dient, haben wir für den STM32 einen anderen Weg eingeschlagen. Mittels Yocto haben wir ein eigenes, angepasstes Linux-Image erstellt. Yocto ist ein Open-Source-Projekt für die Erstellung eigener Linux-Distributionen für Embedded-Systeme. Dieses Image enthält in unserem Fall alle notwendigen Abhängigkeiten und Pakete für QT und Flutter.

MerkmalRaspberry Pi 5STM32MP15F-DK2
CPU64-bit Broadcom BCM271232-bit Dual-Core Cortex-A7 + Cortex M4
CPU-Kerne4 Kerne2 Kerne
CPU-Taktfrequenz2.4 GHz 800 MHz800 MHz + 209 MHz (M4)
Arbeitsspeicher8 GB DDR4512 MB DDR3L
GPUVideoCore VIIVivante GCNano
GrafikunterstützungOpenGL ES3.1, Vulkan 1.2OpenGL ES2.0
BetriebssystemRaspberry Pi OS (64-bit Debian bookworm)OpenSTLinux (Yocto)
SoftwareinstallationMittels apt-getVorinstalliert im Linux Image
BildschirmKapazitiver Touchscreen, 800×480 PixelKapazitiver Touchscreen, 800×480 Pixel

Performance: So funktioniert unsere Test-Applikation

Um die Benutzerfreundlichkeit und Performance von QT und Flutter zu vergleichen, haben wir in beiden Frameworks eine Testapplikation geschrieben. Diese simuliert ein einfaches App-Menü, vergleichbar mit einem Touchscreen-Interface, das man etwa von modernen Kaffeemaschinen kennt.

Um die Benutzerfreundlichkeit und Performance von QT und Flutter zu vergleichen, haben wir in beiden Frameworks eine Testapplikation geschrieben. Diese simuliert ein einfaches App-Menü, vergleichbar mit einem Touchscreen-Interface, das man etwa von modernen Kaffeemaschinen kennt.

Die Flutter-Version haben wir mithilfe von Dart entwickelt – einer modernen, objektorientierten Programmiersprache, die von Google speziell für das Framework konzipiert wurde. Mit der Hot-Reload-Funktion können Entwickler Codeänderungen vornehmen und sie sofort in der laufenden Anwendung sehen, was den Entwicklungsprozess beschleunigt. Dies ermöglicht, eine schnellere Überprüfung und Anpassung von Änderungen ohne zeitraubende Neustarts oder Wartezeiten. Bei QT ist dies offiziell nur über kostenpflichtige Lizenzen möglich.

Auch das eigentliche Entwickeln mit Dart ist unkompliziert. Dank der vielfältigen packages, die von offiziellen und Community-Entwicklern zur Verfügung gestellt werden, sind viele Features einfach zu integrieren. Dabei sind jedoch die unterschiedlichen Lizenzen der packages zu beachten. Diese sind zwar hauptsächlich Open Source, können aber mehr oder weniger restriktive Lizenzmodelle verwenden. Auch die Aktualität der Community-packages muss beachtet werden. Die Flutter-App wird im Zuge dieser Tests mittels flutter-pi, einem Flutter-Engine Embedder, generiert und ausgeführt (Flutter pi Github).

Die User Experience im Test

Aber nicht nur die Performance muss stimmen, sondern auch die User Experience. Hier spielen insbesondere die Reaktionsgeschwindigkeit und die flüssige Bedienung der UI eine wichtige Rolle. Um dies zu beurteilen, haben wir mehrere kleine Testanwendungen entwickelt, mit denen häufig genutzte Funktionen überprüft werden können:

  • Multitouch-Test: Diese App visualisiert jeden erkannten Berührungspunkt, um ein direktes Feedback über die Verzögerung zwischen der tatsächlichen Berührung und dem erkannten Touch-Event zu geben. Für die QT-basierten Apps haben wir die Touchpunkt-Erkennung sowohl mit QML als auch mit C++ implementiert, da sich herausstellte, dass die Erkennung mit QML im Vergleich zu C++ eine größere Verzögerung aufweist.
  • Gesten-Test: Diese Anwendung ermöglicht das Testen gängiger Gesten, wie z.B. Pinch-to-Zoom oder das Rotieren eines Bildes mit zwei Fingern.
  • Labyrinth-Test: Diese App dient dazu, die Präzision der Touch-Erkennung zu überprüfen. Benutzer müssen mit dem Finger eine Linie zeichnen, um durch ein Labyrinth zu navigieren.
  • Animations-Test: Mit dieser App wird die Leistungsfähigkeit der Frameworks in Bezug auf Animationen getestet, indem zahlreiche Animationen gleichzeitig abgespielt werden.
  • Video-Performance-Test: Diese Anwendung prüft, wie effektiv das Framework Videos abspielen kann.

So kompilieren wir die QT- und Flutter-Apps

Der einfachste Weg, die Testapplikationen für den Raspberry Pi zu kompilieren, ist, sie direkt auf dem Pi zu bauen. Interessanterweise dauerte der Prozess für die QML-Anwendung nur wenige Sekunden, während die Flutter-App mehr als 5 Minuten für die Kompilierung auf dem Raspberry Pi gebraucht hat. Dies lässt sich dadurch erklären, dass für die QT-App dynamic linking verwendet, während für die Flutter App immer alles neu kompiliert wird.

Alternativ kann man die Anwendungen auch von einem anderen Computer aus „cross“ kompilieren. In der Praxis wird dies oft bevorzugt, insbesondere bei professionellen Projekten. Dieser Ansatz vereinfacht die Entwicklung für Geräte mit begrenzten Ressourcen, da er das Erstellen der Software auf leistungsfähigeren Systemen ermöglicht. Durch die Vereinfachung der Abhängigkeitsverwaltung und die Gewährleistung reproduzierbarer Builds wird die Entwicklung effizienter und flexibler.

Performance von QT und Flutter

Wie erwartet laufen sowohl die QML- als auch die Flutter-Anwendungen auf dem Raspberry Pi ohne Probleme. Allerdings zeigt die Flutter-App eine deutlich höhere Auslastung von CPU und Arbeitsspeicher. Während die QT-App im App-Menü nur etwa 90 MB Arbeitsspeicher benötigt, verbraucht die Flutter-App mehr als 400 MB. Es scheint, dass die Flutter Linux-Desktop Umgebung deutlich ineffizienter arbeitet. Auf dem Raspberry Pi mit 8 GB Arbeitsspeicher stellt dies kein Problem dar. In der Praxis werden jedoch häufig Systeme mit deutlich weniger Ressourcen eingesetzt.

Raspberry Pi: Physikalischer Speicherbedarf im Startmenü der Applikation

Nach unserer Analyse zeigt sich, dass der Speicherbedarf für die QT- und Flutter-Applikationen auf dem STM32 mit 512 MB RAM mit 72 MB bzw. 75 MB RAM deutlich niedriger ist als auf dem Raspberry Pi. Der Grund dafür ist vermutlich das schlankere Linux-System und die Verwendung eines Flutter-Embedders anstelle der Desktop-Linux-Umgebung. Trotzdem lässt sich auch hier ein Vorteil für die QT-Anwendung im Vergleich zu Flutter feststellen. Die Unterschiede sind zwar nicht so signifikant wie beim Raspberry Pi, dennoch zeigt sich erneut, dass QT im Vergleich besser abschneidet.

STM32: Physikalischer Speicherbedarf unter Einbezug von shared libraries im Startmenü der Applikation

QT vs. Flutter: QT hat immer noch die Nase vorn

Unsere Ergebnisse zeigen, dass Flutter unter bestimmten Bedingungen durchaus eine geeignete Alternative zu QT sein kann. Die Vorteile von Flutter liegen in einem moderneren Entwicklungsprozess und der Verwendung zeitgemäßer Programmiersprachen, was im Allgemeinen die Entwicklung beschleunigt. Ein weiterer Pluspunkt ist die attraktive Lizenzstruktur, da im Gegensatz zu QT grundsätzlich keine Gebühren anfallen. Unsere Untersuchung hat aber auch gezeigt, dass Flutter auf Embedded-Plattformen noch nicht die gleiche Effizienz erreicht wie QT.

Das liegt daran, dass QT für die gleiche Anwendung deutlich weniger Speicher braucht. Daher bleiben die Bedingungen, unter denen Flutter eine geeignete Alternative zu QT ist, spezifisch: Das Framework eignet sich besonders für Projekte, bei denen es auf schnelle Entwicklung und plattformübergreifende Kompatibilität ankommt. Wohingegen in Szenarien, bei denen Systeme nur über begrenzte Ressourcen verfügen und deren effiziente Nutzung besonders kritisch ist, QT höchstwahrscheinlich weiterhin die Nase vorn haben wird und die erste Wahl bleibt.

Vorteile von Flutter:

  • Entwicklungsprozess: Flutter ist ein Open-Source-UI-Toolkit, das Entwicklern ermöglicht, plattformübergreifende Anwendungen zu erstellen
  • Moderne Programmiersprache: Flutter verwendet Dart, eine moderne, single-threaded Sprache mit einem starken Fokus auf reaktiver Programmierung
  • Attraktive Lizenzierungsstruktur: Im Gegensatz zu QT fallen grundsätzlich keine Lizenzgebühren an, was die Entwicklungskosten minimieren, kann
  • Hot-Reload-Funktion: Die Möglichkeit, Änderungen im Code sofort zu sehen, beschleunigt den Entwicklungsprozess

Nachteile von Flutter im Vergleich zu QT:

  • Effizienz auf Embedded-Plattformen: Im Vergleich zu plattformspezifischen Lösungen wie QT ist Flutter auf Embedded-Plattformen weniger effizient
  • Geringere Paketverfügbarkeit: Im Vergleich zum etablierteren Framework (QT) gibt es derzeit eine begrenztere Anzahl an verfügbaren Paketen
  • Höherer Ressourcenbedarf: Benötigt mehr Ressourcen für gleiche Anwendungen wie QT

Ausblick: Alternativen zu QT und Flutter

Eine weitere vielversprechende Alternative zu QT könnten reine Webanwendungen sein, besonders weil sie nativ in Browsern auf Embedded-Geräten laufen können und somit nahezu keine Voraussetzungen an das darunterliegende Betriebssystem stellen. Obwohl diese Flexibilität einen attraktiven Ansatz bietet, gibt es legitime Bedenken hinsichtlich der Ressourceneffizienz und der langfristigen Zukunftssicherheit solcher Lösungen.

Ein weiterer wesentlicher Aspekt im Websektor ist die rasche Entwicklung und das häufige Aufkommen neuer Frameworks und Methoden. Dies steht im starken Kontrast zu den Anforderungen im Embedded-Bereich, wo langfristiger Support und die Reife von Technologien im Vordergrund stehen. Dennoch könnte es in Zukunft interessant sein, sich das genauer anzusehen.


Über die Autoren

Marcus Voß

Smart Devices

Marcus Voß ist seit Oktober 2023 bei MaibornWolff als Software Engineer im Bereich Smart Devices tätig. Bereits während seines Studiums beschäftigte er sich intensiv mit Embedded Linux und sowie der Programmierung von Mikrocontrollern. bei MaibornWolff arbeitet er an internen Forschungsprojekten und entwickelt innovative Lösungen in Kundenprojekten. Sein Fokus liegt dabei auf der Entwicklung in C, C++ und Python.

Hendrik Timmermann

Smart Devices

Hendrik ist seit November 2023 bei MaibornWolff als Software Engineer im Bereich Smart Devices tätig. In seiner täglichen Arbeit konzipiert und entwickelt er kundenspezifische Lösungen und greift dabei auf ein breites Fähigkeitsspektrum im Bereich eingebetteter Systeme, besonders im Umgang mit Mikrocontrollern, zurück.