Quali sono i vantaggi di impostare largeHeap su true?

Ho un'app con quasi 50 classi che sto impostando android:largeHeap="true", come puoi vedere di seguito. È una buona pratica?

<application
        android:name=".MyApplication"
        android:allowBackup="true"
        android:icon="@drawable/ic_launcher"
        android:label="Mall"
        android:largeHeap="true"
        android:logo="@drawable/logo_for_up"
        android:screenOrientation="portrait"
        android:theme="@style/AppTheme" >
</application>

Si prega di suggerire vantaggi e svantaggi per il suo utilizzo.

Ho problemi di memoria, ecco perché faccio questa domanda.

Troppo tardi per la festa qui, ma offrirò comunque i miei 0,02 $.
Non è una buona idea usare android:largeHeap="true" ecco l'estratto di google che lo spiega,

Tuttavia, la possibilità di richiedere un grande heap è intesa solo per un piccolo set di app che possono giustificare la necessità di consumare più RAM (come una grande app di fotoritocco). Non richiedere mai un mucchio di grandi dimensioni semplicemente perché hai esaurito la memoria e hai bisogno di una soluzione rapida: dovresti usarlo solo quando sai esattamente dove viene allocata tutta la memoria e perché deve essere conservata. Tuttavia, anche se sei sicuro che la tua app possa giustificare l'heap di grandi dimensioni, dovresti evitare di richiederla nella misura possibile. L'utilizzo della memoria aggiuntiva andrà sempre più a scapito dell'esperienza utente complessiva, poiché la raccolta dei rifiuti richiederà più tempo e le prestazioni del sistema potrebbero essere più lente quando si cambia attività o si eseguono altre operazioni comuni.

ecco il link completo della documentazione https://developer.android.com/training/articles/memory.html

AGGIORNARE

Dopo aver lavorato duramente con out of memory errorsdirei che aggiungere questo al manifest per evitare il problema oom non è un peccato, anche come @Milad sottolinea di seguito non influisce sul normale funzionamento dell'app

AGGIORNAMENTO 2

Ecco alcuni suggerimenti per affrontare conout of memory errors

1) Utilizzare questi callback che Android dà onLowMemory, onTrimMemory(int) e cancellare la cache delle immagini come (Picasso, glide, affresco ....) si può leggere di più su di loro qui e qui
2) comprimere i file (immagini, pdf)
3) letto su come gestire le bitmap in modo più efficiente qui
4) Usa lint regolarmente prima che la produzione spinga per assicurarti che il codice sia elegante e non ingombrante

Penso che questa sia una domanda molto efficace e consentitemi di aggiungere alcuni dettagli sui vantaggi e gli svantaggi dell'utilizzo di questa opzione.

Cosa ottieni :

• Ovviamente, ottieni un mucchio più grande, il che significa diminuire il rischio di OutOfMemoryError.

Cosa hai perso:

• Potresti perdere alcuni fotogrammi, il che può causare un evidente intoppo . Un heap più grande fa sì che le raccolte di rifiuti richiedano più tempo. Perché il garbage collector deve fondamentalmente attraversare l'intero set di oggetti live. Di solito, il tempo di pausa della raccolta dei rifiuti è di circa 5 ms e potresti pensare che pochi millisecondi non siano un grosso problema. Ma ogni millisecondo conta. Il dispositivo Android deve aggiornare lo schermo ogni 16 ms e un tempo GC più lungo potrebbe spingere il tempo di elaborazione del frame oltre la barriera di 16 millisecondi, il che può causare un intoppo visibile.

• Anche il cambio di app diventerà più lento . Il sistema Android può terminare i processi nella cache LRU a partire dal processo utilizzato meno di recente, ma anche tenendo conto di quali processi richiedono più memoria. Quindi, se utilizzi un heap più grande, è più probabile che il tuo processo venga interrotto quando è in background, il che significa che potrebbe essere necessario più tempo quando gli utenti desiderano passare da altre app alla tua. Inoltre, è più probabile che altri processi in background vengano eliminati quando il processo è in primo piano, perché l'app richiede una memoria più ampia. Significa anche che il passaggio dalla tua app ad altre app richiede più tempo.

Conclusione :

Evita di usare l' largeHeapopzione il più possibile. Potrebbe costarti un calo delle prestazioni difficile da notare e una cattiva esperienza utente.

Ho un'app con quasi 50 classi

