Einige Updates: Wir machen nichts in der App, außer auf Ereignisse zu horchen und Bindings zu verwenden ... das heißt, keine ChangeWatchers, keine manuelle Abfrage ... nur auf Ereignisse wartend. Wir sind die ganze Zeit über mit FMS verbunden, es gibt also einen gewissen Overhead dafür, aber es ist minimal. Bindungen sind in Flex nicht besonders effizient, und wir haben festgestellt, dass es nicht gut ist, das Metadaten-Schlüsselwort [Bindable] direkt zu Klassen hinzuzufügen (in großen Mengen, mit vielen Klassen). Wir machen nicht viel davon, aber es ist eine Möglichkeit, etwas mehr Leistung aus Ihrer App herauszuholen. Wenn Sie [Bindable (event = "usersUpdated")] verwenden, haben Sie die Kontrolle über die Bindung, und sie wird nur ausgelöst, wenn Sie das Ereignis (new) ("usersUpdated") aus einer Funktion in der Klasse dispathen Setter für "Benutzer".
Jeder, der System.gc() in Flex oder AIR verwendet, wird Ihnen sagen, dass Flex Garbage Collection ein Witz ist. Es ist ein teilweise implementiertes Feature und niemand vertraut ihm. Dazu gibt es auch Tricks ... Ruf zweimal an, warte einen Frame, rufe ihn erneut an. Es könnte Ihre alten Objekte aufräumen, aber drücken Sie nicht die Daumen ... Flex macht, was es will.
Verwenden Sie auch temporäre Objekte, um die Anzahl der abgefeuerten Bindungen zu verringern. Statt ...
myUser.location = neuer Standort(); myUser.location.state = "CO"; myUser.location.city = "Denver";
do ...
var tempLoc: Location = new Location(); tempLoc.state = "CO"; tempLoc.city = "Denver"; myUser.location = tempLoc;
Die ehemaligen Brände 3 Bindungen an etwas Ort gebunden. *, Während die letzteren sollten (es ist in der Regel zusätzlichen aufgrund der Art und Weise Flex es in Wirklichkeit behandelt.) Nur Feuer 1-Bindung
Bindungen nicht Ihrem töten App, bis Sie eine Menge von ihnen in einer visuell reichen Anwendung haben ... Bindung und Rendering scheinen die langsamsten Jobs von Flex zu sein.
Eine weitere interessante Sache: Erstellen Sie eine brandneue Flex3-Anwendung in Flex Builder und führen Sie sie im Browser aus. Unsere Tests haben gezeigt, dass die CPU auf einem MacBookPro zwischen 8-10% bleibt (wenn sich die App im Leerlauf befindet und das Browserfenster ausgeblendet ist). Unsere Anwendung läuft jetzt konstant bei ~ 20% und während sie höher abspringt, um Änderungen der Ansicht und dergleichen zu handhaben, kehrt sie immer auf ein Niveau nahe 20% zurück. Unsere anfängliche Sorge war, dass ein Speicherleck oder etwas, das wegrennt, die CPU sehr hoch nehmen und es um 40-50% schweben lassen würde (wieder auf dem MBP ... alles relativ zu diesem Rechner). Wir haben alle Referenzen zu Degrafa herausgenommen und während wir ein gutes Stück Leistungssteigerung bemerkten, hat es nicht alles berücksichtigt. Die leere Flex-App war jedoch aufschlussreich - Flex selbst schwemmt immer 8-10% CPU, selbst im Leerlauf.
Noch ein weiterer Fund ... wenn Sie Mate verwenden, seien Sie vorsichtig, wie Sie mit dem Wechseln von Ansichten umgehen. Es ist einfach, Assets verfügbar zu haben und einfach zu verstecken & deaktivieren Sie sie, wenn sie nicht verwendet werden, mit einem Injektor und einer Bindung in MXML, aber Flex ist nicht sehr schlau, wenn es darum geht, Dinge zu verbergen/deaktivieren. Es ist am besten, die Ansichten spontan zu erstellen und sie zu zerstören, wenn sie fertig sind. Auch wenn die anfängliche Erstellung mehr Zeit in Anspruch nimmt und zwischen den Ansichten länger gewartet werden muss, verwenden Sie einige Anzeigemagie (Fortschrittsbalken, drehende Festplatte usw.), um anzuzeigen, dass die Ansicht wechselt, auf createComplete in der Ansicht wartet und dann verblassen Sie hinein.
Auch weg von ViewStack für visuell reichhaltige Anwendungen. Verwalte deinen eigenen Stapel.
Bisher wurden in diesem Thread die grundlegenden Leistungsprobleme jeder Sprache behandelt, aber Flex ist in vielerlei Hinsicht ein ganz besonderer kleiner Junge ("Special" wird nicht immer als positive Sache angesehen). Es gibt unzählige Fallstricke, da es auf einer sehr visuellen Plattform aufbaut und dennoch für RIAs entwickelt wurde. Flash Player optimiert also möglicherweise Videos, Animationen usw. und optimiert somit keine Flex-App. Erwarten Sie nicht, dass Flex-Apps dieselben Funktionen wie Flash-Apps ausführen. Es gibt auch einen großen Unterschied zwischen AVM (ActionScript Virtual Machine) für AS2 und AS3.
Dies ist nur die Oberfläche der Leistungsprobleme und potenzielle Gewinne in Flex-Apps kratzen. Dies ist eine dunkle Kunst und es ist leicht zu sehen warum.
Code auf, Ninjas.
Ich habe versucht zu spielen um mit der Framerate, aber es hatte keinen wirklichen Effekt auf die Leistung. Wenn Sie die Framerate zu stark verringern, würde dies dazu führen, dass die Änderungen an der Benutzeroberfläche zu langsam ablaufen und die angezeigten Probleme nicht beheben. – Herms
Die Sache ist, der Profiler behauptet, dass das Ereignis ITSELF 32% der CPU-Zeit einnimmt (es plus, was es fordert, nimmt 84%). Das ist sehr viel Zeit für eine Veranstaltung. Etwas ist los, aber ich kann nicht sagen, was. – Herms