ES KAsi UN blog

Blog de Unkasoft, donde hablamos de programación de juegos para móviles, advergaming, marketing móvil, la industria de los videojuegos, metodologías ágiles y todos aquellos temas que nos preocupan en nuestro día a día

23 marzo 2006

Circulo vicioso

Una vez más el problema de la memoria del HEAP y del tamaño del paquete JAR (J2ME) con los recursos. Uno de los mayores problema que tenemos cada día con los teléfonos móviles más pequeños es que no nos vale comprimir al máximo los archivos que se instalan, porque aunque eliminemos la problemática del límite de tamaño de instalación, nos chocamos con el límite de memoria RAM (heap) disponible.

El verdadero problema con la memoria en los teléfonos móviles es que nunca dispones de lo que esperas. Te dicen que tienes n KB para usar de heap, pero nunca cuentas con que tus imágenes comprimidas (PNG…) se tienen que descomprimir y ocupan como un bitmap, que tu archivo JAR se descomprime también, que tus clases java se tienen que cargar en memoria y claro, cuando ejecutas, te comes mucha más memoria de la esperada.

Al final, la solución es cuestión de equilibrio. Si bajas el tamaño del paquete JAR comprimiendo al máximo, y no controlas el contenido, al descomprimirse te encontrarás con una limitación de HEAP. Lo mejor es pensarlo desde el principio, con todos los recursos y el orden en que los vas a manejar en memoria y a destruirlos.

Voy a enumerar una serie de reglas, creo que importantes, que usamos a la hora de evaluar el HEAP que estamos usando con los recursos y que nos están dando buenos resultados:

1 Nunca pienses en el tope de memoria de HEAP especificado por el fabricante. Siempre tendrás menos en el móvil, ya sea por bugs del firmware o por usos internos de la implementación del fabricante.


2Tus imágenes preparadas para pintar ocuparán en memoria siempre la formula:

Imagen (KB) = (ANCHO (pixels) x ALTO (pixels) x COLORES (bytes)) / 1024

Para una imagen de 64 x 64 en una pantalla de 65.535 colores (16 bits = 2 bytes) tendremos = (64 x 64 x 2) / 1024 = 8 KB de HEAP.

Intenta optimizar los tamaños siempre que puedas de cara a tu memoria de HEAP y el número de colores de cara al tamaño de tu archivo JAR.


3El código de tus clases podrían tener que vivir en el HEAP. Recuerda que el uso de una clase necesita de su bytecode en algún sitio, y ese sitio seguramente sea tu querido HEAP. Piensa que las clases descomprimidas irán usando el HEAP cuando las vayas usando. Una buena solución puede ser tener una clase con métodos de un solo uso como cargas y preparaciones, y cuando se finalice de usar, poner todos sus objetos a null para que, en algunos móviles, te saque su código del HEAP por no estar en uso.


4Si crees que tu archivo JAR no puede descomprimirse en tu HEAP, estás muy equivocado. Algunos móviles descomprimirán tu archivo JAR en tu HEAP y si has comprimido a tope, te encontrarás con poco HEAP disponible. Intenta equilibrar el contenido de tu JAR con el HEAP que necesitas. Si no lo equilibras, entrarás en el círculo vicioso entre HEAP y JAR. Otra opción es implementarte un pequeño descompresor para tus recursos (no clases, ni imágenes o sonidos comprimidos) que permita mantenerlos comprimidos. Equilibrar es básico.


5La mayoría de los recursos y clases tienen cabeceras que ocupan espacio de HEAP y de JAR. Cuantos menos archivos de clases y recursos tengas, menos espacio ocuparás. Cuidado con meter todo en una clase o una imagen, cuando los uses podrá desbordar tu HEAP si son muy grandes. Equilibra el número de clases y recursos con su uso en memoria. No es fácil porque hay que analizar la lógica de tu juego para hacer una correcta división, pero te facilitará entrar en móviles pequeños.


6Adapta la disposición de tus gráficos dentro de las imágenes. No ocupa lo mismo en memoria una imagen más vertical que horizontal o cuadrada. Desde hace mucho tiempo se sabe que la forma de crear las imágenes con tus gráficos puede consumir más o menos memoria de HEAP. A veces, poner en vertical los frames de tus sprites puede que mejoren tu uso de memoria. Experimenta hasta encontrar la mejor combinación y únelo a tu equilibrio entre el número las imágenes de recursos.


7Usa herramientas de optimización de imágenes como PNGOUT, herramientas de optimización de archivos JAR como JARG (Java Archive Grinder) o KZIP. Con esto conseguirás mejorar el tamaño de tu archivo JAR, pero recuerda equilibrarlo con tu espacio de HEAP. El uso de ofuscadores es obligatorio tanto para reducir el tamaño del JAR como el espacio ocupado por el Bytecode en el HEAP. Algunos ofuscadores optimizan más que otros, pero también algunos móviles no aceptan bien grandes clases con ciertos tipos de ofuscado, usa el ofuscador más adecuado en cada caso si puedes.


8 La precarga de imágenes y sonidos puede acelerar la ejecución de tus juegos, pero también puede limitar el tamaño de tu lógica dentro del HEAP. Equilibra tus recursos cacheados en memoria con la lógica de tu juego. Aunque no todos los recursos estén cacheados, puedes hacer algunos efectos durante el juego para que el jugador no se de cuenta de los momentos de carga y preparación. Carga y descarga recursos en memoria de HEAP y usa trucos durante el juego para que el jugador no se de cuenta. Cargar desde el archivo JAR es lento y tener las imágenes preparadas para pintar es caro de cara al HEAP; una buena idea consiste en tener algunos archivos de imágenes (PNG, …) en arrays en memoria como si tuvieras una cache y cuando los necesites, prepararlos como imagen bitmap y pintarlos. Esto es mucho más rápido que ir directamente al jar a buscarlos y son recursos que ocupan poco en el HEAP al estar comprimidos en su formato original (PNG, …). Lo mismo puedes hacer con algunos recursos de audio.


9Tu teléfono dispone de una memoria persistente y en caso de J2ME puedes grabar datos en sus Record Store. En algunos casos, si tus recursos y lógica no caben por la limitación de archivo JAR, puedes intentar meter la lógica en el JAR y que al iniciar el juego, el propio juego se descargue los recursos que le falten y los guarde en Record Store. Usamos teléfonos móviles y se pueden conectar a la red, debemos usar estas capacidades para mejorar nuestros juegos. Poco a poco los jugadores irán asimilando que las aplicaciones móviles necesitan conectarse a la red para actualizarse. La creación y acceso a varios Record Store puede ser lenta, pero el acceso y grabación de registros de un Record Store es bastante rápida. Organiza tus contenidos de tal manera que puedas leerlos sin que el usuario note retrasos durante el juego. Podrás crear juegos bastante impactantes en teléfonos limitados. Recuerda que también hay límites para los Record Store de una MIDlet.


10Equilibrio y diseño. Todo es cuestión de equilibrio y depende de cómo diseñemos nuestro videojuego. Si somos capaces de diseñarlo basándonos en el equilibrio entre JAR y HEAP, conseguiremos meter una gran cantidad de contenidos y crearemos pantallas y niveles muy completos para el jugador. Cuando vayas a hacer un videojuego para el móvil, piensa siempre en este equilibrio para evitarte dolores de cabeza posteriores. Esta regla también vale para otras plataformas porque al final a más capacidad, más contenidos metemos y siempre necesitamos un equilibrio.

Etiquetas: ,


Comentarios:
Publicar un comentario

Links to this post:

Crear un enlace



<< Home

This page is powered by Blogger. Isn't yours?