Non credo che questo crei molti problemi. Il motivo per cui hai ottenuto l'errore outOfMemory di solito è caricare troppe immagini nella tua app o qualcosa del genere. Se non sei soddisfatto di utilizzare un mucchio di grandi dimensioni, devi trovare un modo per ottimizzare l'utilizzo della memoria.

Puoi anche utilizzare le librerie di caricamento delle immagini come Picasso , UIL o Glide . Tutti hanno la funzione di caching delle immagini in memoria e / o su disco.

In realtà Android: largeHeap è lo strumento per aumentare la memoria allocata all'app.

Non esiste una definizione chiara della necessità di utilizzare questo flag. Se hai bisogno di più memoria, Android ti fornisce uno strumento per aumentarla. Ma per necessità di utilizzo ti definisci.

Se devi usare (e conservare) una grande quantità di memoria, allora sì, puoi e dovresti usarla android:largeHeap="true". Ma se lo usi, dovresti essere pronto a scaricare la tua app dalla memoria ogni volta che altre app sono in primo piano.

Con "essere preparati", intendo che dovresti progettare in base a tale probabilità, in modo che i tuoi metodi onStop()e onResume()siano scritti nel modo più efficiente possibile, assicurandoti che tutto lo stato pertinente venga salvato e ripristinato in un modo che presenti un aspetto uniforme per l'utente.

Ci sono tre metodi che si riferiscono a questo parametro: maxMemory(), getMemoryClass(), e getLargeMemoryClass().

Per la maggior parte dei dispositivi, maxMemory()rappresenterà un valore simile a quello getMemoryClass()di default, anche se quest'ultimo è espresso in megabyte, mentre il primo è espresso in byte.

Quando si utilizza il largeHeapparametro, maxMemory()verrà aumentato a un livello più alto specifico del dispositivo, mentre getMemoryClass()rimarrà lo stesso.

getMemoryClass()non limita la dimensione dell'heap, ma ti dice la quantità di heap che dovresti usare se vuoi che la tua app funzioni comodamente e compatibilmente entro i limiti del particolare dispositivo su cui stai eseguendo.

maxMemory(), Al contrario, non limitare la dimensione heap, e così si fa l'accesso guadagno mucchio ulteriore aumentando il suo valore, e largeHeapfa aumentare tale valore. Tuttavia, la maggiore quantità di heap è ancora limitata e tale limite sarà specifico del dispositivo, il che significa che la quantità di heap disponibile per la tua app varierà a seconda delle risorse del dispositivo su cui è in esecuzione l'app. Quindi, l'utilizzo largeHeapnon è un invito per la tua app ad abbandonare ogni cautela e farsi strada attraverso il buffet all-you-can-eat.

La tua app può scoprire esattamente quanta memoria sarebbe resa disponibile su un particolare dispositivo utilizzando il largeHeapparametro richiamando il metodo getLargeMemoryClass(). Il valore restituito è in megabyte.

Questo post precedente include una discussione del largeHeapparametro, nonché una serie di esempi di quali quantità di heap sono rese disponibili con e senza il suo utilizzo, su diversi dispositivi Android specifici:

Rileva la dimensione dell'heap dell'applicazione in Android

Non ho distribuito nessuna delle mie app con questo parametro impostato su true. Tuttavia, ho del codice ad alta intensità di memoria in una delle mie app per la compilazione di una serie di parametri relativi all'ottimizzazione, che viene eseguita solo durante lo sviluppo. Aggiungo il largeHeapparametro solo durante lo sviluppo, per evitare errori di memoria insufficiente durante l'esecuzione di questo codice. Ma rimuovo il parametro (e il codice) prima di distribuire l'app.

Se i processi della tua applicazione devono essere creati con un grande mucchio Dalvik. Questo vale per tutti i processi creati per l'applicazione. Si applica solo alla prima applicazione caricata in un processo; se si utilizza un ID utente condiviso per consentire a più applicazioni di utilizzare un processo, tutte devono utilizzare questa opzione in modo coerente o avranno risultati imprevedibili.

La maggior parte delle app non dovrebbe averne bisogno e dovrebbe invece concentrarsi sulla riduzione dell'utilizzo complessivo della memoria per migliorare le prestazioni. L'abilitazione di questo inoltre non garantisce un aumento fisso della memoria disponibile, perché alcuni dispositivi sono vincolati dalla loro memoria disponibile totale.