Llevo un tiempo peleándome con un problema de rendimiento, en una aplicación Flex y quería comentar mi experiencias con quien esté interesado.
El caso es que, pasado un tiempo realizando ciertas operaciones que involucraban la creación y eliminación de hijos(instancias de objetos), la aplicación se ralentizaba de manera notoria. Utilizando el profile del Eclipse, descubrí que habia ciertas instancias que no se estaban eliminando de memoria, aunque en código eran eliminadas, así que me puse a investigar sobre el tema.
Al parecer el recolector de basura(GC) de Flex, sólo elimina los objetos de memoria cuando no existen referencias fuertes sobre el objeto. ¿Y a que se refieren con referencias fuertes? Pues, a listener no eliminados, watchers, e incluso a bindings. Es decir que si realizamos un removeChildren, de objetos que dentro de su lógica tengan algún binding asociado, estos no se borrarán de la memoria…
Bueno, para los que quieran saber más sobre este tema, os dejo un par de enlaces,
http://blogagic.com/163/flex-memory-management-and-memory-leaks
http://www.cubicleman.com/2008/06/11/bindingutilsbindproperty-use-a…
Pero vamos, en resumen, el primer artículo, nos viene a decir que tengamos especial cuidado con el uso de referencias y nos sugiere unas buenas prácticas para evitar estos posibles fallos.
- Asegurarnos de eliminar los eventListeners, o por lo menos habilitar el valor de weakReference a true a la hora de crearlos
- Con los BindingUtils.bindProperty, para versiones anteriores a flex 4.5 no existe la opción de weakReference, así que tendremos que asegurarnos de eliminar esos bindings cuando no los utilicemos. (con algo así)
- Por último nos sugiere el primer artículo, crear una interface para nuestros componentes que nos obligue a implementar un método que se ocupe de solucionar estos temas, para que cada componente individualmente se ocupe de no dejar basura sin recoger y abstraiga al resto.
Bueno, espero que alguno le sirva de algo esta parrafada
y si alguien tiene algo que aportar o corregirme bienvenido sea.

Deja un comentario
Feed de los comentarios de este artículo