Flash Lite Crash - Imposible abrir. Archivo dañado.
3 02 2008A primera vista, lo primero que te viene a la cabeza es un problema con las versiones del swf que estás intentando abrir y el player que estás usando… luego si habrá compilado bien… pero en realidad en el caso que os quiero comentar, no tiene absolutamente nada que ver (aaahh que bien vendría que los códigos y mensajes de error arrojados por el player fueran mejor redactados y más concretos y afinados…).
El problema viene originado por el uso masivo de degradados. En la inmensa mayoría de tips o tutoriales sobre desarrollo de gráficos para flash lite, viene indicado que el uso de transparencias y degradados ha de ser evitado u optimizado al máximo. La razón? Aquí la tenéis en el ejemplo que os comento. Un uso totalmente incorrecto de esta característica en los gráficos de nuestra aplicación puede ocasionar un salida inesperada de la aplicación sin posibilidad de recuperarse.
Existen muchas maneras de optimizar los gráficos, simplificando las formas, usando rellenos en vez de líneas, emulando degradados con rellenos sólidos en diferentes pasos progresivos.. todas ellas pueden ayudar no solo a que gráficamente logremos un resultado similar e incluso idéntico en la pantalla de un móvil (no olvidemos del tamaño en el que estamos viendo los gráficos, que hace que determinados detalles puedan ser omitidos) sino a que nuestra aplicación RINDA MEJOR y sea MÁS ESTABLE.
Os detalle el ejemplo que me ha causado el error, y la manera de solucionarlo:
37 rellenos agrupados independientemente con degradado
7 rellenos (originalmente líneas) con degradados
74 rellenos sólidos agrupados de forma independiente
Con esto el player rompía en cuanto llegaba al fotograma en el que se encontraba el gráfico (el swf carga correctamente, solo rompe cuando tiene que renderizarlo en pantalla.
Y finalmente quedó:
0 degradados
5 rellenos en total
Os preguntareis como he podido tener tan pocos rellenos. Evidentemente en cada caso será posible o no, pero el mayor cambie es la agrupación. En mi experiencia es muchísimo mejor tener un relleno más grande que muchos rellenos pequeños, es decir, evitar en la medida de lo posible la agrupación por separado a la hora de la publicación final (durante el desarrolo puede interesar tenerlo todo agrupado a partes…).
Con esto no solo no da el error, sino que le puedo aplicar animaciones de alpha y de movimiento con resultados buenos en un N95.
Ya sabéis… optimizar al máximo vuestros gráficos!! os ahorrarán dolores de cabeza!
todo esto en mapa de bits ? , pues eran muchas lineas….y rellenos jiji
La cuestion es, ¿si quieres hacer una aplicacion que se adapte a todos los tamaños de pantalla?
El mapa de bits podría quedar un poco destrozado según en qué proporciones no?
Evidentemente para vectores muy complejos el primer paso a pensar es en meter un mapa de bits… pero en ocasiones esa no es solución
Saludos!
yaaa jeje era la coña, yo personalmente siempre me cuelo hacerlos por separados y siempre tengo que volver a optimizar y optimizar, me encanta ir corriendo al grano, al code….
Buen apunte.