¿Por qué Android utiliza Ints en vez de Enums?

Lectura sobre Android Puedo ver muchas partes del framework usando constantes int para un valor de retorno, o valor de configuración ( como aquí en el START_REDELIVER_INTENT ), en lugar de un enum , que hasta donde yo sé es una mejor opción por muchas razones que Se puede encontrar en toda la web, como este .

Así que esto me hace preguntarme … ¿por qué Google decidió utilizar tantos int's lugar de enum's ?

Tirado directamente de los documentos

Enums often require more than twice as much memory as static constants. You should strictly avoid using enums on Android.

http://developer.android.com/training/articles/memory.html#Overhead

Editar:

También una diapositiva de una de las conversaciones de Guy Romano

https://speakerdeck.com/romainguy/android-memories?slide=67

Las operaciones en int ocurren muchas veces más rápido que las operaciones en enum.

Juzga por ti mismo. Cada vez que crea un enum que cree como mínimo:

 1) Class-loader for it. 2) You keep this object in memory. 3) Since enum is static anonymous class - it will always hang in your memory (sometimes even after you close the application.) 

Con respecto al Service . En esta clase, las banderas se utilizan principalmente para comparaciones y devolver el resultado a la clase anterior ( ContextWrapper ). Pero, básicamente, si usted cavar en las entrañas de Android SDK usted descubrirá por sí mismo que casi todas estas banderas se utilizan para las operaciones de turno bynary .

Incluso en Java utilizar un cambio binario operaciones en JDK:

 /** * Max capacity for a HashMap. Must be a power of two >= MINIMUM_CAPACITY. */ private static final int MAXIMUM_CAPACITY = 1 << 30; 

También puedes consultar la clase Window en Android SDK

 /** * Set the container for this window. If not set, the DecorWindow * operates as a top-level window; otherwise, it negotiates with the * container to display itself appropriately. * * @param container The desired containing Window. */ public void setContainer(Window container) { mContainer = container; if (container != null) { // Embedded screens never have a title. mFeatures |= 1<<FEATURE_NO_TITLE; mLocalFeatures |= 1<<FEATURE_NO_TITLE; container.mHasChildren = true; } } /** The default features enabled */ @SuppressWarnings({"PointlessBitwiseExpression"}) protected static final int DEFAULT_FEATURES = (1 << FEATURE_OPTIONS_PANEL) | (1 << FEATURE_CONTEXT_MENU); 

Así que las razones son dos (al menos):

  • Menor consumo de memoria.

  • Trabajar más rápido debido a las operaciones a bit.

  • Biblioteca de AndroidFillableLoaders de JorgeCastilloPrz - Problema de SVGPath
  • ¿Cómo evitar httpsURLConnection.getInputStream () en Android colgando si se proporcionan credenciales de inicio de sesión incorrectas?
  • ¿Cómo establecer el límite de los elementos coincidentes devueltos por DynamoDB utilizando Java?
  • ActionBarActivity: no se puede resolver con un tipo
  • Acceder directamente a los campos estáticos en lugar de llamar a un método getter estático, ¿es más rápido?
  • Android ClassNotFoundException: No encontró la clase en el path
  • LibGDX - Texto sobre textura en tile / tilemaps
  • Android establece el atributo autoLink mediante programación
  • Android sólo juego en OpenGL: rendimiento en C ++ (NDK) vs Java (Dalvik)
  • Android: Llamar a Python Script (a través de SL4A) desde código Java
  • El constructor BitmapDrawable () está obsoleto fix
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.