studio - ¿Por qué Android no usa más enumeraciones?

tag android

Question

Empecé a gustarme mucho el uso de C # y las enumeraciones de Java en mi código por varias razones:

• Son mucho más seguros en cuanto a tipos que enteros, cadenas o conjuntos de indicadores booleanos.
• Conducen a un código más legible.
• Es más difícil establecer una enumeración en un valor no válido que una int o una cadena.
• Facilitan el descubrimiento de los valores permitidos para una variable o parámetro.
• Todo lo que he leído indica que funcionan tan bien como los enteros en C # y en la mayoría de las JVM.

Sin embargo, el marco de Android tiene numerosos casos en los que se deben pasar banderas de varios tipos, pero ninguno de ellos parece usar enumeraciones. Un par de ejemplos en los que creo que su uso sería beneficioso son Toast.LENGTH_SHORT / Toast.LENGTH_LONG y View.GONE , View.VISIBLE , etc.

¿Por qué es esto? ¿Las enumeraciones funcionan peor que los valores enteros simples en Dalvik? ¿Hay algún otro inconveniente del que no tengo conocimiento?

Answer 1

Los enteros son más pequeños y requieren menos sobrecarga, algo que todavía importa en los dispositivos móviles.

Answer 2

Un colega mío realizó una pequeña prueba con respecto a esta situación. Él auto generó una class y una enum con la misma cantidad de "enumeraciones". Creo que generó 30000 entradas.

Los resultados fueron:

• .class para la class era aproximadamente 1200 KB
• .class para la enum era aproximadamente 800 KB

Espero que esto ayude a alguien.

Answer 3

Esta respuesta está desactualizada a partir de marzo de 2011.

Los enums se pueden usar en Froyo y hasta de acuerdo con esta respuesta ( ¿Por qué se evitó la eliminación de los enunciados donde solo se necesitan Ints de los consejos de rendimiento de Android? ) De un miembro del equipo de Android VM (y su blog ).

Respuesta anterior:

La recomendación oficial del equipo de Android es evitar enums siempre que puedas evitarlo:

Los enum son muy convenientes, pero desafortunadamente pueden ser dolorosos cuando el tamaño y la velocidad importan. Por ejemplo, esto:

public enum Shrubbery { GROUND, CRAWLING, HANGING }

agrega 740 bytes a su archivo .dex en comparación con la clase equivalente con tres entradas finales estáticas públicas. En el primer uso, el inicializador de clase invoca el método en objetos que representan cada uno de los valores enumerados. Cada objeto obtiene su propio campo estático, y el conjunto completo se almacena en una matriz (un campo estático llamado "$ VALUES"). Eso es una gran cantidad de código y datos, solo por tres enteros. Además, esto:

Shrubbery shrub = Shrubbery.GROUND;

causa una búsqueda de campo estática. Si "TIERRA" fuera una int final estática, el compilador la trataría como una constante conocida y la alinearía.

Fuente: Evita los enums donde solo necesitas Ints