¿Debo evitar estrictamente el uso de enumeraciones en Android?

Solía ​​definir un conjunto de constantes relacionadas como Bundleclaves juntas en una interfaz como la siguiente:

public interface From{
    String LOGIN_SCREEN = "LoginSCreen";
    String NOTIFICATION = "Notification";
    String WIDGET = "widget";
}

Esto me proporciona una forma más agradable de agrupar constantes relacionadas y usarlas haciendo una importación estática (no implementaciones). Sé Androidmarco también utiliza las constantes en la misma manera como Toast.LENTH_LONG, View.GONE.

Sin embargo, a menudo siento que Java Enumsproporcionan una forma mucho mejor y poderosa de representar la constante.

Pero hay un problema performence en el uso enumsde Android?

Con un poco de investigación terminé confundido. A partir de esta pregunta "Evitar enumeraciones donde solo necesita Ints" se eliminó de las sugerencias de rendimiento de Android, queda claro que Googlese eliminó "Evitar enumeraciones" de sus sugerencias de rendimiento, pero de sus documentos de capacitación oficiales Tenga en cuenta la sección de sobrecarga de memoria que dice claramente: "Enums a menudo requieren más del doble de memoria que las constantes estáticas. Debes evitar estrictamente el uso de enumeraciones en Android. " ¿Sigue siendo válido? (Por ejemplo, en Javaversiones posteriores a la 1.6).

Un problema más que observé es enviar a enumstravés del intentsuso Bundle. Debería enviarlos serializando (es decir putSerializable(), creo que es una operación costosa en comparación con el putString()método primitivo , aunque lo enumsproporciona de forma gratuita).

¿Alguien puede aclarar cuál es la mejor manera de representar lo mismo Android? ¿Debo estrictamente evitar el uso enumsde Android?

Úselo enumcuando necesite sus características. No lo evites estrictamente .

La enumeración de Java es más poderosa, pero si no necesita sus características, use constantes, ocupan menos espacio y pueden ser primitivas en sí mismas.

Cuándo usar la enumeración:

• verificación de tipo: puede aceptar solo los valores enumerados y no son continuos (vea a continuación lo que llamo continuo aquí)

• sobrecarga de métodos: cada constante de enumeración tiene su propia implementación de un método
  

  public enum UnitConverter{
      METERS{
          @Override
          public double toMiles(final double meters){
              return meters * 0.00062137D;
          }
  
          @Override
          public double toMeters(final double meters){
              return meters;
          }
      },
      MILES{
          @Override
          public double toMiles(final double miles){
              return miles;
          }
  
          @Override
          public double toMeters(final double miles){
              return miles / 0.00062137D;
          }
      };
  
      public abstract double toMiles(double unit);
      public abstract double toMeters(double unit);
  }
  

• más datos: su única constante contiene más de una información que no se puede poner en una variable

• datos complicados: sus métodos de necesidad constante para operar con los datos

Cuando no usar enum:

• puede aceptar todos los valores de un tipo, y sus constantes contienen solo los más utilizados

• puedes aceptar datos continuos
  

  public class Month{
      public static final int JANUARY = 1;
      public static final int FEBRUARY = 2;
      public static final int MARCH = 3;
      ...
  
      public static String getName(final int month){
          if(month <= 0 || month > 12){
              throw new IllegalArgumentException("Invalid month number: " + month);
          }
  
          ...
      }
  }
  

• para nombres (como en tu ejemplo)
• para todo lo demás que realmente no necesita una enumeración

Las enumeraciones ocupan más espacio

• una sola referencia a una constante de enumeración ocupa 4 bytes
• cada constante de enumeración ocupa un espacio que es una suma de los tamaños de sus campos alineados a 8 bytes + sobrecarga del objeto
• la clase enum en sí ocupa algo de espacio

Las constantes ocupan menos espacio

• una constante no tiene una referencia, por lo que es un dato puro (incluso si es una referencia, la instancia de enum sería una referencia a otra referencia)
• las constantes se pueden agregar a una clase existente; no es necesario agregar otra clase
• las constantes pueden estar en línea; trae características extendidas en tiempo de compilación (como verificación nula, búsqueda de código muerto, etc.)

Si las enumeraciones simplemente tienen valores, debe intentar usar IntDef / StringDef, como se muestra aquí:

https://developer.android.com/studio/write/annotations.html#enum-annotations

Ejemplo: en lugar de:

