Cambiando el estilo de codificación debido al rendimiento del Android GC, ¿qué tan lejos está demasiado lejos?

Question

Sigo escuchando que las aplicaciones de Android deben tratar de limitar el número de objetos creados para reducir la carga de trabajo en el recolector de basura. Tiene sentido que no desee crear números masivos de objetos para rastrear en una huella de memoria limitada, por ejemplo, en una aplicación de servidor tradicional crear 100.000 objetos en pocos segundos no sería desconocida.

El problema es ¿cuánto debo tomar esto? He visto toneladas de ejemplos de aplicaciones de Android que dependen del estado estático para supuestamente "acelerar las cosas". ¿Aumenta realmente la cantidad de instancias que deben ser recolectadas de basura de decenas a cientos? Me imagino cambiando mi estilo de codificación para crear ahora cientos de miles de objetos como los que podría tener en un servidor Java-EE completo pero depender de un montón de estado estático para (supuestamente) reducir la cantidad de objetos que se recolectan como basura parece impar.

¿Cuánto es realmente necesario cambiar su estilo de codificación para crear aplicaciones de rendimiento de Android?

Answer 1

El consejo de "evitar asignación" es generalmente con respecto a los bucles del juego. El VM tiene que hacer una pausa para recoger basura, y no quieres que eso suceda mientras tu juego esté animando a 30 fps. Si no asigna ningún objeto, la VM no necesitará recolectar basura para liberar memoria. Si tiene un juego que necesita ejecutarse sin interrupciones visibles para el usuario, entonces debería considerar cambiar el código en las partes relevantes para minimizar o eliminar la asignación.

Si está haciendo una aplicación que contenga recetas o muestre fotos, no me preocuparía; el hipo del GC no es algo que el usuario probablemente note.

Las futuras mejoras en el GC Dalvik (por ejemplo, la colección generacional) deberían hacer que este no sea un problema.

Answer 2

Yo diría que realmente depende de lo que está haciendo y cuál es su estilo de codificación ahora. Siempre es necesario tener en cuenta las limitaciones de hardware de un dispositivo móvil y programar en consecuencia, pero una vez más, es una buena práctica ser consciente de eso, sin importar dónde se ejecutará su aplicación. Si está haciendo muchos cálculos muy intensivos que necesitan actualizarse en tiempo real o algo así como un juego, entonces puede considerar usar el NDK, pero si solo está haciendo cosas normales impulsadas por el usuario, no debería ser tan malo. . Mi consejo sería intentar ser frugal, pero no preocuparse demasiado por la optimización hasta que tenga una idea de cómo funciona.