¿Forzar la recolección de basura en AS3?

¿Es posible forzar programáticamente una ejecución completa de recolección de basura en ActionScript 3.0?

Digamos que he creado varios Objetos de visualización con EventListeners y que algunos de los DO han sido eliminados, algunos de los EventListeners se han activado y eliminado, etc. … ¿Hay alguna manera de forzar la recolección de basura para que se ejecute y recostackr todo lo que es disponible para ser recogido?

Sí, es posible, pero generalmente es una mala idea. El GC debería tener una mejor idea de cuándo es un buen momento para correr de lo que debería, y excepto en un caso muy específico, como que acaba de usar 500MB de memoria y necesita recuperarlo lo antes posible, no debe llamar al GC tú mismo.

En Flash 10, hay un método System.gc() que puede llamar (pero no lo haga, consulte más arriba): tenga en cuenta que System.gc () solo funciona en la versión de depuración de Flash player 10+.

En Flash 9, existe una forma no admitida de forzarlo a través de un comando LocalConnection impar, pero puede no funcionar en todas las versiones. Ver esta publicación de Grant Skinner.

Hay una nueva API para decirle al CG que podría ser un “momento relativamente bueno” para recostackr.

Consulte los documentos de la API de Adobe para System.pauseForGCIfCollectionImminent

Y también esta publicación de blog de Adobe poco después de que se introdujera el método en la versión 11 del reproductor

El método toma un argumento de “inminencia”; básicamente, alimentas en un número bajo (cerca de 0.0) si realmente quieres que el recostackdor se ejecute, incluso si no ha habido mucha actividad (actualmente medida por bytes asignados) desde la última colección, y alimentas un gran número ( cerca de 1.0) si solo desea que se produzca la pausa de recostackción si ya estuviéramos cerca del punto en el que se realizaría una recostackción.

La motivación aquí es para situaciones en, por ejemplo, juegos en los que desee cambiar el punto en el que los GC pasan en una pequeña cantidad, por ejemplo, hacer GC durante un cambio de nivel en el juego, en lugar de dos segundos después de que el jugador comenzó a explorar el nivel.

Un detalle muy importante: esta nueva API es compatible tanto con Release como con Debugger Flash Runtimes. Esto lo hace superior a llamar a System.gc ().

Para todas las versiones publicadas actualmente, System.gc () solo funciona en la versión de depuración del reproductor Flash y ADL (el entorno de depuración para las aplicaciones de AIR). Flash Player 10 beta actualmente funciona en todos los sabores.

Estoy de acuerdo con Davr, es una mala idea. El tiempo de ejecución generalmente tendrá una mejor idea que tú.

Además, los detalles de cómo funciona el recolector de basura es un detalle de implementación sujeto a cambios entre las versiones de Flash Player. Entonces, lo que funciona bien hoy no tiene garantía de funcionar bien en el futuro.

Como otros dijeron: no intentes GC manualmente, hay hacks pero no es seguro.

Debería tratar de reciclar objetos cuando pueda; ahorrará mucha memoria.

Esto se puede aplicar, por ejemplo, a BitmapDatas (borrar y reutilizar), partículas (eliminar de la pantalla y reutilizar).

Tengo un comentario sobre los que dicen que nunca se debe hacer GC manualmente. Estoy acostumbrado a la administración manual de memoria en C ++ y prefiero compartir mucho sobre GC, pero de todos modos.

Hay un caso específico en el que no puedo encontrar otra solución que no sea un GC. Considere: Tengo una clase DataCache, la forma en que funciona es que mantiene los objetos de resultados para ciertas llamadas a métodos que envían eventos actualizados al actualizar / recibir datos. La forma en que se actualiza el caché es simplemente limpiar todos los resultados y enviar el evento que causa que los oyentes restantes vuelvan a solicitar sus datos y los oyentes que salieron del scope no deben volver a realizar la solicitud, lo que elimina los resultados innecesarios. Pero, al parecer, si no puedo obligar a todos los oyentes que todavía cuelgan esperando a que el GC se limpie inmediatamente antes de enviar el evento “preguntar de nuevo a los datos”, los oyentes que cuelgan solicitarán datos innecesariamente. Como no puedo eliminar EventListener porque AS3 no tiene destructores, no veo otra solución fácil que forzar un GC para asegurarme de que ya no haya escuchas colgantes.

(Editar) Además de eso, no puedo usar removeEventListener de todos modos para el enlace que se configuraron en mxml, por ejemplo (usando mi clase DataCacher personalizada que maneja remoteobj)

  

Cuando se cierra la ventana emergente que contiene esta cuadrícula de datos, es de esperar que se destruyan los enlaces. Aparentemente ellos viven y siguen. Hmm, no debería doblar destruir todas las vinculaciones (es decir, eventlisteners) de un objeto cuando se está marcando para GC porque se borró la última referencia. Eso solucionaría un poco el problema para mí.

Al menos es por eso que creo, todavía soy un principiante en Flex por lo que cualquier pensamiento sería apreciado.

 try { new LocalConnection().connect('foo'); new LocalConnection().connect('foo'); } catch (e:*){ trace("Forcing Garbage Collection :"+e.toString()); } 

Si es necesario, llamar al gargabe collector podría ser útil … por lo tanto, debe tener cuidado de cómo y cuándo lo hace, pero no hay duda de que hay ocasiones en que es necesario.

por ejemplo, si tiene una aplicación que es modular, cuando cambie de una vista a otra, todos los objetos eliminados podrían representar una gran cantidad de memoria que debería estar disponible lo más rápido posible, solo necesita tener el control del variables y referencias que está eliminando.

el reciclaje realmente no ayuda. Usé un cargador que cargó repetidamente el mismo jpg cada 500 ms. el administrador de tareas aún informó un aumento continuo de la memoria.

solución probada y probada aquí.

http://simplistika.com/as3-garbage-collection/