Questa pagina è stata tradotta dall'API Cloud Translation.

Gestire la memoria dell'app

In questa pagina viene spiegato come ridurre proattivamente la memoria utilizzata all'interno della tua app. Per informazioni su la modalità di gestione della memoria da parte del sistema operativo Android, vedi Panoramica della gestione della memoria.

La memoria ad accesso casuale (RAM) è una risorsa preziosa per qualsiasi ambiente di sviluppo software. ma è ancora più utile per un sistema operativo mobile in cui la memoria fisica è spesso limitata. Sebbene sia la macchina virtuale Android Runtime (ART) sia la macchina virtuale Dalvik eseguano la garbage di routine Ciò non significa che puoi ignorare quando e dove l'app alloca e rilascia la memoria. Devi comunque evitare di introdurre perdite di memoria, di solito causate dal mantenimento dell'oggetto riferimenti nelle variabili membro statiche e rilascia eventuali Reference oggetto in il momento giusto, in base ai callback del ciclo di vita.

Monitorare la memoria disponibile e l'utilizzo della memoria

Prima di poterli risolvere, devi individuare i problemi di utilizzo della memoria dell'app. La Memory Profiler in Android Studio ti aiuta a trovare: e diagnosticare i problemi di memoria nei seguenti modi:

Scopri in che modo la tua app alloca la memoria nel tempo. Lo strumento di analisi della memoria mostra un grafico in tempo reale della quantità di memoria utilizzata dalla tua app, del numero di oggetti Java allocati e del momento in cui avviene la raccolta dei rifiuti.
Avvia eventi di garbage collection e acquisisci uno snapshot dell'heap Java mentre usi l'app viene eseguito.
Registra le allocazioni di memoria dell'app, ispeziona tutti gli oggetti allocati, visualizza l'analisi dello stack per ogni allocazione e vai al codice corrispondente nell'editor di Android Studio.

Rilasciare memoria in risposta agli eventi

Android può recuperare memoria dalla tua app o interromperla completamente se necessario per liberare memoria per le attività più importanti, come spiegato Panoramica della gestione della memoria. Per ulteriore assistenza bilanciare la memoria di sistema ed evitare che il sistema interrompa il processo dell'app, puoi implementare il ComponentCallbacks2 dell'interfaccia nelle tue Activity classi. Il onTrimMemory() il metodo di callback avvisa l'app di eventi relativi al ciclo di vita o alla memoria che rappresentano l'opportunità di ridurre volontariamente la memoria utilizzata dalla tua app. Se si libera memoria, si può ridurre probabilità che la tua app venga interrotta uccisione a bassa memoria.

Puoi implementare il callback onTrimMemory() per rispondere a diversi problemi di memoria come mostrato nell'esempio seguente:

Kotlin

import android.content.ComponentCallbacks2
// Other import statements.

class MainActivity : AppCompatActivity(), ComponentCallbacks2 {

    // Other activity code.

    /**
     * Release memory when the UI becomes hidden or when system resources become low.
     * @param level the memory-related event that is raised.
     */
    override fun onTrimMemory(level: Int) {

        if (level >= ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) {
            // Release memory related to UI elements, such as bitmap caches.
        }

        if (level >= ComponentCallbacks2.TRIM_MEMORY_BACKGROUND) {
            // Release memory related to background processing, such as by
            // closing a database connection.
        }
    }
}

Java

import android.content.ComponentCallbacks2;
// Other import statements.

public class MainActivity extends AppCompatActivity
    implements ComponentCallbacks2 {

    // Other activity code.

    /**
     * Release memory when the UI becomes hidden or when system resources become low.
     * @param level the memory-related event that is raised.
     */
    public void onTrimMemory(int level) {

        if (level >= ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) {
            // Release memory related to UI elements, such as bitmap caches.
        }

        if (level >= ComponentCallbacks2.TRIM_MEMORY_BACKGROUND) {
            // Release memory related to background processing, such as by
            // closing a database connection.
        }
    }
}

Controllare la quantità di memoria necessaria

