Optimización de AndEngine juego

Estoy usando java + AndEngine en mi juego.

Durante el juego tengo algunas heladas, busqué la información y encontré algunos pasos para optimizar el rendimiento del juego:

  1. Evite GC (recolector de basura) para ser llamado en la acción principal en el juego:
    A) no crear objetos durante el juego;
    B) no crear objetos innecesarios;
  2. Optimizar el código que se repite con mucha frecuencia

He seguido estos pasos, pero nunca menos tengo algunas heladas durante el juego.

Ahora estoy creando y cargando todas las texturas antes de que el juego comenzara y no las descargue, ¿es una mala idea? ¿Cómo puedo optimizar el proceso de juego? Tal vez tengo que liberar toda la memoria posible antes de la actividad principal y luego volver a cargarlos después de cada nivel?

  1. Reduzca el tamaño de la textura.
  2. Reduzca los interruptores de textura (también utilice spritesheets, para que la textura deba cambiarse lo menos posible)
  3. Utilice texturas de menor calidad (RGBA4444 o RGB565 en lugar de RGBA8888).
  4. Llame a setIgnoreUpdate donde la entidad no necesita actualizaciones.
  5. Utilice SpriteBatches si es posible .

FYI: La próxima versión de AndEngine (a mediados de diciembre) se divierte GLES2 por lo que tiene muchas más posibilidades de mejorar el rendimiento con Shaders y Entidades personalizadas.

También ejecutará el oleoducto de inicio (onLoadEngine / onLoadResources / onLoadScene / onLoadComplete) en el primer fotograma del GL-Thread, en lugar de bloquearlo, en el subproceso UI (directamente en onCreate).

También le permite descargar fácilmente las etapas de la tubería en Hilos, sin romper la tubería como un todo. Habrá una subclase muy simple de implementar BaseGameActivity que muestra un ProgressDialog determinado mientras se ejecutan las etapas del pipeline. Las entidades aparecerán en la pantalla cuando estén conectadas a la escena.

En general, esto significa que los tiempos de carga reales se reducen y, lo que es más importante, los tiempos de carga del fieltro se reducen significativamente. Crear una pantalla de carga es trivialmente fácil, en contraposición al dolor que era antes.

Puede aumentar el rendimiento con AndEngine: Uso del conjunto de objetos http://c0deattack.wordpress.com/2011/01/06/andengine-using-the-object-pool/

Es probable que vaya a necesitar publicar alguna información más específica sobre su juego, pero una sugerencia es asegurarse de que está reutilizando sprites y objetos. Por ejemplo, si su juego tiene algún tipo de objeto que se genera repetidamente (enemigos que vuelan al azar, viñetas, elementos de fondo repetitivos) trate de pensar en la cantidad máxima de ese objeto que necesitará en la pantalla al mismo tiempo y luego cree que muchos Antes de que empiece el juego, cargando y restableciéndolos según sea necesario.

Por ejemplo mi juego utiliza enemigos que "al azar" volar desde la parte superior de la pantalla. Al principio estaba haciendo un nuevo enemigo con cada llamada, pero ahora tengo un ArrayList que contiene sólo 6 enemigos en total que se reutilizan y se mueven alrededor de cientos de veces cada uno. Esto resultó en una enorme ganancia de rendimiento para mí, especialmente en sesiones de juego más largas. Esto se relaciona con la optimización del GC, pero es algo que quizás no tengas que optimizar antes.

La importancia de perfilar su código primero antes de hacer optimizaciones preventivas no puede ser exagerado. No tiene mucho sentido optimizar todos los sprites, etc. si estás unido a la GPU (esto es poco probable, pero como estás usando GLES2.0 y la tubería programable, y como no sabemos cómo has escrito el código GLSL, es posible ).

Hay algunas herramientas que puede utilizar para perfiles, ya que hay diferentes cosas para el perfil de.

Para la creación de perfiles de memoria, puede utilizar el DDMS y traceview para verificar la asignación de memoria y la frecuencia con la que se va a llamar al GC. Esta pregunta de SO tiene detalles:

¿Cómo puedo configurar mi aplicación de Android?

Respecto al código de ejecución, siempre puede programarlo usted mismo y escribir los resultados en el archivo de registro. Es un poco de trabajo intensivo, pero probablemente ya sabe donde su propio código es potencialmente lento.

El enfoque que estoy usando es cargar todas las texturas necesarias antes de que empiece el nivel. Cuando vaya al siguiente nivel, debe descargar sólo las texturas de los objetos que no se necesitan en el siguiente nivel. Otros, como el marcador o el fondo principal, no deben cargarse. Y por supuesto tienes que descargar todas tus texturas en la actividad de tu actividad. Es cierto, que en primer lugar debe optimizar el código de bucle, por ejemplo, no debe acceder a ningún recurso durante un bucle, trate de buscarlos todos antes de iniciar un bucle.

Esto Definitivamente mejorará el rendimiento de su juego: mantener el tema por defecto de renderizado todo el tiempo. Aquí hay un tutorialhttp: //www.andengine.org/forums/tutorials/andengine-performance-tip-of-the-day-t810.html

  • Mejores Prácticas de Android - Comunicación entre Actividad y Fragmentos
  • El menú deslizante de Android bloquea la interfaz de usuario
  • La aplicación o la actividad lleva tiempo para cargarse algunas veces
  • Métodos estáticos o Singletons rendimiento-sabio (Android)?
  • Cargar sólo parte de un archivo de mapa de bits en Android
  • ¿Cuál es la principal ventaja y la desventaja de "no mantener las actividades" en android
  • WebView no carga la página web
  • Velocidad de inicio en startActivity
  • Problema "La prueba del repositorio tiene un error" al intentar importar el proyecto de bitbucket al android studio
  • ¿Por qué los pesos anidados son malos para el rendimiento? ¿Alternativas?
  • Tiempo inactivo de actividad para ActivityRecord
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.