enum NavigationMode {NAVIGATION_MODE_STANDARD, NAVIGATION_MODE_LIST, NAVIGATION_MODE_TABS} 

tu usas:

@IntDef({NAVIGATION_MODE_STANDARD, NAVIGATION_MODE_LIST, NAVIGATION_MODE_TABS})
@Retention(RetentionPolicy.SOURCE)
public @interface NavigationMode {}

public static final int NAVIGATION_MODE_STANDARD = 0;
public static final int NAVIGATION_MODE_LIST = 1;
public static final int NAVIGATION_MODE_TABS = 2;

y en la función que lo tiene como parámetro / valor devuelto, use:

@NavigationMode
public abstract int getNavigationMode();

public abstract void setNavigationMode(@NavigationMode int mode);

En caso de que la enumeración sea compleja, use una enumeración. No está tan mal.

Para comparar enumeraciones frente a valores constantes, debe leer aquí:

http://hsc.com/Blog/Best-Practices-For-Memory-Optimization-on-Android-1

Su ejemplo es de una enumeración con 2 valores. Se necesitan 1112 bytes en un archivo dex en comparación con 128 bytes cuando se utilizan enteros constantes. Tiene sentido, ya que las enumeraciones son clases reales, a diferencia de cómo funciona en C / C ++.

Además de las respuestas anteriores, agregaría que si está utilizando Proguard (y definitivamente debería hacerlo para reducir el tamaño y ofuscar su código), entonces Enumsse convertirá automáticamente a @IntDefdonde sea posible:

https://www.guardsquare.com/en/proguard/manual/optimizations

class / unboxing / enum

Simplifica los tipos de enumeración a constantes enteras, siempre que sea posible.

Por lo tanto, si tiene algunos valores discretos y algún método debería permitir tomar solo estos valores y no otros del mismo tipo, entonces usaría Enum, porque Proguard hará que este manual funcione de optimización de código para mí.

Y aquí hay una buena publicación sobre el uso de enumeraciones de Jake Wharton, échale un vistazo.

Como desarrollador de bibliotecas, reconozco estas pequeñas optimizaciones que deben realizarse, ya que queremos tener el menor impacto posible en el tamaño, la memoria y el rendimiento de la aplicación que consume. Pero es importante darse cuenta de que poner una [...] enumeración en su API pública frente a valores enteros donde sea apropiado está perfectamente bien. Conocer la diferencia para tomar decisiones informadas es lo importante

¿Debo evitar estrictamente el uso de enumeraciones en Android?

No. " Estrictamente " significa que son tan malos que no deben usarse en absoluto. Es posible que surjan problemas de rendimiento en una situación extrema como muchas muchas (miles o millones de) operaciones con enumeraciones (consecutivas en el hilo de la interfaz de usuario). Mucho más comunes son las operaciones de E / S de red que deberían ocurrir estrictamente en un hilo de fondo. El uso más común de enumeraciones es probablemente algún tipo de verificación de tipo: si un objeto es esto o aquello que es tan rápido, no podrá notar una diferencia entre una sola comparación de enumeraciones y una comparación de enteros.

¿Alguien puede aclarar cuál es la mejor manera de representar lo mismo en Android?

No existe una regla general para esto. Utilice lo que funcione para usted y le ayude a preparar su aplicación. Optimice más tarde, después de que note que hay un cuello de botella que ralentiza algún aspecto de su aplicación.

Con Android P, Google no tiene restricciones / objeciones en el uso de enumeraciones

La documentación ha cambiado donde antes se recomendaba ser cauteloso, pero ahora no lo menciona. https://developer.android.com/reference/java/lang/Enum

Dos hechos.

1, Enum es una de las funciones más poderosas de JAVA.

2, el teléfono Android suele tener MUCHA memoria.

Entonces mi respuesta es NO. Usaré Enum en Android.

Me gusta agregar que no puede usar @Annotations cuando declara una List <> o Map <> donde la clave o el valor es de una de sus interfaces de anotación. Aparece el error "No se permiten anotaciones aquí".

enum Values { One, Two, Three }
Map<String, Values> myMap;    // This works

// ... but ...
public static final int ONE = 1;
public static final int TWO = 2;
public static final int THREE = 3;

@Retention(RetentionPolicy.SOURCE)
@IntDef({ONE, TWO, THREE})
public @interface Values {}

Map<String, @Values Integer> myMap;    // *** ERROR ***

Entonces, cuando necesite empaquetarlo en una lista / mapa, use enum, ya que se pueden agregar, pero @annotated int / string groups no.