Per consentire più processi in esecuzione, Android imposta un limite rigido alla dimensione heap assegnata per ogni dell'app. Il limite esatto delle dimensioni dell'heap varia da un dispositivo all'altro in base alla quantità di RAM disponibile sul dispositivo nel complesso. Se l'app raggiunge la capacità heap e tenta di allocare più memoria, il sistema genera OutOfMemoryError.

Per evitare di esaurire la memoria, puoi eseguire una query al sistema per determinare quanto spazio heap è disponibili sul dispositivo attuale. Puoi eseguire una query sul sistema per questa cifra richiamando getMemoryInfo(). Questo restituisce un ActivityManager.MemoryInfo che fornisce informazioni sullo stato attuale della memoria del dispositivo, incluse informazioni memoria totale, memoria totale e soglia di memoria, ovvero il livello di memoria al quale il sistema di interruzione dei processi. Inoltre, l'oggetto ActivityManager.MemoryInfo espone lowMemory, che è un semplice valore booleano che indica se la memoria del dispositivo scarseggia.

Il seguente esempio di snippet di codice mostra come utilizzare il metodo getMemoryInfo() in la tua app.

Kotlin

fun doSomethingMemoryIntensive() {

    // Before doing something that requires a lot of memory,
    // check whether the device is in a low memory state.
    if (!getAvailableMemory().lowMemory) {
        // Do memory intensive work.
    }
}

// Get a MemoryInfo object for the device's current memory status.
private fun getAvailableMemory(): ActivityManager.MemoryInfo {
    val activityManager = getSystemService(Context.ACTIVITY_SERVICE) as ActivityManager
    return ActivityManager.MemoryInfo().also { memoryInfo ->
        activityManager.getMemoryInfo(memoryInfo)
    }
}

Java

public void doSomethingMemoryIntensive() {

    // Before doing something that requires a lot of memory,
    // check whether the device is in a low memory state.
    ActivityManager.MemoryInfo memoryInfo = getAvailableMemory();

    if (!memoryInfo.lowMemory) {
        // Do memory intensive work.
    }
}

// Get a MemoryInfo object for the device's current memory status.
private ActivityManager.MemoryInfo getAvailableMemory() {
    ActivityManager activityManager = (ActivityManager) this.getSystemService(ACTIVITY_SERVICE);
    ActivityManager.MemoryInfo memoryInfo = new ActivityManager.MemoryInfo();
    activityManager.getMemoryInfo(memoryInfo);
    return memoryInfo;
}

Utilizza costrutti di codice più efficienti in termini di memoria

Alcune funzionalità Android, classi Java e costrutti di codice utilizzano più memoria di altre. Puoi al minimo la quantità di memoria usata dall'app scegliendo alternative più efficienti nel codice.

Utilizza i servizi con parsimonia

Ti consigliamo vivamente di non lasciare i servizi in esecuzione quando non sono necessari. Non necessario di servizi in esecuzione è uno dei peggiori errori di gestione della memoria che un'app per Android può commettere. Se la tua app necessita di un servizio per funzionare in background, non uscire e non è in esecuzione, a meno che non sia necessario eseguire un job. Interrompi il servizio una volta completata l'attività. Altrimenti, potresti causare una perdita di memoria.

Quando avvii un servizio, il sistema preferisce mantenere in esecuzione il processo per quel servizio. Questo questo comportamento rende i processi di servizio molto costosi perché la RAM utilizzata da un servizio rimane non è disponibile per altri processi. Ciò riduce il numero di processi memorizzati nella cache che il sistema può mantenere nella cache LRU, rendendo meno efficiente il passaggio da un'app all'altra. Può anche portare allo schiacciamento nel quando la memoria è limitata e il sistema non è in grado di mantenere processi sufficienti per ospitare tutti i servizi attualmente in esecuzione.

In generale, evita di utilizzare servizi permanenti a causa delle richieste continue che sottopongono a disponibilità la memoria. Ti consigliamo invece di utilizzare un'implementazione alternativa, come WorkManager. Per ulteriori informazioni su come utilizzare WorkManager per pianificare i processi in background, consulta Lavoro costante.

Utilizza i container di dati ottimizzati

