Voy a seguir la respuesta de @ Juan: GC debe considerarse desde cero como un aspecto crítico del diseño de la aplicación. Si crea un objeto, debe tener en cuenta cada referencia al mismo, eliminar cada referencia y anularla para que marque correctamente @. Si hace referencia a ese objeto en una matriz, eso cuenta, si lo hace referencia en un oyente, eso cuenta, si lo hace a través de una variable local, eso también cuenta (aunque solo durante la vida de la función), si simplemente está en el lista de visualización, que definitivamente cuenta, y así sucesivamente.
Voy a escribir mis instrucciones de eliminación de escuchas antes de agregarlas solo para asegurarme.
Casi siempre escribiré un método público destroy() para que cualquier objeto maneje las jerarquías internas de los objetos (las llamadas parentales destroy en child, que, a su vez, destruyen cualquier elemento secundario, etc.). Simplemente eliminar/anular un padre sin hacerlo a cada niño es una gestión de GC pobre.
Y si realmente tiene alguna duda de que la fuga de mem ha surgido, trace el Sistema.totalMemory sólo para asegurarse de:
var mem:String = Number(System.totalMemory/1024/1024).toFixed(2) + ‘Mb’;
trace(mem); // eg traces “24.94Mb”
Medio - acaba de ser metódico en ello - no es una ciencia exacta, pero hay que tener cuidado.
Saludos -
@ e incluso si lo hace, flash hace su propia decisión acerca de cuándo realmente hacer un barrido. Lo mejor que podemos hacer es garantizar que un objeto esté correctamente marcado y confiar en que se tratará de manera eficiente.
¿Es esta una pregunta de tarea o algo? – davr
No, pero lo planteé como si fuera un jaja ... La idea es tener un buen ejemplo "goto" cuando piense en pérdidas de memoria en general. Un buen 'antipatrón', por así decirlo. – Skawful