Flutter ist ein Framework von Google, welches auf den Programmiersprachen Dart, C, C++ basiert und zur Entwicklung von Nativen Cross-Platform-Apps verwendet wird. Zielplattformen sind dabei Android, IOS, Windows, MacOS, Linux, WebApp und Fuchsia.<\/p>\n\n\n\n
Applikationen die mit dem Flutter Framework entwickelt werden, werden in Dart geschrieben. Innerhalb dieser Entwicklung wird mittels Widgets gearbeitet. Widgets k\u00f6nnen dabei stateful und stateless arbeiten.<\/p>\n\n\n\n
Stateless Widgets beinhalten Kontent, welcher einmal gebaut wird und sich dann nicht mehr \u00e4ndert.<\/p>\n\n\n\n
Stateful Widgets sind dabei Widgets, welche interaktiv mit dem Nutzer agieren oder sich \u00e4ndern k\u00f6nnen, wenn sie neue Daten erhalten. Der Zustand eines Widgets wird dabei von der visuellen Darstellung getrennt. Wenn sich der Zustand des Widgets \u00e4ndert, ruft das State-Objekt die Methode \u201csetState()\u201d auf und weist das Framework an, das Widget neu zu zeichnen.<\/p>\n\n\n\n
Diese Widgets stellen sp\u00e4ter auch Teile der Oberfl\u00e4che dar. Neben einem vom Betriebssystem abh\u00e4ngigen Design, wie Material f\u00fcr Googles Android oder Cupertino f\u00fcr Apples IOS, beinhalten Widgets auch Logik, welche das Verhalten auf Gesten, die Datenverarbeitung und Animationen definiert. Diese Widgets k\u00f6nnen dabei auch verschachtelt werden und bilden dabei logisch eine Baumstruktur. <\/p>\n\n\n\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/02\/image5.png\")
<\/a>Code, der in Flutter geschrieben wurde, wird in der Flutter Engine verarbeitet. Der Quellcode kann mit Dart 2 Native als Ahead of Time (AOT) native \u00fcbersetzt werden oder mit der Dart-VM als Just in Time (JIT) ausgef\u00fchrt werden. Just in Time \u00fcbersetzter Code ist beim Start langsamer, kann aber eine bessere Spitzenleistung aufweisen, wenn er lange genug l\u00e4uft, sodass Laufzeitoptimierungen angewendet werden k\u00f6nnen. [1,2,3,4,5]<\/p>\n\n\n\n
Warum Codeoptimierung?<\/strong><\/h2>\n\n\n\nFlutter wurde zu Beginn entwickelt um auf mobilen Ger\u00e4ten Anwendung zu finden. Google wollte dabei die Barriere zwischen den Systemen brechen, damit Code nicht doppelt geschrieben werden muss und so Kosten in der Entwicklung eingespart werden k\u00f6nnen.
Dabei ist es jedoch gerade bei mobilen Plattformen wichtig, dass Code performant und optimiert l\u00e4uft, denn nicht optimierter Code kann dazu f\u00fchren, dass:<\/p>\n\n\n\n
- Applikationen, mehr Leistung und somit auch mehr Akkukapazit\u00e4t ben\u00f6tigen. <\/li>
- die Bedienung oft tr\u00e4ge wirkt durch Ruckler oder l\u00e4ngere Ladezeiten.<\/li>
- mehr Speicher oder Rechenleistung ben\u00f6tigt wird, welcher gerade bei \u00e4lteren Ger\u00e4ten im mobilen Bereich nicht zur Verf\u00fcgung steht. <\/li>
- mehr Datenvolumen bei der \u00dcbertragung ben\u00f6tigt wird.<\/li><\/ul>\n\n\n\n
Allein diese Gr\u00fcnden k\u00f6nnen dazu f\u00fchren, dass der Nutzer mit einer Applikation unzufrieden ist, sie nicht oder wenig nutzt oder gar deinstalliert und sich eine Alternative sucht. F\u00fcr den Entwickler hei\u00dft dies demzufolge fehlende Nutzer und daraus resultieren fehlende Einnahmen. [6,7,8]<\/p>\n\n\n\n
Codeoptimierung, was kann ich als Entwickler tun?<\/strong><\/h2>\n\n\n\nGenerell sollte beim Optimieren die Frage gestellt werden, wo der Code ausgef\u00fchrt wird. Eine Flutteranwendung nutzt standardm\u00e4\u00dfig folgende drei Threatarten, auf welche kurz eingegangen werden soll:<\/p>\n\n\n\n
- UI-Thread: Dies ist der Main Thread, welcher Widgets verarbeitet. Er wird von einer Ereignisschleife gesteuert. Die Ereignisschleife von Flutter ist \u00e4quivalent zu Androids Main-Looper. Dieser Thread darf nicht blockiert werden! Er wird in der unteren Zeile des Performance-Overlays angezeigt.<\/li>
- Raster-Thread: Verarbeitet das Rendern und die Darstellung von Bildern. Es ist nicht m\u00f6glich direkt auf dem Raster-Thread oder seine Daten zuzugreifen, aber wenn dieser Thread langsam ist, resultiert dies von etwas, was im Dart-Code gemacht wurde. Die Grafikbibliothek Skia l\u00e4uft auf diesem Thread. Dieser wird in der oberen Zeile des Performance-Overlays angezeigt. Dieser Thread war fr\u00fcher als “GPU-Thread” bekannt, weil dieser f\u00fcr die GPU arbeitet. Tats\u00e4chlich l\u00e4uft dieser aber auf der CPU. Er wurde in Raster-Thread umbenannt, weil viele Entwickler f\u00e4lschlicherweise annahmen, dass der Thread auf der GPU-Einheit l\u00e4uft.<\/li>
- IO-Thread: Verarbeitet Kommunikationsdaten er ist f\u00fcr die Kommunikation mit der Au\u00dfenwelt zust\u00e4ndig.<\/li><\/ul>\n\n\n\n
Jedoch sollten auch eigene Threads genutzt werden. Falls in einer Anwendung zum Beispiel eine aufwendige Berechnung ausgef\u00fchrt werden soll, sollte der Compute-Thread genutzt werden. Der Compute-Thread dient dazu sehr aufwendige Berechnungen im Hintergrund zu berechnen, damit die Applikation w\u00e4hrenddessen weiterarbeiten kann und das User Interface nicht stehen bleibt bis die Berechnung fertig ist.<\/p>\n\n\n\n
Durch dieses Wissen ist es als Entwickler m\u00f6glich, Tools zu nutzen, um den eigenen Code zu optimieren. Als Entwicklertools stehen dabei unter anderem die Dart Dev Tools auf dem Entwicklerger\u00e4t und das Performance Overlay auf dem Endger\u00e4t zur Verf\u00fcgung. Wie diese aussehen zeigen die nachfolgenden Grafiken.<\/p>\n\n\n\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/02\/image7-1024x640.png\")
<\/a>Abbildung 2: Einblick in die Dart Dev Tools<\/figcaption><\/figure><\/div>\n\n\n\n![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/02\/performance-overlay.png\")
<\/a>Abbildung 3: Einblick in das Performance Overlay<\/figcaption><\/figure><\/div>\n\n\n\n\n\n\n\nDas Dart Dev Tool dient zur Auswertung des Speichers, dem Debugging, dem Logging, zum \u00dcberwachen des Traffics und vieles mehr. Das Performance Overlay dient zum \u00fcberwachen der Threads mit besonderem Schwerpunkt auf dem UI-Thread und den GPU-Thread, die im Folgenden n\u00e4her erl\u00e4utert werden.Durch das Performance Overlay k\u00f6nnen unter anderem Janks aufgesp\u00fcrt werden. Jank ist eine Art Ruckler, der dem Nutzer dadurch auff\u00e4llt, dass zum Beispiel eine Animation nicht fl\u00fcssig wirkt.Dies liegt daran, dass ein Frame nicht rechtzeitig fertig geladen wurde und sich somit mit dem n\u00e4chsten Frame innerhalb der Berechnung \u00fcberschneidet.In den fortfolgenden Grafiken wird das Jank veranschaulicht, dabei stehen die d\u00fcnnen, wei\u00dfen Vertikallinien f\u00fcr den Beginn der Berechnung eines Frames, die gr\u00fcnen, horizontalen Balken f\u00fcr die Dauer der Berechnung eines Frames. Die linke Abbildung zeigt den Optimalfall. Jeder Frame wurde fertig berechnet, bevor der N\u00e4chste beginnt. Die rechte Abbildung \u00fcberspringt einen Frame, da sich der vorherige Frame bei der Berechnung mit dem vorherigen Frame \u00fcberschneidet, die Animation wirkt demzufolge ruckelig. Jank tritt an den Stellen auf, an denen der UI-Thread eine hohe Auslastung in Form eines Spikes anzeigt. <\/p>\n\n\n\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/02\/Bild_2021-02-28_172744.png\")
<\/a>Abbildung 4: Veranschaulichung von Jank.<\/figcaption><\/figure><\/div>\n\n\n\n[9,10,11,12,17]<\/p>\n<\/div><\/div>\n\n\n\n
Ans\u00e4tze zum Optimieren <\/strong><\/h2>\n\n\n\nBeim Optimieren von Code gibt es, wie bereits erl\u00e4utert, mehrere Ans\u00e4tze, auf die mehreren Beispielen eingegangen werden soll.<\/p>\n\n\n\n
Beispiel 1<\/strong><\/h2>\n\n\n\nBeim Optimieren wird oftmals gesagt \u201cthere is no free lunch\u201d, was soviel bedeutet, dass wenn in eine Richtung optimiert wird, es in eine andere schlechter wird. Somit geht es beim Optimieren oft darum die richtige Balance zu finden. Auf mobilen Endger\u00e4ten muss dabei oft zwischen Speicher oder Performance abgewogen werden.<\/p>\n\n\n\n
Beeinflusst werden kann dies bei Flutter durch die geeignete Widgetwahl, was durch ein Beispiel schnell deutlich wird.<\/p>\n\n\n\n
Unter der Annahme, dass ein Bild aus dem Internet angezeigt werden soll, besteht die M\u00f6glichkeit die Widgets namens Network Image und Cached Network Image zu nutzen.<\/p>\n\n\n\n
Das Widget Network Image l\u00e4dt Bilddaten aus dem Internet immer neu, sobald es aufgerufen wird und ist dadurch etwas langsamer und ben\u00f6tigt mehr Akku durch die Datenverbindung. Es hat jedoch den Vorteil, dass wenig Speicher auf dem Ger\u00e4t ben\u00f6tigt wird, w\u00e4hrend die Anwendung genutzt wird.<\/p>\n\n\n\n
Wird stattdessen das Widget Cached Network Image verwendet, so wird das Bild nur einmal aus dem Internet heruntergeladen. Dies ist sp\u00e4ter beim erneuten Anzeigen schneller, da es auf dem Ger\u00e4t gespeichert und aus dem Ger\u00e4tespeicher geladen werden kann, auch wenn sp\u00e4ter keine Datenverbindung mehr zur Verf\u00fcgung stehen sollte.<\/p>\n<\/div><\/div>\n<\/div><\/div>\n<\/div><\/div>\n\n\n\n
Beispiel 2<\/strong><\/h2>\n\n\n\nEine weitere sehr einfache aber effektive \u00c4nderung bei Flutter ist das Erstellen von eigenen Widgets falls dieses Widget mehrfach genutzt werden. Veranschaulicht wird dies in einem nachfolgenden Beispiel in dem zwei Listen erstellt werden, die jeweils 1000 Widgets als Listitem beinhalten. Zum Veranschaulichen des Problems dient hierbei Abbildung 7. Bewusst wurde hier auf den Flutter eigenen Listbuilder verzichtet und eine for-schleife genommen, die 1000 Mal die Items erstellt.<\/p>\n\n\n\n
In Abbildung 8 wird das Widget immer neu aufgebaut, somit ben\u00f6tigt Flutter 1000*5 = 5000 Berechnungsschritte, denn es werden die Widgets (List Title, Padding, Image, Network Image Text) immer neu aufgebaut und verschachtelt.<\/p>\n\n\n\n
In Abbildung 9 wird das Widget in eine neue Klasse als Stateless definiert, somit ben\u00f6tigt Flutter 1000*1 = 5000 Berechnungsschritte, da die Struktur von List Title durch die Klasse bekannt ist und durch das Stateless nur mit unterschiedlichen Informationen gef\u00fcttert wird.<\/p>\n\n\n\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/02\/image10.png\")
<\/a>Abbildung 5: App mit zwei Listen <\/figcaption><\/figure><\/div>\n\n\n\n![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/02\/image9.png\")
<\/a>Abbildung 6: Code zur Erzeugung beider Listen<\/figcaption><\/figure><\/div>\n\n\n\n![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/02\/image15.png\")
<\/a>Abbildung 7: Schlechter Code – Widget Struktur wird immer neu aufgebaut<\/figcaption><\/figure>\n\n\n\n![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/02\/image13.png\")
<\/a>Abbildung 8: Verbesserter Code – Widget Struktur ist Flutter nach einmaligem Erstellen bekannt<\/figcaption><\/figure>\n\n\n\nBeispiel 3<\/strong><\/h2>\n\n\n\nDa viele Anwendungen an mehreren Stellen Bilder verwenden in Form von Icons oder um eigenen Inhalt darzustellen macht es hier Sinn, dass die Bilder in entsprechender Aufl\u00f6sung dargestellt werden. Das kann gerade bei einer Liste, wie in Beispiel 2 zu sehen war, sehr viel Leistung einsparen. Denn wenn Bilder in einer zu gro\u00dfen Aufl\u00f6sung hinterlegt sind, muss Flutter sie innerhalb der Applikation unter anderem Einlesen, Komprimieren und Rendern. Daher sollte in so einem Fall ein Thumbnail in angepasster Aufl\u00f6sung angeboten werden. Dadurch werden deutlich weniger Daten \u00fcbertragen, falls diese von Extern geladen werden m\u00fcssen oder spart Speicher, wenn diese, zum Beispiel als Icon, Teil der App sind.<\/p>\n\n\n\n
Durch die Anwendung eines gefilterten Bildes kann ein Junk vermieden werden, besonders wenn dies mit einer Animation kombiniert wird. W\u00fcrde man diese Filterung nicht vorab berechnen, m\u00fcsste sie f\u00fcr jeden Frame in einer Animation angewendet werden. Somit sollte auf Filter und leistungshungrige Funktionen zur Laufzeit m\u00f6glichst verzichtet werden, da diese sehr viele Ressourcen ben\u00f6tigen. <\/p>\n\n\n\n
In folgender Grafik wird ein Ausschnitt des Performance Overlays angezeigt, der durch eine einfache Animation mit Filter verursacht wird im Vergleich zu einer Animation ohne Filter.<\/p>\n\n\n\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/02\/image1.gif\")
<\/a>Abbildung 9: Darstellung der Animation mit Filter<\/figcaption><\/figure><\/div>\n\n\n\n![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/02\/image14-1.gif\")
<\/a>Abbildung 10: Darstellung der Animation ohne Filter<\/figcaption><\/figure><\/div>\n\n\n\n<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/02\/Bild_2021-02-28_173719.png\")
<\/a>Abbildung 11: Performance Overlay
links: erh\u00f6hte GPU-Auslastung durch permanentes Rendern der Frames
rechts: geringe GPU-Auslastung durch optimierten Code ohne Filter
<\/figcaption><\/figure><\/div>\n\n\n\nBeispiel 4<\/strong><\/h2>\n\n\n\nEine weitere kleine Anpassung, welche die App fl\u00fcssiger wirken lassen kann, ist das Anpassen von \u00dcbergangsanimationen. \u00dcbergangsanimationen tragen oft dazu bei, dass eine Applikation stimmiger wirkt oder der Nutzer ein besseres Verst\u00e4ndnis daf\u00fcr bekommt, was er gerade macht. Das Anpassen des Animationsverlaufs kann daf\u00fcr sorgen, dass Animationen stimmiger zum Kontext sind oder auch schneller wirken, obwohl die Animationsdauer exakt gleich bleibt. Je nachdem welche Operation gerade ausgef\u00fchrt wird, sollte ein Entwickler daher testen, welche Animationskurve den gew\u00fcnnschten Effekt erziehlt.<\/p>\n\n\n\n
Die folgende Animation dauert in Fall A und Fall B beides Mal 300 Millisekunden, jedoch wirkt Animation B schneller durch einen nichtlinearen Verlauf der Animation. <\/p>\n\n\n\n
Dabei ist es jedoch gerade bei mobilen Plattformen wichtig, dass Code performant und optimiert l\u00e4uft, denn nicht optimierter Code kann dazu f\u00fchren, dass:<\/p>\n\n\n\n
Allein diese Gr\u00fcnden k\u00f6nnen dazu f\u00fchren, dass der Nutzer mit einer Applikation unzufrieden ist, sie nicht oder wenig nutzt oder gar deinstalliert und sich eine Alternative sucht. F\u00fcr den Entwickler hei\u00dft dies demzufolge fehlende Nutzer und daraus resultieren fehlende Einnahmen. [6,7,8]<\/p>\n\n\n\n
Codeoptimierung, was kann ich als Entwickler tun?<\/strong><\/h2>\n\n\n\nGenerell sollte beim Optimieren die Frage gestellt werden, wo der Code ausgef\u00fchrt wird. Eine Flutteranwendung nutzt standardm\u00e4\u00dfig folgende drei Threatarten, auf welche kurz eingegangen werden soll:<\/p>\n\n\n\n
- UI-Thread: Dies ist der Main Thread, welcher Widgets verarbeitet. Er wird von einer Ereignisschleife gesteuert. Die Ereignisschleife von Flutter ist \u00e4quivalent zu Androids Main-Looper. Dieser Thread darf nicht blockiert werden! Er wird in der unteren Zeile des Performance-Overlays angezeigt.<\/li>
- Raster-Thread: Verarbeitet das Rendern und die Darstellung von Bildern. Es ist nicht m\u00f6glich direkt auf dem Raster-Thread oder seine Daten zuzugreifen, aber wenn dieser Thread langsam ist, resultiert dies von etwas, was im Dart-Code gemacht wurde. Die Grafikbibliothek Skia l\u00e4uft auf diesem Thread. Dieser wird in der oberen Zeile des Performance-Overlays angezeigt. Dieser Thread war fr\u00fcher als “GPU-Thread” bekannt, weil dieser f\u00fcr die GPU arbeitet. Tats\u00e4chlich l\u00e4uft dieser aber auf der CPU. Er wurde in Raster-Thread umbenannt, weil viele Entwickler f\u00e4lschlicherweise annahmen, dass der Thread auf der GPU-Einheit l\u00e4uft.<\/li>
- IO-Thread: Verarbeitet Kommunikationsdaten er ist f\u00fcr die Kommunikation mit der Au\u00dfenwelt zust\u00e4ndig.<\/li><\/ul>\n\n\n\n
Jedoch sollten auch eigene Threads genutzt werden. Falls in einer Anwendung zum Beispiel eine aufwendige Berechnung ausgef\u00fchrt werden soll, sollte der Compute-Thread genutzt werden. Der Compute-Thread dient dazu sehr aufwendige Berechnungen im Hintergrund zu berechnen, damit die Applikation w\u00e4hrenddessen weiterarbeiten kann und das User Interface nicht stehen bleibt bis die Berechnung fertig ist.<\/p>\n\n\n\n
Durch dieses Wissen ist es als Entwickler m\u00f6glich, Tools zu nutzen, um den eigenen Code zu optimieren. Als Entwicklertools stehen dabei unter anderem die Dart Dev Tools auf dem Entwicklerger\u00e4t und das Performance Overlay auf dem Endger\u00e4t zur Verf\u00fcgung. Wie diese aussehen zeigen die nachfolgenden Grafiken.<\/p>\n\n\n\n
<\/a>Abbildung 2: Einblick in die Dart Dev Tools<\/figcaption><\/figure><\/div>\n\n\n\n<\/a>Abbildung 3: Einblick in das Performance Overlay<\/figcaption><\/figure><\/div>\n\n\n\n\n\n\n\nDas Dart Dev Tool dient zur Auswertung des Speichers, dem Debugging, dem Logging, zum \u00dcberwachen des Traffics und vieles mehr. Das Performance Overlay dient zum \u00fcberwachen der Threads mit besonderem Schwerpunkt auf dem UI-Thread und den GPU-Thread, die im Folgenden n\u00e4her erl\u00e4utert werden.Durch das Performance Overlay k\u00f6nnen unter anderem Janks aufgesp\u00fcrt werden. Jank ist eine Art Ruckler, der dem Nutzer dadurch auff\u00e4llt, dass zum Beispiel eine Animation nicht fl\u00fcssig wirkt.Dies liegt daran, dass ein Frame nicht rechtzeitig fertig geladen wurde und sich somit mit dem n\u00e4chsten Frame innerhalb der Berechnung \u00fcberschneidet.In den fortfolgenden Grafiken wird das Jank veranschaulicht, dabei stehen die d\u00fcnnen, wei\u00dfen Vertikallinien f\u00fcr den Beginn der Berechnung eines Frames, die gr\u00fcnen, horizontalen Balken f\u00fcr die Dauer der Berechnung eines Frames. Die linke Abbildung zeigt den Optimalfall. Jeder Frame wurde fertig berechnet, bevor der N\u00e4chste beginnt. Die rechte Abbildung \u00fcberspringt einen Frame, da sich der vorherige Frame bei der Berechnung mit dem vorherigen Frame \u00fcberschneidet, die Animation wirkt demzufolge ruckelig. Jank tritt an den Stellen auf, an denen der UI-Thread eine hohe Auslastung in Form eines Spikes anzeigt. <\/p>\n\n\n\n
<\/a>Abbildung 4: Veranschaulichung von Jank.<\/figcaption><\/figure><\/div>\n\n\n\n[9,10,11,12,17]<\/p>\n<\/div><\/div>\n\n\n\n
Ans\u00e4tze zum Optimieren <\/strong><\/h2>\n\n\n\nBeim Optimieren von Code gibt es, wie bereits erl\u00e4utert, mehrere Ans\u00e4tze, auf die mehreren Beispielen eingegangen werden soll.<\/p>\n\n\n\n
Beispiel 1<\/strong><\/h2>\n\n\n\nBeim Optimieren wird oftmals gesagt \u201cthere is no free lunch\u201d, was soviel bedeutet, dass wenn in eine Richtung optimiert wird, es in eine andere schlechter wird. Somit geht es beim Optimieren oft darum die richtige Balance zu finden. Auf mobilen Endger\u00e4ten muss dabei oft zwischen Speicher oder Performance abgewogen werden.<\/p>\n\n\n\n
Beeinflusst werden kann dies bei Flutter durch die geeignete Widgetwahl, was durch ein Beispiel schnell deutlich wird.<\/p>\n\n\n\n
Unter der Annahme, dass ein Bild aus dem Internet angezeigt werden soll, besteht die M\u00f6glichkeit die Widgets namens Network Image und Cached Network Image zu nutzen.<\/p>\n\n\n\n
Das Widget Network Image l\u00e4dt Bilddaten aus dem Internet immer neu, sobald es aufgerufen wird und ist dadurch etwas langsamer und ben\u00f6tigt mehr Akku durch die Datenverbindung. Es hat jedoch den Vorteil, dass wenig Speicher auf dem Ger\u00e4t ben\u00f6tigt wird, w\u00e4hrend die Anwendung genutzt wird.<\/p>\n\n\n\n
Wird stattdessen das Widget Cached Network Image verwendet, so wird das Bild nur einmal aus dem Internet heruntergeladen. Dies ist sp\u00e4ter beim erneuten Anzeigen schneller, da es auf dem Ger\u00e4t gespeichert und aus dem Ger\u00e4tespeicher geladen werden kann, auch wenn sp\u00e4ter keine Datenverbindung mehr zur Verf\u00fcgung stehen sollte.<\/p>\n<\/div><\/div>\n<\/div><\/div>\n<\/div><\/div>\n\n\n\n
Beispiel 2<\/strong><\/h2>\n\n\n\nEine weitere sehr einfache aber effektive \u00c4nderung bei Flutter ist das Erstellen von eigenen Widgets falls dieses Widget mehrfach genutzt werden. Veranschaulicht wird dies in einem nachfolgenden Beispiel in dem zwei Listen erstellt werden, die jeweils 1000 Widgets als Listitem beinhalten. Zum Veranschaulichen des Problems dient hierbei Abbildung 7. Bewusst wurde hier auf den Flutter eigenen Listbuilder verzichtet und eine for-schleife genommen, die 1000 Mal die Items erstellt.<\/p>\n\n\n\n
In Abbildung 8 wird das Widget immer neu aufgebaut, somit ben\u00f6tigt Flutter 1000*5 = 5000 Berechnungsschritte, denn es werden die Widgets (List Title, Padding, Image, Network Image Text) immer neu aufgebaut und verschachtelt.<\/p>\n\n\n\n
In Abbildung 9 wird das Widget in eine neue Klasse als Stateless definiert, somit ben\u00f6tigt Flutter 1000*1 = 5000 Berechnungsschritte, da die Struktur von List Title durch die Klasse bekannt ist und durch das Stateless nur mit unterschiedlichen Informationen gef\u00fcttert wird.<\/p>\n\n\n\n
<\/a>Abbildung 5: App mit zwei Listen <\/figcaption><\/figure><\/div>\n\n\n\n<\/a>Abbildung 6: Code zur Erzeugung beider Listen<\/figcaption><\/figure><\/div>\n\n\n\n<\/a>Abbildung 7: Schlechter Code – Widget Struktur wird immer neu aufgebaut<\/figcaption><\/figure>\n\n\n\n<\/a>Abbildung 8: Verbesserter Code – Widget Struktur ist Flutter nach einmaligem Erstellen bekannt<\/figcaption><\/figure>\n\n\n\nBeispiel 3<\/strong><\/h2>\n\n\n\nDa viele Anwendungen an mehreren Stellen Bilder verwenden in Form von Icons oder um eigenen Inhalt darzustellen macht es hier Sinn, dass die Bilder in entsprechender Aufl\u00f6sung dargestellt werden. Das kann gerade bei einer Liste, wie in Beispiel 2 zu sehen war, sehr viel Leistung einsparen. Denn wenn Bilder in einer zu gro\u00dfen Aufl\u00f6sung hinterlegt sind, muss Flutter sie innerhalb der Applikation unter anderem Einlesen, Komprimieren und Rendern. Daher sollte in so einem Fall ein Thumbnail in angepasster Aufl\u00f6sung angeboten werden. Dadurch werden deutlich weniger Daten \u00fcbertragen, falls diese von Extern geladen werden m\u00fcssen oder spart Speicher, wenn diese, zum Beispiel als Icon, Teil der App sind.<\/p>\n\n\n\n
Durch die Anwendung eines gefilterten Bildes kann ein Junk vermieden werden, besonders wenn dies mit einer Animation kombiniert wird. W\u00fcrde man diese Filterung nicht vorab berechnen, m\u00fcsste sie f\u00fcr jeden Frame in einer Animation angewendet werden. Somit sollte auf Filter und leistungshungrige Funktionen zur Laufzeit m\u00f6glichst verzichtet werden, da diese sehr viele Ressourcen ben\u00f6tigen. <\/p>\n\n\n\n
In folgender Grafik wird ein Ausschnitt des Performance Overlays angezeigt, der durch eine einfache Animation mit Filter verursacht wird im Vergleich zu einer Animation ohne Filter.<\/p>\n\n\n\n
<\/a>Abbildung 9: Darstellung der Animation mit Filter<\/figcaption><\/figure><\/div>\n\n\n\n<\/a>Abbildung 10: Darstellung der Animation ohne Filter<\/figcaption><\/figure><\/div>\n\n\n\n<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/a>Abbildung 11: Performance Overlay
links: erh\u00f6hte GPU-Auslastung durch permanentes Rendern der Frames
rechts: geringe GPU-Auslastung durch optimierten Code ohne Filter
<\/figcaption><\/figure><\/div>\n\n\n\nBeispiel 4<\/strong><\/h2>\n\n\n\nEine weitere kleine Anpassung, welche die App fl\u00fcssiger wirken lassen kann, ist das Anpassen von \u00dcbergangsanimationen. \u00dcbergangsanimationen tragen oft dazu bei, dass eine Applikation stimmiger wirkt oder der Nutzer ein besseres Verst\u00e4ndnis daf\u00fcr bekommt, was er gerade macht. Das Anpassen des Animationsverlaufs kann daf\u00fcr sorgen, dass Animationen stimmiger zum Kontext sind oder auch schneller wirken, obwohl die Animationsdauer exakt gleich bleibt. Je nachdem welche Operation gerade ausgef\u00fchrt wird, sollte ein Entwickler daher testen, welche Animationskurve den gew\u00fcnnschten Effekt erziehlt.<\/p>\n\n\n\n
Die folgende Animation dauert in Fall A und Fall B beides Mal 300 Millisekunden, jedoch wirkt Animation B schneller durch einen nichtlinearen Verlauf der Animation. <\/p>\n\n\n\n
Jedoch sollten auch eigene Threads genutzt werden. Falls in einer Anwendung zum Beispiel eine aufwendige Berechnung ausgef\u00fchrt werden soll, sollte der Compute-Thread genutzt werden. Der Compute-Thread dient dazu sehr aufwendige Berechnungen im Hintergrund zu berechnen, damit die Applikation w\u00e4hrenddessen weiterarbeiten kann und das User Interface nicht stehen bleibt bis die Berechnung fertig ist.<\/p>\n\n\n\n
Durch dieses Wissen ist es als Entwickler m\u00f6glich, Tools zu nutzen, um den eigenen Code zu optimieren. Als Entwicklertools stehen dabei unter anderem die Dart Dev Tools auf dem Entwicklerger\u00e4t und das Performance Overlay auf dem Endger\u00e4t zur Verf\u00fcgung. Wie diese aussehen zeigen die nachfolgenden Grafiken.<\/p>\n\n\n\n
<\/a><\/a>Das Dart Dev Tool dient zur Auswertung des Speichers, dem Debugging, dem Logging, zum \u00dcberwachen des Traffics und vieles mehr. Das Performance Overlay dient zum \u00fcberwachen der Threads mit besonderem Schwerpunkt auf dem UI-Thread und den GPU-Thread, die im Folgenden n\u00e4her erl\u00e4utert werden.Durch das Performance Overlay k\u00f6nnen unter anderem Janks aufgesp\u00fcrt werden. Jank ist eine Art Ruckler, der dem Nutzer dadurch auff\u00e4llt, dass zum Beispiel eine Animation nicht fl\u00fcssig wirkt.Dies liegt daran, dass ein Frame nicht rechtzeitig fertig geladen wurde und sich somit mit dem n\u00e4chsten Frame innerhalb der Berechnung \u00fcberschneidet.In den fortfolgenden Grafiken wird das Jank veranschaulicht, dabei stehen die d\u00fcnnen, wei\u00dfen Vertikallinien f\u00fcr den Beginn der Berechnung eines Frames, die gr\u00fcnen, horizontalen Balken f\u00fcr die Dauer der Berechnung eines Frames. Die linke Abbildung zeigt den Optimalfall. Jeder Frame wurde fertig berechnet, bevor der N\u00e4chste beginnt. Die rechte Abbildung \u00fcberspringt einen Frame, da sich der vorherige Frame bei der Berechnung mit dem vorherigen Frame \u00fcberschneidet, die Animation wirkt demzufolge ruckelig. Jank tritt an den Stellen auf, an denen der UI-Thread eine hohe Auslastung in Form eines Spikes anzeigt. <\/p>\n\n\n\n
<\/a>[9,10,11,12,17]<\/p>\n<\/div><\/div>\n\n\n\n
Ans\u00e4tze zum Optimieren <\/strong><\/h2>\n\n\n\nBeim Optimieren von Code gibt es, wie bereits erl\u00e4utert, mehrere Ans\u00e4tze, auf die mehreren Beispielen eingegangen werden soll.<\/p>\n\n\n\n
Beispiel 1<\/strong><\/h2>\n\n\n\nBeim Optimieren wird oftmals gesagt \u201cthere is no free lunch\u201d, was soviel bedeutet, dass wenn in eine Richtung optimiert wird, es in eine andere schlechter wird. Somit geht es beim Optimieren oft darum die richtige Balance zu finden. Auf mobilen Endger\u00e4ten muss dabei oft zwischen Speicher oder Performance abgewogen werden.<\/p>\n\n\n\n
Beeinflusst werden kann dies bei Flutter durch die geeignete Widgetwahl, was durch ein Beispiel schnell deutlich wird.<\/p>\n\n\n\n
Unter der Annahme, dass ein Bild aus dem Internet angezeigt werden soll, besteht die M\u00f6glichkeit die Widgets namens Network Image und Cached Network Image zu nutzen.<\/p>\n\n\n\n
Das Widget Network Image l\u00e4dt Bilddaten aus dem Internet immer neu, sobald es aufgerufen wird und ist dadurch etwas langsamer und ben\u00f6tigt mehr Akku durch die Datenverbindung. Es hat jedoch den Vorteil, dass wenig Speicher auf dem Ger\u00e4t ben\u00f6tigt wird, w\u00e4hrend die Anwendung genutzt wird.<\/p>\n\n\n\n
Wird stattdessen das Widget Cached Network Image verwendet, so wird das Bild nur einmal aus dem Internet heruntergeladen. Dies ist sp\u00e4ter beim erneuten Anzeigen schneller, da es auf dem Ger\u00e4t gespeichert und aus dem Ger\u00e4tespeicher geladen werden kann, auch wenn sp\u00e4ter keine Datenverbindung mehr zur Verf\u00fcgung stehen sollte.<\/p>\n<\/div><\/div>\n<\/div><\/div>\n<\/div><\/div>\n\n\n\n
Beispiel 2<\/strong><\/h2>\n\n\n\nEine weitere sehr einfache aber effektive \u00c4nderung bei Flutter ist das Erstellen von eigenen Widgets falls dieses Widget mehrfach genutzt werden. Veranschaulicht wird dies in einem nachfolgenden Beispiel in dem zwei Listen erstellt werden, die jeweils 1000 Widgets als Listitem beinhalten. Zum Veranschaulichen des Problems dient hierbei Abbildung 7. Bewusst wurde hier auf den Flutter eigenen Listbuilder verzichtet und eine for-schleife genommen, die 1000 Mal die Items erstellt.<\/p>\n\n\n\n
In Abbildung 8 wird das Widget immer neu aufgebaut, somit ben\u00f6tigt Flutter 1000*5 = 5000 Berechnungsschritte, denn es werden die Widgets (List Title, Padding, Image, Network Image Text) immer neu aufgebaut und verschachtelt.<\/p>\n\n\n\n
In Abbildung 9 wird das Widget in eine neue Klasse als Stateless definiert, somit ben\u00f6tigt Flutter 1000*1 = 5000 Berechnungsschritte, da die Struktur von List Title durch die Klasse bekannt ist und durch das Stateless nur mit unterschiedlichen Informationen gef\u00fcttert wird.<\/p>\n\n\n\n
<\/a>Abbildung 5: App mit zwei Listen <\/figcaption><\/figure><\/div>\n\n\n\n<\/a>Abbildung 6: Code zur Erzeugung beider Listen<\/figcaption><\/figure><\/div>\n\n\n\n<\/a>Abbildung 7: Schlechter Code – Widget Struktur wird immer neu aufgebaut<\/figcaption><\/figure>\n\n\n\n<\/a>Abbildung 8: Verbesserter Code – Widget Struktur ist Flutter nach einmaligem Erstellen bekannt<\/figcaption><\/figure>\n\n\n\nBeispiel 3<\/strong><\/h2>\n\n\n\nDa viele Anwendungen an mehreren Stellen Bilder verwenden in Form von Icons oder um eigenen Inhalt darzustellen macht es hier Sinn, dass die Bilder in entsprechender Aufl\u00f6sung dargestellt werden. Das kann gerade bei einer Liste, wie in Beispiel 2 zu sehen war, sehr viel Leistung einsparen. Denn wenn Bilder in einer zu gro\u00dfen Aufl\u00f6sung hinterlegt sind, muss Flutter sie innerhalb der Applikation unter anderem Einlesen, Komprimieren und Rendern. Daher sollte in so einem Fall ein Thumbnail in angepasster Aufl\u00f6sung angeboten werden. Dadurch werden deutlich weniger Daten \u00fcbertragen, falls diese von Extern geladen werden m\u00fcssen oder spart Speicher, wenn diese, zum Beispiel als Icon, Teil der App sind.<\/p>\n\n\n\n
Durch die Anwendung eines gefilterten Bildes kann ein Junk vermieden werden, besonders wenn dies mit einer Animation kombiniert wird. W\u00fcrde man diese Filterung nicht vorab berechnen, m\u00fcsste sie f\u00fcr jeden Frame in einer Animation angewendet werden. Somit sollte auf Filter und leistungshungrige Funktionen zur Laufzeit m\u00f6glichst verzichtet werden, da diese sehr viele Ressourcen ben\u00f6tigen. <\/p>\n\n\n\n
In folgender Grafik wird ein Ausschnitt des Performance Overlays angezeigt, der durch eine einfache Animation mit Filter verursacht wird im Vergleich zu einer Animation ohne Filter.<\/p>\n\n\n\n
<\/a>Abbildung 9: Darstellung der Animation mit Filter<\/figcaption><\/figure><\/div>\n\n\n\n<\/a>Abbildung 10: Darstellung der Animation ohne Filter<\/figcaption><\/figure><\/div>\n\n\n\n<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/a>Abbildung 11: Performance Overlay
links: erh\u00f6hte GPU-Auslastung durch permanentes Rendern der Frames
rechts: geringe GPU-Auslastung durch optimierten Code ohne Filter
<\/figcaption><\/figure><\/div>\n\n\n\nBeispiel 4<\/strong><\/h2>\n\n\n\nEine weitere kleine Anpassung, welche die App fl\u00fcssiger wirken lassen kann, ist das Anpassen von \u00dcbergangsanimationen. \u00dcbergangsanimationen tragen oft dazu bei, dass eine Applikation stimmiger wirkt oder der Nutzer ein besseres Verst\u00e4ndnis daf\u00fcr bekommt, was er gerade macht. Das Anpassen des Animationsverlaufs kann daf\u00fcr sorgen, dass Animationen stimmiger zum Kontext sind oder auch schneller wirken, obwohl die Animationsdauer exakt gleich bleibt. Je nachdem welche Operation gerade ausgef\u00fchrt wird, sollte ein Entwickler daher testen, welche Animationskurve den gew\u00fcnnschten Effekt erziehlt.<\/p>\n\n\n\n
Die folgende Animation dauert in Fall A und Fall B beides Mal 300 Millisekunden, jedoch wirkt Animation B schneller durch einen nichtlinearen Verlauf der Animation. <\/p>\n\n\n\n
Beim Optimieren wird oftmals gesagt \u201cthere is no free lunch\u201d, was soviel bedeutet, dass wenn in eine Richtung optimiert wird, es in eine andere schlechter wird. Somit geht es beim Optimieren oft darum die richtige Balance zu finden. Auf mobilen Endger\u00e4ten muss dabei oft zwischen Speicher oder Performance abgewogen werden.<\/p>\n\n\n\n
Beeinflusst werden kann dies bei Flutter durch die geeignete Widgetwahl, was durch ein Beispiel schnell deutlich wird.<\/p>\n\n\n\n
Unter der Annahme, dass ein Bild aus dem Internet angezeigt werden soll, besteht die M\u00f6glichkeit die Widgets namens Network Image und Cached Network Image zu nutzen.<\/p>\n\n\n\n
Das Widget Network Image l\u00e4dt Bilddaten aus dem Internet immer neu, sobald es aufgerufen wird und ist dadurch etwas langsamer und ben\u00f6tigt mehr Akku durch die Datenverbindung. Es hat jedoch den Vorteil, dass wenig Speicher auf dem Ger\u00e4t ben\u00f6tigt wird, w\u00e4hrend die Anwendung genutzt wird.<\/p>\n\n\n\n
Wird stattdessen das Widget Cached Network Image verwendet, so wird das Bild nur einmal aus dem Internet heruntergeladen. Dies ist sp\u00e4ter beim erneuten Anzeigen schneller, da es auf dem Ger\u00e4t gespeichert und aus dem Ger\u00e4tespeicher geladen werden kann, auch wenn sp\u00e4ter keine Datenverbindung mehr zur Verf\u00fcgung stehen sollte.<\/p>\n<\/div><\/div>\n<\/div><\/div>\n<\/div><\/div>\n\n\n\n
Beispiel 2<\/strong><\/h2>\n\n\n\nEine weitere sehr einfache aber effektive \u00c4nderung bei Flutter ist das Erstellen von eigenen Widgets falls dieses Widget mehrfach genutzt werden. Veranschaulicht wird dies in einem nachfolgenden Beispiel in dem zwei Listen erstellt werden, die jeweils 1000 Widgets als Listitem beinhalten. Zum Veranschaulichen des Problems dient hierbei Abbildung 7. Bewusst wurde hier auf den Flutter eigenen Listbuilder verzichtet und eine for-schleife genommen, die 1000 Mal die Items erstellt.<\/p>\n\n\n\n
In Abbildung 8 wird das Widget immer neu aufgebaut, somit ben\u00f6tigt Flutter 1000*5 = 5000 Berechnungsschritte, denn es werden die Widgets (List Title, Padding, Image, Network Image Text) immer neu aufgebaut und verschachtelt.<\/p>\n\n\n\n
In Abbildung 9 wird das Widget in eine neue Klasse als Stateless definiert, somit ben\u00f6tigt Flutter 1000*1 = 5000 Berechnungsschritte, da die Struktur von List Title durch die Klasse bekannt ist und durch das Stateless nur mit unterschiedlichen Informationen gef\u00fcttert wird.<\/p>\n\n\n\n
<\/a>Abbildung 5: App mit zwei Listen <\/figcaption><\/figure><\/div>\n\n\n\n<\/a>Abbildung 6: Code zur Erzeugung beider Listen<\/figcaption><\/figure><\/div>\n\n\n\n<\/a>Abbildung 7: Schlechter Code – Widget Struktur wird immer neu aufgebaut<\/figcaption><\/figure>\n\n\n\n<\/a>Abbildung 8: Verbesserter Code – Widget Struktur ist Flutter nach einmaligem Erstellen bekannt<\/figcaption><\/figure>\n\n\n\nBeispiel 3<\/strong><\/h2>\n\n\n\nDa viele Anwendungen an mehreren Stellen Bilder verwenden in Form von Icons oder um eigenen Inhalt darzustellen macht es hier Sinn, dass die Bilder in entsprechender Aufl\u00f6sung dargestellt werden. Das kann gerade bei einer Liste, wie in Beispiel 2 zu sehen war, sehr viel Leistung einsparen. Denn wenn Bilder in einer zu gro\u00dfen Aufl\u00f6sung hinterlegt sind, muss Flutter sie innerhalb der Applikation unter anderem Einlesen, Komprimieren und Rendern. Daher sollte in so einem Fall ein Thumbnail in angepasster Aufl\u00f6sung angeboten werden. Dadurch werden deutlich weniger Daten \u00fcbertragen, falls diese von Extern geladen werden m\u00fcssen oder spart Speicher, wenn diese, zum Beispiel als Icon, Teil der App sind.<\/p>\n\n\n\n
Durch die Anwendung eines gefilterten Bildes kann ein Junk vermieden werden, besonders wenn dies mit einer Animation kombiniert wird. W\u00fcrde man diese Filterung nicht vorab berechnen, m\u00fcsste sie f\u00fcr jeden Frame in einer Animation angewendet werden. Somit sollte auf Filter und leistungshungrige Funktionen zur Laufzeit m\u00f6glichst verzichtet werden, da diese sehr viele Ressourcen ben\u00f6tigen. <\/p>\n\n\n\n
In folgender Grafik wird ein Ausschnitt des Performance Overlays angezeigt, der durch eine einfache Animation mit Filter verursacht wird im Vergleich zu einer Animation ohne Filter.<\/p>\n\n\n\n
<\/a>Abbildung 9: Darstellung der Animation mit Filter<\/figcaption><\/figure><\/div>\n\n\n\n<\/a>Abbildung 10: Darstellung der Animation ohne Filter<\/figcaption><\/figure><\/div>\n\n\n\n<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/a>Abbildung 11: Performance Overlay
links: erh\u00f6hte GPU-Auslastung durch permanentes Rendern der Frames
rechts: geringe GPU-Auslastung durch optimierten Code ohne Filter
<\/figcaption><\/figure><\/div>\n\n\n\nBeispiel 4<\/strong><\/h2>\n\n\n\nEine weitere kleine Anpassung, welche die App fl\u00fcssiger wirken lassen kann, ist das Anpassen von \u00dcbergangsanimationen. \u00dcbergangsanimationen tragen oft dazu bei, dass eine Applikation stimmiger wirkt oder der Nutzer ein besseres Verst\u00e4ndnis daf\u00fcr bekommt, was er gerade macht. Das Anpassen des Animationsverlaufs kann daf\u00fcr sorgen, dass Animationen stimmiger zum Kontext sind oder auch schneller wirken, obwohl die Animationsdauer exakt gleich bleibt. Je nachdem welche Operation gerade ausgef\u00fchrt wird, sollte ein Entwickler daher testen, welche Animationskurve den gew\u00fcnnschten Effekt erziehlt.<\/p>\n\n\n\n
Die folgende Animation dauert in Fall A und Fall B beides Mal 300 Millisekunden, jedoch wirkt Animation B schneller durch einen nichtlinearen Verlauf der Animation. <\/p>\n\n\n\n
<\/a><\/a><\/a><\/a>Beispiel 3<\/strong><\/h2>\n\n\n\nDa viele Anwendungen an mehreren Stellen Bilder verwenden in Form von Icons oder um eigenen Inhalt darzustellen macht es hier Sinn, dass die Bilder in entsprechender Aufl\u00f6sung dargestellt werden. Das kann gerade bei einer Liste, wie in Beispiel 2 zu sehen war, sehr viel Leistung einsparen. Denn wenn Bilder in einer zu gro\u00dfen Aufl\u00f6sung hinterlegt sind, muss Flutter sie innerhalb der Applikation unter anderem Einlesen, Komprimieren und Rendern. Daher sollte in so einem Fall ein Thumbnail in angepasster Aufl\u00f6sung angeboten werden. Dadurch werden deutlich weniger Daten \u00fcbertragen, falls diese von Extern geladen werden m\u00fcssen oder spart Speicher, wenn diese, zum Beispiel als Icon, Teil der App sind.<\/p>\n\n\n\n
Durch die Anwendung eines gefilterten Bildes kann ein Junk vermieden werden, besonders wenn dies mit einer Animation kombiniert wird. W\u00fcrde man diese Filterung nicht vorab berechnen, m\u00fcsste sie f\u00fcr jeden Frame in einer Animation angewendet werden. Somit sollte auf Filter und leistungshungrige Funktionen zur Laufzeit m\u00f6glichst verzichtet werden, da diese sehr viele Ressourcen ben\u00f6tigen. <\/p>\n\n\n\n
In folgender Grafik wird ein Ausschnitt des Performance Overlays angezeigt, der durch eine einfache Animation mit Filter verursacht wird im Vergleich zu einer Animation ohne Filter.<\/p>\n\n\n\n
<\/a>Abbildung 9: Darstellung der Animation mit Filter<\/figcaption><\/figure><\/div>\n\n\n\n<\/a>Abbildung 10: Darstellung der Animation ohne Filter<\/figcaption><\/figure><\/div>\n\n\n\n<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/a>Abbildung 11: Performance Overlay
links: erh\u00f6hte GPU-Auslastung durch permanentes Rendern der Frames
rechts: geringe GPU-Auslastung durch optimierten Code ohne Filter
<\/figcaption><\/figure><\/div>\n\n\n\nBeispiel 4<\/strong><\/h2>\n\n\n\nEine weitere kleine Anpassung, welche die App fl\u00fcssiger wirken lassen kann, ist das Anpassen von \u00dcbergangsanimationen. \u00dcbergangsanimationen tragen oft dazu bei, dass eine Applikation stimmiger wirkt oder der Nutzer ein besseres Verst\u00e4ndnis daf\u00fcr bekommt, was er gerade macht. Das Anpassen des Animationsverlaufs kann daf\u00fcr sorgen, dass Animationen stimmiger zum Kontext sind oder auch schneller wirken, obwohl die Animationsdauer exakt gleich bleibt. Je nachdem welche Operation gerade ausgef\u00fchrt wird, sollte ein Entwickler daher testen, welche Animationskurve den gew\u00fcnnschten Effekt erziehlt.<\/p>\n\n\n\n
Die folgende Animation dauert in Fall A und Fall B beides Mal 300 Millisekunden, jedoch wirkt Animation B schneller durch einen nichtlinearen Verlauf der Animation. <\/p>\n\n\n\n
<\/a><\/a><\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/a>links: erh\u00f6hte GPU-Auslastung durch permanentes Rendern der Frames
rechts: geringe GPU-Auslastung durch optimierten Code ohne Filter
<\/figcaption><\/figure><\/div>\n\n\n\n