Una breve introducción al tunning de aplicaciones flex, mejores practicas y ejemplos.

1. Tunning Flex Apps
Ivan Alvarez
Senior RIA Developer
ivan.alvarez@tidyslice.com

2. Sinópsis
• Open Source.
• Version 4 Beta.
• Alta adopción.

3. Por que Tunning?

4. Sinópsis
• Aplicaciones
• Estables.
• Rápidaz.
• Bajo consumo de memoria y CPU.

5. Como funciona el Flash
Player?

6. Memoria
• Reserva memoria del SO en grandes
grupos(4096 bytes).
• Devuelve recursos al SO través del
Garbage Collector.

7. Garbage Collector
• Conteo de Referencias.
• Cada objeto tiene asociado un contador
de referencias
• Si un objeto tiene 0 referencias sera
candidadato a eliminarse.

8. Garbage Collector
• Mark and Sweep
• Se empieza desde el stage y se recorre la
aplicación siguiendo las referencias
• Se marcan lo objetos que se vayan
encontrando
• Los objetos que queden sin marcar serán
candidatos a eliminarse.

9. Memory Leak
• Si no borramos las referencias a un objeto
y éstas van creciendo, en nuestra aplicación
se producirá un memory leak.
• La aplicación se vuelve mas lenta
progresivamente hasta que se vuelve
inoperante.

10. Elastic Racetrack
• Frame Rate: es la cantidad máxima de veces por
segundo, que el FP redibujará la pantalla.
• Flex solo utiliza 2 Frames.
• 24 FPS es el default.

11. Mejores Prácticas

12. Event Listener
• Strong Listeners(removeEventListener)
• WeakListeners( Precaución)
• addEventListeners( dirección )
• FlexGlobals.topLevelApplication(Flex 4)
• Application.application(Flex 3)

13. Transferencia de Datos
• Uso de protocolo binario: AMF

14. Mejores Prácticas
• Objetos Tipados vs No Tipados
• Uso de Invalidate Methods
invalidateDisplayList().
• Data Binding: Evitar utilizarlo en Data
Transfer Objects.
• Reuso de objetos a traves de pools.

15. Módulos
• Solucion para escalar aplicaciones de gran
tamaño.
• Caracteristica nativa para modularizar
aplicaciones Flex
• Es un conjunto de clases no necesario en el
momento de arranque de la aplicación.
• Carga dinámica de funcionalidades.

16. Modulos
• Reduce el tiempo de startUp.(solo se carga
el shell).
• Uso de memoria inferior, ya que no está
todo el código cargado.
• Fomento de la programación orientada a
Interface -> polimorfismo -> mayor
rendimiento (menor tiempo de
instanciación debido a una cadena de
herencia menor).

17. Módulos
• Shell / Module
• Shell: Código necesario en startUp
• Module: Código necesario on-demand
• Shell carga modules bajo demanda
• Shell puede ofrecer una API de comunicación
unidireccional / bidireccional con los módulos
• Todo basado entre Interfaces debido al
funcionamiento nativo de los
applicationDomains.

18. Demos