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 …
- Android adecuada limpieza / eliminación
- Cómo escuchar eventos de GC en Android
- Cómo explícitamente realizar la recolección de basura
- Garbage Collection causa: MediaPlayer finalizado sin ser lanzado
- ¿Por qué la basura de Android recopila tantas veces con Jacksons ObjectMapper?
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?
- Diferencia entre system.gc () y runtime.gc ()
- 17.8 MiB asignación de montón para un simple "Hello World" proyecto?
- Cómo persistir el miembro estático en las preferencias compartidas cuando está a punto de ser recogido en Android
- Monodroid: Realización de un GC completo
- Android - Constructor de actividad vs onCreate
- Recolector de basura en Android
- Posibilidad de pérdida de memoria no controlada
- ¿Por qué se filtran hilos en Android?
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?
- Fragmentos de Android y su influencia en el rendimiento
- Cómo hacer que las aplicaciones de Android sean accesibles (para personas con discapacidades) con PhoneGap