Las buenas prácticas al escribir código Java pueden ser malas prácticas al escribir código Android
AbrahamMe he encontrado con una presentación de Romain Guy y Chet Haase describiendo distintos trucos, técnicas y consejos varios relativos al desarrollo de interfaces de usuario en Android. La charla ya tiene más de un año, no es nada moderno. Pero al menos yo es la primera vez que me la encuentro y me ha impresionado mucho.
La principal lección que he sacado es que muchas de las cosas que podemos considerar como buenas prácticas al escribir código Java normal no son necesariamente buenas prácticas al escribir código Android. Por ejemplo, los recogedores de basura de Java en el escritorio son altamente eficientes, y esto hace que la creación de múltiples objetos pequeños que se van a usar durante poco tiempo en Java no sea problemático; es más, Joshua Bloch lo recomienda en su libro Effective Java. Esto no se aplica a dispositivos Android, donde la creación de estos objetos puede disparar al recogedor de basuras, y si esto sucede en medio de una animación habrá paradas. Romain Guy y Chet Haase recomiendan usar objetos estáticos que sean variables de instancia para evitar la creación de múltiples objetos dentro de métodos.
De un modo similar el uso de Boxing y autoboxig o de varargs producen un montón de objetos intermedios que pueden terminar desencadenando pausas del recogedor de basuras. Siempre que sea posible, es recomendable evitar varargs, y usar "float" en vez de "Float". A este último respecto, tened en cuenta que siempre que añadís un tipo primitivo una colección se convierte en la clase wraper correspondiente.
En resumen, lo que pueden ser buenas prácticas al escribir aplicaciones Java SE puede ser lo contrario al escribir aplicaciones Android. Una interesante lección que he aprendido en esta presentación. Os dejo aquí el video de la presentación:
Reader Comments (4)
Pero eso es porque el recolector de basura de android se lanza en distintos momentos que los de J2SE? O mas bien porque son simplemente menos eficientes? Poque esto ultimo, con procesadores de giga y pico y varios nucleos no deberia ser un verdadero problema! Es más, los procesadores de los moviles de gamas medias / altas deben ser mas o menos de la misma potencia que los que habia cuando Effective Java fue escrito!
Más que tema de eficiencia u otras historias yo creo que es tema de contar con mucha menos memoria, lo que les obliga a dispararse mucho más a menudo. Cuando la memoria de tu heap se mide por docenas, o cientos, de megas crear objetos para desechar pronto no es problema. Cuando se mide en cientos de Kb, o a todo lo sumo unos pocos megas, es otra historia. O al menos esta es mi interpretación; estoy muy lejos de ser un experto en Android.
Abraham no carga la presentación, se te ha olvidado o el CMS se lo ha comido el link o la parte del link a la presentación concreta.
Este tema nos retrotrae a tiempos pasados de Java en donde se recomendaba no crear objetos al tuntun, tiempo después la máquina virtual mejoró muchísimo en la recolección de objetos de corta vida hasta el punto de que se considera una mala práctica usar otras técnicas.
¿En Android? es posible que en algunos aspectos se haya vuelto al mundo Java antiguo, por ejemplo el Lint es una herramienta Android que te regaña cuando creas objetos en los métodos onDraw pues esos métodos se llaman muchísimas veces.
En mi opinión ese es el único contexto en donde la creación de objetos aunque sean de corta de vida puede degradar el rendimiento, en las rutinas gráficas repetitivas, y aunque no puedo ver la presentación estoy seguro que ese es el contexto en el que hablan Romain y Chet, porque ellos son chicos "draw", su mundo gira en el onDraw y en las rutinas de animación y es verdad que ahí las deficiencias se amplifican, pero en general en este ámbito la regla es "haz lo menos que puedas" y "cachea lo que puedas", la creación de objetos es una razón pero lo es cualquier rutina en este ámbito tan crítico. Ahora bien no es lo mismo una aplicación Android convencional que un videojuego, en una aplicación Android convencional es difícil hacerlo muy mal incluso en estos contextos, un videojuego es otra cosa.
Pero en el resto del código yo no veo que una programación Java normal y corriente pueda perjudicar significativamente el rendimiento de una aplicación , es decir cuando se instancia un objeto visual, el crear 1000 objetos Java o 10 una sóla vez en dicha operación que ya no se repite hasta que se crea de nuevo, sinceramente no lo va a notar nadie.
Ahora bien, el vídeo según dices tiene más de un año, actualmente tenemos dual core y quad core y 1Gb y velocidades de más de 1Ghz por cuatro euros/dolares/pesos/soles, la memoria y la potencia va dejando de ser un problema.
Ha debido de ser algún problema temporal con el video; ahora funciona. De todas formas la URL es:
http://www.parleys.com/#st=5&id=2115&sl=0