Una aplicación Android debe ser rápida y eficiente, teniendo en cuenta
el poder de procesamiento, almacenamiento de datos, pantalla más
pequeña, y la vida de la batería limitada.
Hay que tener en cuenta que aunque la aplicación funcione bien en el
emulador, no lo hará igual en el dispositivo. Se debe intentar crear un
código eficiente, para garantizar el mejor rendimiento posible en una
variedad de dispositivos móviles.
Hay dos reglas básicas para sistemas con recursos limitados:
– No realizar trabajos que no sean indispensables.
– No utilizar memoria si puede evitarlo.
Evitar la creación de objetos
Creación de objetos nunca es gratuita, por lo tanto, se debe evitar la creación de
instancias de objetos que no se necesitan.
debe tratar de ser lo más eficiente posible.)
En general, evitar la creación de objetos temporales si es posible. Menor número de
objetos creados significa menos frecuente la recolección de basura, que tiene un
impacto directo en la experiencia del usuario.
Ejemplos:
– Al extraer cadenas de una entrada es mejor devolver una subcadena y no crear una
copia. Se crea un nuevo objeto pero comparten el char[].
– Si un método devuelve una cadena que será añadida a un StringBuffer, cambiemos
la implementación para que el método añada la cadena, en lugar de crear un objeto
temporal.
– Un array de ints es mejor que uno de Integers e igualmente para cualquier tipo
primitivo.
– Es mejor dos arrays (Foo[], Bar[])paralelos de objetos que uno simple que los
almacene (Foo, Bar).
Utilice métodos nativos
Cuando se trabaja con cadenas, utilice métodos como String.indexOf(),
String.lastIndexOf(), ya están implementados en C/C++ y es más rápido que
realizar lo mismo con un bucle usando java.
Elegir Virtual en lugar de Interface
Map myMap1 = new HashMap();
HashMap myMap2 = new HashMap();
Normalmente elegiríamos el Map, ya que permitiría utilizar cualquier otra interfaz del
mapa, pero no es una buena práctica para los sistemas integrados. Llamar a través
de una referencia a la interfaz puede tomar más del doble que una llamada a un
método virtual a través de una referencia concreta.
Elegir Satic en lugar de Virtual
Si no necesita acceder a los métodos de un objeto, hazlos estáticos. Se le puede
llamar más rápido, ya no requiere una tabla de métodos virtuales indirectos.
Evitar métodos Getters/Setters
Las llamadas a métodos virtuales son caros, y debemos saber que dentro de una clase siempre se
debe acceder a sus campos directamente.
Cachear campos de búsqueda
Acceder a los miembros de un objeto es mucho más lento que acceder a variables locales.
for (int i = 0; i < this.mCount; i++)
dumpItem(this.mItems[i]);
Se debería escribir:
int count = this.mCount;
Item[] items = this.mItems;
for (int i = 0; i < count; i++)
dumpItems(items[i]);
Declarar constantes como final
El compilador genera un método de inicialización de clase, llamado <clinit>, que se ejecuta cuando
la clase es usado por primera vez.
Al declararlos final que no necesitan la llamada a <clinit> ya que son gestionadas directamente
por la máquina virtual.
Uso prudente de la sintaxis en bucles for
Correcta
public static void one() {
int sum = 0;
Foo[] localArray = mArray;
int len = localArray.length;
for (int i = 0; i < len; i++) {
sum += localArray[i].mSplat;
}
}
Incorrecta
public static void two() {
int sum = 0;
for (Foo a: mArray) {
sum += a.mSplat;
}
}
Mejorar la sintaxis de un bucle se comporta bien con los arrays, pero hay que tener cuidado cuando se
utiliza con objetos Iterable ya que existe la creación de objetos adicionales.
Evitar Enums
Las enumeraciones son muy convenientes, pero por desgracia puede ser
inconveniente cuando el tamaño y la velocidad son limitadas.
Evitar Float
Antes del lanzamiento de la CPU Pentium, las operaciones se basaban en cálculos de
enteros. Actualmente la práctica común en los sistemas de escritorio es el uso de
punto flotante.
Lamentablemente, procesadores integrados con frecuencia no tienen soporte de
hardware punto flotante, por lo que todas las operaciones de «flotar» y «doble» se
realizan en el software.