Alcuni corsi forniti dal linguaggio di programmazione non sono ottimizzati per l'uso sui dispositivi mobili dispositivi mobili. Ad esempio, L'implementazione dell'HashMap può essere memoria è inefficiente perché necessita di un oggetto entry separato per ogni mappatura.

Il framework Android include diversi contenitori di dati ottimizzati, tra cui SparseArray, SparseBooleanArray, e LongSparseArray. Ad esempio, le classi SparseArray sono più efficienti perché evitano le classi necessario casella automatica la chiave e talvolta il valore, il che crea un paio di altri oggetti per voce.

Se necessario, puoi sempre passare agli array non elaborati per una struttura dei dati agile.

Fai attenzione alle astrazioni del codice

Gli sviluppatori spesso usano le astrazioni come buona pratica di programmazione perché possono migliorare il codice flessibilità e manutenzione. Tuttavia, le astrazioni sono molto più costose perché di solito richiedono più codice da eseguire, che richiede più tempo e RAM per il codice in memoria. Se le astrazioni non sono molto utili, evitale.

Utilizza protobuf lite per i dati serializzati

Protocollo I buffer (protobuf) sono un meccanismo estensibile e indipendente dal linguaggio e dalla piattaforma progettato Google per la serializzazione di dati strutturati, simili a XML, ma più piccoli, più veloci e più semplici. Se utilizzi protobuf per i dati, usa sempre protobuf lite nel codice lato client. Regolare I protobuf generano codice estremamente dettagliato, il che può causare molti problemi alla tua app, ad esempio: aumento dell'utilizzo della RAM, aumento significativo delle dimensioni degli APK ed esecuzione più lenta.

Per ulteriori informazioni, consulta protobuf leggimi.

Evitare il tasso di abbandono della memoria

Gli eventi di raccolta dei rifiuti non influiscono sulle prestazioni dell'app. Tuttavia, molti garbage collection che si verificano in un breve periodo di tempo possono scaricare velocemente la batteria, oltre che aumenta il tempo di configurazione dei frame a causa delle interazioni necessarie tra il garbage collector e thread di app. Maggiore è il tempo che il sistema impiega nella raccolta dei rifiuti, più velocemente la batteria drenaggio.

Spesso, l'abbandono della memoria può causare un numero elevato di eventi di garbage collection. Nel il tasso di abbandono della memoria descrive il numero di oggetti temporanei allocati che si verificano per un periodo di tempo limitato.

Ad esempio, potresti allocare più oggetti temporanei all'interno di un loop for. Oppure potresti creare un nuovo Paint o Bitmap oggetti all'interno dell'elemento onDraw() funzione di una vista. In entrambi i casi, l'app crea molti oggetti rapidamente ad alto volume. Questi può consumare rapidamente tutta la memoria disponibile nella giovane generazione, forzando una garbage collection che si verifichi.

Utilizza il Memory Profiler per trovare i luoghi in il tuo codice in cui il tasso di abbandono della memoria è elevato prima di poterlo risolvere.

Dopo aver identificato le aree problematiche del codice, prova a ridurre il numero di allocazioni all'interno in aree critiche per le prestazioni. Prova a spostare gli elementi fuori dai loop interni o magari a spostarli in una fabbrica struttura di allocazione.

Puoi anche valutare se i pool di oggetti sono utili per il caso d'uso. Con un pool di oggetti, invece di facendo cadere un'istanza di oggetto sul pavimento, la rilasci in un pool quando non è più necessaria. La prossima volta che è necessaria un'istanza di oggetto di quel tipo, puoi acquisirla dal pool anziché che allocarlo.

Valuta attentamente le prestazioni per determinare se un pool di oggetti è adatto in una determinata situazione. In alcuni casi i pool di oggetti potrebbero peggiorare le prestazioni. Anche se i pool evitano allocazioni, inoltre, introducono altre spese generali. Ad esempio, la gestione del pool di solito comporta con un overhead non trascurabile. Inoltre, se cancelli l'istanza dell'oggetto in pool evitare fughe di memoria durante il rilascio e la sua inizializzazione durante l’acquisizione può avere un valore diverso da zero overhead.

