Otros procesos llaman a GC que ralentiza mi juego

Estoy escribiendo un juego de arcade en tiempo real para Android> = 2.1. Durante el juego no estoy asignando memoria, para no seducir GC. Beacuse si el GC invoca, toma procesador para 70-200ms. El usuario ve esto como "oh no, ese juego está rezagado …" .

Revisé LogCat. Hay un montón de GC_FOR_MALLOC o GC_EXPLICIT. Pero … no de PID de mi proceso! Mi juego no los está causando. Están causados ​​porque otros procesos, que se ejecutan en el fondo. Algunos fondos de pantalla, widgets, radio, correo electrónico, la comprobación del tiempo y otros servicios …

No lo entiendo por completo. Cuando, por ejemplo wallpaper dissapears, su onPause () se llama, supongo. Por lo tanto, debe detener todos sus subprocesos y sin duda no asignar ninguna memoria (o llamar a System.gc ()). Tal vez se ha implementado incorrectamente? No lo sé. Pero hay algunos servicios de Android, que también están causando GC de vez en cuando … Es extraño.

¿Es una gran falla de arquitectura Android <= 2.2? Android 2.3 introduce CG concurrente, que toma menos tiempo.

¿Qué puedo hacer para asegurar que mi juego se ejecute sin problemas?

En primer lugar, las cosas que ve en LogCat serán diferentes de un dispositivo a otro. Si estás seguro de que el GC no viene de tu aplicación, no tienes absolutamente nada que puedas hacer. Usted siempre encontrará el GC haciendo .. algo. Asegúrese de mantener su código limpio y muy lite.

Además, recuerde que en general, en presencia de un recolector de basura, nunca es una buena práctica llamar manualmente al GC. Un GC se organiza en torno a los algoritmos heurísticos que funcionan mejor cuando se deja a sus propios dispositivos. Llamar a la GC manualmente a menudo disminuye el rendimiento.

De vez en cuando, en algunas situaciones relativamente raras, uno puede encontrar que un GC particular lo hace incorrecto, y una llamada manual al GC puede entonces mejorar cosas, funcionamiento-sabio. Esto se debe a que en realidad no es posible implementar un GC "perfecto" que gestione la memoria óptimamente en todos los casos. Tales situaciones son difíciles de predecir y dependen de muchos detalles de implementación sutiles. La "buena práctica" es permitir que el GC funcione solo; Una llamada manual al GC es la excepción, que debe ser prevista sólo después de un problema real de rendimiento ha sido debidamente atestiguado.

No creo que sea una falla en Android <= 2.2. ¿Está sucediendo en las versiones superiores? ¿Lo has probado?

  • Variables que se recolectan basura
  • Obtener la lista de procesos en ejecución y eliminar sus servicios de fondo
  • Detalles técnicos de Android Garbage Collector
  • La interfaz de usuario de aplicación se congela con mensajes de GC
  • Android: GC_FOR_MALLOC causado por un largo evento táctil?
  • ¿Qué significan GC_FOR_MALLOC, GC_EXPLICIT y otros GC_ * en Android Logcat?
  • java.lang.OutOfMemoryError: Límite de sobrecarga de GC superado en Android 1.4
  • Multithreading de Android: WaitForGcToComplete después de enviar la aplicación al fondo
  • SoftReference obtiene recolección de basura demasiado temprano
  • Fuga de memoria de Android ClassLoader
  • ¿Cómo encontrar el origen de un GC_FOR_MALLOC?
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.