actionscript-3 swf - Statische Actionscript-Code-Analyse?





decompiler online (7)


Schau dir diese Anwendung an: http://evgeniy-polyakov.github.io/link-report-analyzer/ . Es ermöglicht geschachtelte und zirkuläre Abhängigkeiten im Verbindungsbericht zu finden.

Ich möchte Klassen, Funktionen und Variablen / Eigenschaften, Abhängigkeiten visuell sehen, wie NDepend , aber für ActionScript 2 oder AS3-Code.

Irgendwelche Programme oder Ideen?

Verwenden Sie Doxygen in irgendeiner Weise?

FlexUnit?




Zur Laufzeit erhalten Sie über die describeType-Methode (Teil von flash.utils) auch Informationen zu einzelnen Klassen. Es gibt ein XML-Dokument zurück, das die Klasse beschreibt, die Sie ihm geben.




Die Flex SDK-Compiler verfügen -link-report Argument -link-report , das Ihnen einige gute Informationen über die in die SWF-Datei kompilierten Klassen und ihre Abhängigkeiten liefert.

Weitere Informationen finden Sie unter Überprüfen der Linkerabhängigkeiten in der Flex 3-Dokumentation.




Weit davon entfernt, eine vollständige Lösung zu sein, aber um zu starten, können Sie Flex SDK ASDoc verwenden, um die Klassenpfadstruktur in einem einzigen XML zu generieren (dank der Argumente -keep-xml-skip-xsl ).

Danach könntest du wahrscheinlich ein schönes Ergebnis erhalten, wenn du mit graphviz ( http://www.graphviz.org/Resources.php ) spielst.

Alles über ANT zu automatisieren und Sie sind sortiert; )




Ich wollte einen Link zu Big Kahuna Burgers Link Report Visualizer veröffentlichen, aber ich sehe, dass Darrin ein viel besseres Werkzeug gefunden hat.

Trotzdem könnte es von Nutzen sein

LinkReportAIR




ItDepends , ein visueller Browser für Klassen- und ItDepends in Flex-Anwendungen.

Es fehlen die Visualisierungsfähigkeiten von NDepends, aber es ist ein großer Schritt von dem Versuch, Linkberichte sinnvoll zu machen. Seine Quelle ist dort, also wenn man genug motiviert war, könnte es mit Visualisierungen erweitert werden.




Update: Danke für die stressige Version. Wiederum konnte ich keinen Unterschied sehen, dass ich nur herumrannte. Aber ich fand clever heraus, dass "r" Türmchen fallen lässt, und als ich 20-30 Türme fallen ließ, war die native Version etwas langsamer als die manuelle Version, also lag ich vielleicht falsch. (Ich habe keinen Unterschied in der Speichernutzung gesehen.) Es scheint immer noch so zu sein, als ob die Dinge nativ schneller sein könnten, aber es könnte gut sein, dass es eine spezielle Handhabung von undurchsichtiger Art erfordert.

Da dies akzeptiert wurde, füge ich eine Notiz hinzu, um explizit zu machen, was ich in einem Kommentar zu einer anderen Antwort gesagt habe: Wenn alle Ihre Assets Bitmaps selbst sind, dann ist es nicht überraschend, dass das Zusammensetzen manuell schneller sein kann als Machen Sie native Objekte und überlassen Sie Flash die Arbeit, da der mit Anzeigeobjekten verbundene Overhead wie Ereignisstrukturen entfällt.

Es gibt jedoch Situationen, in denen Dinge manuell ausgeführt werden können, z. B. wenn Vektorinhalte in Bitmaps gerendert werden müssen oder viele animierte Sprites, oder wenn Sie Mausereignisse auf Ihren Schauspielern erkennen müssen (was Sie tun würden müssen Sie manuell tun, vielleicht schmerzlich, wenn Sie Ihre eigenen Compositing machen).

Wenn Sie also nichts tun müssen, was das manuelle Compositing verlangsamt, scheint es definitiv die beste Antwort zu sein, und wenn Sie das tun, dann ist es die beste Möglichkeit, absolut sicher zu sein, beide Ansätze auszuprobieren. (Ein Hybridmodell ist ebenfalls möglich, bei dem Sie eine Ebene nativer Objekte erstellen, die Mausereignisse benötigen, und diese mit einer Schicht manuell zusammengesetzter Bitmaps überlagern oder unterlagern.)





actionscript-3 actionscript code-analysis static-analysis