AIR App am einfrieren hindern?

[Silver_Surfer]

Hi Leute,

hab mal eine Frage bzw Problem wie kann ich meinem AIR App sagen, dass es nicht einfriert wenn ich zB größerer Schleifen durchlaufe?
Gibts da ein Event was ich werfen kann wie zB "prevent Form Freeze".
Danke euch.

[Nico B.]

Was durchläufst Du denn? Wenn Deine App einfriert hast Du wohl irgendwo irgendwas schlicht und einfach schlecht programmiert?

[Silver_Surfer]

Genau daran liegt es! Nein, z.B. recursive Ordner mit 18000 Dateien durchsuchen.

[thomas_E]

Nein, z.B. recursive Ordner mit 18000 Dateien durchsuchen.

also doch schlecht programmiert

18000 Ordner zu durchsuchen, dauert nunmal seine Zeit! und wenn du Flash sagst, dass er das in einer Schleife auf einmal abarbeiten soll, wird er das auch tun, und es interessiert Flash dabei nicht, ob es währenddessen mit solchen Nebensächlichkeiten wie Benutzereingaben, oder Refresh-Zyklen des OS behelligt wird.
in anderen Sprachen wird sowas über Threading gelöst, da kann der eine Thread schonmal was länger ackern, das hält die anderen Threads aber nicht dabei auf, weiterzuarbeiten.
nur Flash kann kein threading, also musst du das anders lösen.
anderes Thema, selbes Problem: SWF friert ein bei bitmap encoding - Flashforum

Vorschlag:
erstell eine lange todo-liste
und lass Flash immer ~100 Ordner abarbeiten, dann bspw ein Timeout von 10ms.
wenn die Liste durch ist, feuert dein Code ein Event und du machst weiter, mit dem, was du vorhattest (hat ja sicher einen Grund, diese Ordner auszulesen)

[Silver_Surfer]

Danke das werde ich testen..

[Nico B.]

Ich wollte damit auch nur sagen, "beschreib das Problem genauer" und nicht "Du bist doof"

Die Idee von thomas finde ich zb. sehr interessant.

[Silver_Surfer]

Zitat von Nico B.

Ich wollte damit auch nur sagen, "beschreib das Problem genauer" und nicht "Du bist doof"

Die Idee von thomas finde ich zb. sehr interessant.

Ja sorry..war auch eine dumme Antwort von mir.. Ick kenne das halt aus anderen Sprachen, dass man in der Schleife eine Meldung an die App schickt damit diese nicht einfriert...

Aber die Lösung von thomas ist tres bien!
Ich mach jetzt alles in einem Timer mit 10 MS und es geht wunderbar!

[thomas_E]

Threading funktioniert im Grunde genauso, da wird jedem Thread eine gewisse Laufzeit auf der CPU eingeräumt, dann wird sich um den nächsten Thread gekümmert; wenn die Liste durch ist, gehts wieder von vorne los. weiss grad nicht mehr von welcher Instanz das gesteuert wird; vermutlich irgendwo low-level OS!?

hier musst du Flash auch die Möglichkeit geben irgendwas anderes zu machen, bevor es sich wieder um deine Aufgabe kümmert, sonst friert es ein.
in dem o.g. Link hab ich das im Code mit setTimeout implementiert.
ich hatte auch versucht, es so zu bauen:

PHP-Code:

var t:Timer = new Timer(10, 1);
t.addEventListener(TimerEvent.TIMER_COMPLETE, tick);

function tick(e:Event=null):void
{
    //mach was
    t.start();
} 


weil in der Referenz von setTimeout zugunsten von Timern abgeraten wird; aber der Code lief gefühlt langsamer, bei gleicher CPU-Last.

eine weitere Möglichkeit wäre das ganze über ENTER_FRAME aufzurufen. Wenn pro frame zu viel zu erledigen ist sinkt die FrameRate halt, aber die Anwendung friert nicht ein.

was ich noch nicht probiert habe, weil es vom Gefühl her eher nicht funktioniert wären setInterval oder ein durchlaufender Timer. Ich fürchte die halten sich so sehr an ihr timing, dass in den Pausen nicht genug Zeit bleibt, dass die Anwendung flüssig weiterläuft. (müsste ich bei Gelegenheit mal genauer testen)
setTimeout wird hier ja erst nach dem Abarbeiten der Portion ausgeführt, somit ist da tatsächlich eine Pause von 10 ms in denen etwas anderes ausgeführt wird(oder auch nicht)
bei einem interval wären die 10ms die Zeit von start zu start, einschliesslich der Zeit die benötigt wird, um diese Portion abzuarbeiten.

Aber die Lösung von thomas ist tres bien!
Ich mach jetzt alles in einem Timer mit 10 MS und es geht wunderbar!

ah, super. dann muss ich mir das doch mal genauener anschauen, und ggf. mal die Performance vergleichen

ergänzung:
bei allen Lösungen gilt: die Portionen / Zyklus müssen klein genug bleiben, dass sie in < 40 ms abgearbeitet werden können (entspricht 25fps), sonst wird auch hier die Anwendung nicht nur langsamer, sondern friert trotzdem ein.
wenn die Portion jedoch zu klein gehalten wird, dauert der Vorgang ewig, was auch nicht Sinn sein kann.

[Silver_Surfer]

Ich habs jetzt mit einem Timer gelöst, aber du meinst setTimeout ist schneller?

[thomas_E]

wie gesagt, war "nur" gefühlt, hatte keine Benchmarks dazu gemacht.
noch was:

Zitat von Timer.delay

Hinweis: Ein Wert von weniger als 20 Millisekunden für delay wird nicht empfohlen. Die Timer-Frequenz ist auf 60 Bilder pro Sekunde begrenzt. Eine Verzögerung unter 16,6 Millisekunden führt zu Laufzeitproblemen.

bei setTimeout steht da nix zu.

vielleicht hatte es damit was zu tun, vielleicht damit, dass der Timer immer gestartet und beendet werden muss, oder dem Event-System dass dazwischen liegt, ka. vielleicht war es auch nur subjektive Wahrnehmung.