Algunas actualizaciones: No estamos haciendo nada en la aplicación que no sea escuchar eventos y usar enlaces ... es decir, no ChangeWatchers, no hay sondeo manual ... solo a la espera de eventos. Estamos conectados a FMS todo el tiempo, por lo que hay algunos gastos generales para eso, pero es mínimo. Los enlaces no son muy eficientes en Flex, y hemos descubierto que no es bueno agregar la palabra clave de metadatos [Bindable] directamente a las clases (en gran volumen, con muchas clases). No estamos haciendo mucho de esto, pero es una manera de sacar un poco más rendimiento de su aplicación. Si usa [Bindable (event = "usersUpdated")], tendrá control sobre el enlace, y solo se activará cuando envíe el evento (new Event ("usersUpdated")) dentro de una función de la clase, es decir, su setter para 'usuarios'.
Cualquiera que haya usado System.gc() en Flex o AIR le dirá que la recolección de basura de Flex es una broma. Es una característica parcialmente implementada y nadie confía en ella. También hay trucos para esto ... llámalo dos veces, espera un cuadro, llámalo de nuevo. Puede limpiar tus objetos viejos, pero no cruces los dedos ... Flex hace lo que quiere.
Además, use objetos temporales para disminuir el número de enlaces disparados. En lugar de ...
myUser.location = new Ubicación(); myUser.location.state = "CO"; myUser.location.city = "Denver";
hacer ...
var tempLoc: Localización = nueva ubicación(); tempLoc.state = "CO"; tempLoc.city = "Denver"; myUser.location = tempLoc;
Los antiguos fuegos 3 ataduras a nada ligados a la localización. *, Mientras que el segundo debe sólo el fuego de unión 1 (en realidad, por lo general es extra debido a la forma en Flex maneja.)
enlaces no va a matar a su aplicación hasta que tenga muchos de ellos en una aplicación visualmente rica ... el enlace y la representación parecen ser los trabajos más lentos de Flex.
Otra cosa interesante: crear una nueva aplicación Flex3 en Flex Builder y ejecutarla en el navegador. Nuestras pruebas mostraron que la CPU se mantiene entre el 8-10% en una MacBookPro (cuando la aplicación está inactiva y la ventana del navegador oculta). Nuestra aplicación ahora se ejecuta de manera constante en ~ 20% y mientras aumenta más para manejar los cambios de vista y similares, siempre vuelve a un nivel cercano al 20%. Nuestra preocupación inicial era que había una fuga de memoria o algo que se escapaba y que elevaría la CPU hasta un 40-50% (de nuevo, en el MBP ... todo en relación con esta máquina). Eliminamos todas las referencias a Degrafa y, aunque notamos un buen aumento en el rendimiento, no explicaba todo. Sin embargo, la aplicación Flex vacía fue esclarecedora: Flex en sí consume una CPU del 8-10% en todo momento, incluso cuando está inactivo.
Otro hallazgo más ... si usa Mate, tenga cuidado de cómo maneja las vistas de cambio. Es fácil tener activos disponibles y simplemente ocultar & deshabilitarlos cuando no están siendo utilizados, mediante el uso de un inyector y un enlace en MXML, pero Flex no es muy inteligente a la hora de ocultar/deshabilitar cosas. Lo mejor es crear las vistas sobre la marcha y destruirlas cuando hayan terminado. Aunque la creación inicial puede llevar más tiempo y habrá una espera más larga entre las vistas, use algo de magia de visualización (una barra de progreso, un disco giratorio, etc.) para indicar que la vista se está alternando, espere a la creación completa en la vista y luego desvanecerse en él.
Además, aléjese de ViewStack para aplicaciones visualmente ricas. Administra tu propia pila.
Hasta ahora, este hilo ha superado los problemas de rendimiento básicos comunes a cualquier idioma, pero Flex es un niño muy especial en muchos aspectos ("especial" no siempre se considera algo positivo). Hay innumerables trampas porque está construida sobre una plataforma muy visual, pero está diseñada para RIA, por lo que aunque Flash Player pueda optimizar video, animaciones, etc., no optimizará una aplicación Flex. No espere que las aplicaciones Flex tengan el mismo rendimiento que las aplicaciones Flash. También hay una gran diferencia entre AVM (máquina virtual ActionScript) para AS2 y AS3.
Esto simplemente está arañando la superficie de los problemas de rendimiento y las posibles ganancias en las aplicaciones de Flex. Este es un arte oscuro y es fácil ver por qué.
Code on, ninjas.
he intentado jugar alrededor con la velocidad de fotogramas, pero no tuvo ningún efecto real en el rendimiento. Bajar demasiado la velocidad de fotogramas provocaría que los cambios de la interfaz de usuario se ejecuten demasiado lentamente y no solucionarían los problemas que estamos viendo. – Herms
El problema es que el generador de perfiles afirma que el evento ITSELF está ocupando el 32% del tiempo de CPU (más lo que llama lleva un 84%). Esa es una cantidad de tiempo muy significativa para un evento. Algo está pasando, pero no puedo decir qué. – Herms