Devo assolutamente evitare di usare le enumerazioni su Android?

Definivo insieme un insieme di costanti correlate come le Bundlechiavi in ​​un'interfaccia come di seguito:

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

Questo mi fornisce un modo migliore per raggruppare le costanti correlate e usarle facendo un'importazione statica (non implementa). So Androidquadro utilizza anche le costanti nello stesso modo come Toast.LENTH_LONG, View.GONE.

Tuttavia, sento spesso che il file Java Enums forniscano un modo molto migliore e potente per rappresentare la costante.

Ma c'è un problema di prestazioni nell'uso enumsdiAndroid ?

Con un po 'di ricerca sono finito in confusione. Da questa domanda "Evita enumerazioni dove hai solo bisogno di Ints" rimossa dai suggerimenti sulle prestazioni di Android? È chiaro che Googleha rimosso "Evita enumerazioni" dai suoi suggerimenti sulle prestazioni, ma dai suoi documenti di formazione ufficiali Fai attenzione alla sezione relativa al sovraccarico della memoria che dice chiaramente: " spesso richiedono più del doppio della memoria rispetto alle costanti statiche. Dovresti assolutamente evitare di utilizzare le enumerazioni su Android. " È ancora valido? (Ad esempio nelle Javaversioni successive alla 1.6)

Un problema più che ho osservato è quello di inviare enumstutto intentstramite Bundledovrei inviarli via serializzazione (vale a dire putSerializable(), che ritengo un'operazione costosa rispetto al primitivo putString()metodo, eventhoughenums fornisce gratuitamente).

Qualcuno può chiarire qual è il modo migliore per rappresentare lo stesso in Android? Devo assolutamente evitare di usare enumsil Android?

Usalo enumquando ne hai bisogno. Non evitarlo rigorosamente .

Java enum è più potente, ma se non hai bisogno delle sue funzionalità, usa le costanti, occupano meno spazio e possono essere primitive.

Quando usare enum:

• controllo del tipo: puoi accettare solo i valori elencati e non sono continui (vedi sotto quello che chiamo continuo qui)

• sovraccarico del metodo: ogni costante enum ha la propria implementazione di un metodo
  

  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);
  }

• più dati: la tua unica costante contiene più di un'informazione che non può essere inserita in una variabile

• dati complicati: i tuoi metodi di necessità costante per operare sui dati

Quando non usare enum:

• puoi accettare tutti i valori di un tipo e le tue costanti contengono solo quelli più utilizzati

• puoi accettare dati continui
  

  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);
          }
  
          ...
      }
  }

• per i nomi (come nel tuo esempio)
• per tutto il resto che in realtà non necessita di enumerazione

Gli enum occupano più spazio

• un singolo riferimento a una costante enum occupa 4 byte
• ogni costante enum occupa uno spazio che è una somma delle dimensioni dei suoi campi allineati a 8 byte + overhead dell'oggetto
• la classe enum stessa occupa un po 'di spazio

Le costanti occupano meno spazio

• una costante non ha un riferimento quindi è un dato puro (anche se è un riferimento, l'istanza enum sarebbe un riferimento a un altro riferimento)
• le costanti possono essere aggiunte a una classe esistente - non è necessario aggiungere un'altra classe
• le costanti possono essere inline; offre funzionalità estese in fase di compilazione (come il controllo null, la ricerca di codice morto ecc.)

Se le enumerazioni hanno semplicemente valori, dovresti provare a utilizzare IntDef / StringDef, come mostrato qui:

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

Esempio: invece di:

enum NavigationMode {NAVIGATION_MODE_STANDARD, NAVIGATION_MODE_LIST, NAVIGATION_MODE_TABS} 

usate:

@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;

e nella funzione che lo ha come parametro / valore restituito, usa:

@NavigationMode
public abstract int getNavigationMode();

public abstract void setNavigationMode(@NavigationMode int mode);

Nel caso in cui l'enum sia complesso, usa un enum. Non è così male.

Per confrontare enumerazioni con valori costanti, dovresti leggere qui:

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

Il loro esempio è di un'enumerazione con 2 valori. Richiede 1112 byte nel file dex rispetto ai 128 byte quando vengono utilizzati numeri interi costanti. Ha senso, poiché le enumerazioni sono classi reali, al contrario di come funziona in C / C ++.

Oltre alle risposte precedenti, aggiungerei che se stai usando Proguard (e dovresti assolutamente farlo per ridurre le dimensioni e offuscare il tuo codice), il tuo Enumsverrà automaticamente convertito in@IntDef ovunque sia possibile:

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

class / unboxing / enum

Semplifica i tipi enum in costanti intere, quando possibile.

Pertanto, se hai dei valori discreti e qualche metodo dovrebbe consentire di prendere solo questi valori e non altri dello stesso tipo, allora userei Enum userei, perché Proguard farà questo lavoro manuale di ottimizzazione del codice per me.

Ed ecco un buon post sull'uso delle enumerazioni di Jake Wharton, dai un'occhiata.

In qualità di sviluppatore di librerie, riconosco queste piccole ottimizzazioni che dovrebbero essere fatte poiché vogliamo avere il minor impatto possibile sulle dimensioni, la memoria e le prestazioni dell'app che consumano. Ma è importante rendersi conto che mettere [...] un enum nella tua API pubblica rispetto a valori interi dove appropriato va perfettamente bene. Sapere la differenza per prendere decisioni informate è ciò che è importante

Devo assolutamente evitare di usare le enumerazioni su Android?

No. " Rigorosamente " significa che sono così cattivi, non dovrebbero essere usati affatto. È possibile che si verifichino problemi di prestazioni in una situazione estrema come molte molte (migliaia o milioni di) operazioni con enumerazioni (consecutive sul thread dell'interfaccia utente). Molto più comuni sono le operazioni di I / O di rete che dovrebbero avvenire rigorosamente in un thread in background. L'utilizzo più comune di enumerazioni è probabilmente una sorta di controllo del tipo: se un oggetto è questo o quello che è così veloce non sarai in grado di notare una differenza tra un singolo confronto di enumerazioni e un confronto di interi.

Qualcuno può chiarire qual è il modo migliore per rappresentare lo stesso in Android?

Non esiste una regola generale per questo. Usa quello che funziona per te e ti aiuta a preparare la tua app. Ottimizza in seguito: dopo aver notato che c'è un collo di bottiglia che rallenta alcuni aspetti della tua app.

Con Android P, Google non ha restrizioni / obiezioni nell'uso delle enumerazioni

La documentazione è cambiata dove prima si raccomandava di essere cauti ma ora non la menziona. https://developer.android.com/reference/java/lang/Enum

Due fatti.

1, Enum è una delle funzionalità più potenti di JAVA.

2, il telefono Android di solito ha MOLTA memoria.

Quindi la mia risposta è NO. Userò Enum su Android.

Mi piace aggiungere che non puoi usare @Annotations quando dichiari un List <> o Map <> dove la chiave o il valore è di una delle tue interfacce di annotazione. Viene visualizzato l'errore "Le annotazioni non sono consentite qui".

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 ***

Quindi, quando è necessario comprimerlo in un elenco / mappa, utilizzare enum, poiché possono essere aggiunti, ma i gruppi int / string @annotated non possono.