Anche il blocco di più istanze di oggetti del pool del necessario comporta un carico di lavoro eccessivo . Sebbene i pool di oggetti riducano il numero di chiamate alla garbage collection, finiscono per aumentando la quantità di lavoro necessario per ogni chiamata, in quanto è proporzionale al numero di byte live (raggiungibili).

Rimuovi risorse e librerie che utilizzano molta memoria

Alcune risorse e librerie all'interno del codice possono consumare memoria a tua insaputa. La le dimensioni complessive dell'app, incluse le librerie di terze parti o le risorse incorporate, possono influire utilizzata dalla tua app. Per migliorare il consumo della memoria dell'app, rimuovi elementi ridondanti, componenti, risorse e librerie del codice inutili o gonfi.

Riduci le dimensioni complessive dell'APK

Puoi ridurre in modo significativo l'utilizzo della memoria da parte dell'app riducendo le dimensioni complessive dell'app. Dimensioni bitmap, risorse, frame di animazione e librerie di terze parti possono contribuire alla dimensione della tua app. Android Studio e l'SDK Android forniscono diversi strumenti per aiutare a ridurre le dimensioni le risorse e le dipendenze esterne. Questi strumenti supportano i moderni metodi di riduzione del codice, come Compilation di R8.

Per ulteriori informazioni su come ridurre le dimensioni complessive dell'app, consulta Riduci le dimensioni della tua app.

Usa Hilt o Dagger 2 per l'inserimento delle dipendenze

I framework di inserimento delle dipendenze possono semplificare il codice che scrivi e fornire un'esperienza molto utile per i test e altre modifiche alla configurazione.

Se intendi utilizzare un framework di Dependency Injection nella tua app, ti consigliamo di utilizzare Hilt o Dagger. Hilt è un'inserimento di dipendenze libreria per Android basata su Dagger. Dagger non utilizza il riflesso per analizzare lo le API nel tuo codice. Puoi utilizzare l'implementazione statica in fase di compilazione di Dagger nelle app per Android senza costi di runtime o utilizzo della memoria non necessari.

Altri framework di inserimento delle dipendenze che utilizzano la riflessione inizializzano i processi analizzando il tuo per le annotazioni. Questo processo può richiedere molti più cicli della CPU e RAM e può causare un notevole ritardo all'avvio dell'app.

Presta attenzione all'utilizzo di librerie esterne

Il codice libreria esterna spesso non è scritto per ambienti mobili e può essere inefficiente per lavorare con un client mobile. Quando usi una libreria esterna, potresti doverne ottimizzare libreria per dispositivi mobili. Pianifica questo lavoro in anticipo e analizza la libreria in termini di dimensione del codice e impronta RAM prima di utilizzarla.

Anche alcune librerie ottimizzate per dispositivi mobili possono causare problemi a causa di implementazioni diverse. Per Ad esempio, una libreria potrebbe utilizzare protobuf lite e un'altra utilizza protobuf micro, ottenendo implementazioni di protobuf diverse nella tua app. Ciò può accadere con diverse implementazioni logging, analisi, framework di caricamento delle immagini, memorizzazione nella cache e molte altre cose che non ti aspetti.

Sebbene ProGuard possa aiutarti a rimuovere API e risorse con i flag corretti, non può rimuovere le dipendenze interne di grandi dimensioni di una libreria. Le funzionalità che vuoi includere in queste librerie potrebbero richiedere dipendenze di livello inferiore. Questo diventa particolarmente problematico quando usa una sottoclasse Activity da un libreria, che può avere ampie fasce di dipendenze, quando le librerie usano la riflessione, che è comune e richiede la modifica manuale di ProGuard per farlo funzionare.

Evita di utilizzare una libreria condivisa solo per una o due funzionalità su decine. Non tirare una grossa fetta quantità di codice e overhead che non utilizzi. Quando valuti se utilizzare una libreria, cerca un'implementazione che soddisfi le tue esigenze specifiche. Altrimenti, puoi decidere di creare i tuoi la propria implementazione.