2018: Android supporta questo in modo nativo attraverso i componenti del ciclo di vita.
AGGIORNAMENTO di marzo 2018 : ora esiste una soluzione migliore. Vedi ProcessLifecycleOwner . Dovrai utilizzare i nuovi componenti dell'architettura 1.1.0 (la più recente in questo momento) ma è specificamente progettato per farlo.
C'è un semplice esempio fornito in questa risposta, ma ho scritto un'app di esempio e un post sul blog a riguardo.
Da quando l'ho scritto nel 2014, sono nate diverse soluzioni. Alcuni hanno funzionato, altri si pensava funzionassero , ma avevano difetti (incluso il mio!) E noi, come comunità (Android), abbiamo imparato a convivere con le conseguenze e abbiamo scritto soluzioni alternative per i casi speciali.
Non dare per scontato che un singolo frammento di codice sia la soluzione che stai cercando, è improbabile che sia così; meglio ancora, cerca di capire cosa fa e perché lo fa.
La MemoryBossclasse non è mai stata effettivamente utilizzata da me come scritto qui, era solo un pezzo di pseudo codice che funzionava.
A meno che non ci sia una ragione valida per non usare i nuovi componenti dell'architettura (e ce ne sono alcuni, specialmente se si prendono di mira le vecchie vecchie API), quindi andare avanti e usarli. Sono tutt'altro che perfetti, ma nessuno dei due lo era ComponentCallbacks2.
AGGIORNAMENTO / NOTE (novembre 2015) : le persone hanno fatto due commenti, il primo è che >=dovrebbe essere usato invece che ==perché la documentazione afferma che non si dovrebbero verificare i valori esatti . Questo va bene per la maggior parte dei casi, ma tenere a mente che se solo si cura di fare qualcosa quando l'applicazione è andato al fondo, si dovrà utilizzare == e anche combinarlo con un'altra soluzione (come callback attività del ciclo di vita), oppure si potrebbe non ottenere l'effetto desiderato. L'esempio (e questo è successo a me) è che se vuoi bloccarela tua app con una schermata della password quando passa in background (come 1Password se la conosci), potresti accidentalmente bloccare l'app se hai poca memoria e stai improvvisamente testando >= TRIM_MEMORY, perché Android attiverà una LOW MEMORYchiamata e questo è più alto del tuo. Quindi fai attenzione a come / cosa testare.
Inoltre, alcune persone hanno chiesto come rilevare quando torni.
Il modo più semplice a cui riesco a pensare è spiegato di seguito, ma dato che alcune persone non lo conoscono, sto aggiungendo un pseudo codice proprio qui. Supponendo che tu abbia YourApplicatione le MemoryBossclassi, nel tuo class BaseActivity extends Activity(dovrai crearne una se non ne hai una).
@Override
protected void onStart() {
super.onStart();
if (mApplication.wasInBackground()) {
// HERE YOU CALL THE CODE YOU WANT TO HAPPEN ONLY ONCE WHEN YOUR APP WAS RESUMED FROM BACKGROUND
mApplication.setWasInBackground(false);
}
}
Raccomando onStart perché le finestre di dialogo possono mettere in pausa un'attività, quindi scommetto che non vuoi che la tua app pensi "è andata in secondo piano" se tutto ciò che hai fatto è stato visualizzare una finestra di dialogo a schermo intero, ma il tuo chilometraggio può variare.
E questo è tutto. Il codice nel blocco if sarà eseguito solo una volta , anche se si va a un'altra attività, quello nuovo (che anche extends BaseActivity) riferirà wasInBackgroundè falsein modo da non eseguire il codice, fino a quando onMemoryTrimmedviene chiamato e il flag è impostato su true nuovo .
Spero che aiuti.
AGGIORNAMENTO / NOTE (aprile 2015) : Prima di andare su Copia e incolla su questo codice, nota che ho trovato un paio di casi in cui potrebbe non essere affidabile al 100% e devo combinarlo con altri metodi per ottenere i migliori risultati. In particolare, ci sono due casi noti in cui onTrimMemorynon è garantita l'esecuzione della richiamata:
Se il telefono blocca lo schermo mentre l'app è visibile (diciamo che il dispositivo si blocca dopo nn minuti), questo callback non viene chiamato (o non sempre) perché la schermata di blocco è solo in cima, ma l'app è ancora "in esecuzione" anche se coperta.
Se il tuo dispositivo ha una memoria relativamente bassa (e sotto stress di memoria), il sistema operativo sembra ignorare questa chiamata e passare direttamente a livelli più critici.
Ora, a seconda di quanto sia importante che tu sappia quando la tua app è passata in background, potresti aver bisogno o meno di estendere questa soluzione insieme per tenere traccia del ciclo di vita delle attività e quant'altro.
Tieni a mente quanto sopra e fai in modo di avere un buon team di controllo qualità;)
FINE AGGIORNAMENTO
Potrebbe essere tardi, ma esiste un metodo affidabile in Ice Cream Sandwich (API 14) e versioni successive .
Si scopre che quando l'app non ha più un'interfaccia utente visibile, viene attivato un callback. Il callback, che è possibile implementare in una classe personalizzata, si chiama ComponentCallbacks2 (sì, con un due). Questo callback è disponibile solo in API Level 14 (Ice Cream Sandwich) e versioni successive.
Praticamente ricevi una chiamata al metodo:
public abstract void onTrimMemory (int level)
Il livello è 20 o più specificamente
public static final int TRIM_MEMORY_UI_HIDDEN
Ho provato questo e funziona sempre, perché il livello 20 è solo un "suggerimento" che potresti voler rilasciare alcune risorse poiché la tua app non è più visibile.
Per citare i documenti ufficiali:
Livello per onTrimMemory (int): il processo mostrava un'interfaccia utente e non lo fa più. A questo punto è necessario rilasciare grandi allocazioni con l'interfaccia utente per consentire una migliore gestione della memoria.
Ovviamente, dovresti implementarlo per fare effettivamente ciò che dice (elimina la memoria che non è stata utilizzata in un determinato momento, cancella alcune raccolte che sono rimaste inutilizzate, ecc. Le possibilità sono infinite (vedi i documenti ufficiali per altri possibili altro livelli critici ).
Ma la cosa interessante è che il sistema operativo ti sta dicendo: HEY, la tua app è passata in secondo piano!
Che è esattamente quello che volevi sapere in primo luogo.
Come determini quando sei tornato?
Bene, è facile, sono sicuro che hai un "BaseActivity" in modo da poter usare onResume () per segnalare il fatto che sei tornato. Perché l'unica volta che dirai che non sei tornato è quando ricevi effettivamente una chiamata al onTrimMemorymetodo sopra .
Funziona. Non ottieni falsi positivi. Se un'attività riprende, sei tornato, il 100% delle volte. Se l'utente torna di nuovo sul retro, si riceve un'altra onTrimMemory()chiamata.
Devi iscrivere le tue attività (o meglio ancora, un corso personalizzato).
Il modo più semplice per garantirti di ricevere sempre questo è creare una classe semplice come questa:
public class MemoryBoss implements ComponentCallbacks2 {
@Override
public void onConfigurationChanged(final Configuration newConfig) {
}
@Override
public void onLowMemory() {
}
@Override
public void onTrimMemory(final int level) {
if (level == ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) {
// We're in the Background
}
// you might as well implement some memory cleanup here and be a nice Android dev.
}
}
Per usarlo, nell'implementazione dell'applicazione ( ne hai uno, DESTRA? ), Fai qualcosa del tipo:
MemoryBoss mMemoryBoss;
@Override
public void onCreate() {
super.onCreate();
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.ICE_CREAM_SANDWICH) {
mMemoryBoss = new MemoryBoss();
registerComponentCallbacks(mMemoryBoss);
}
}
Se si crea un, Interfaceè possibile aggiungere un elsea quello ife implementare ComponentCallbacks(senza il 2) utilizzato in qualsiasi cosa sotto API 14. Quel callback ha solo il onLowMemory()metodo e non viene chiamato quando si passa in background , ma è necessario utilizzarlo per tagliare la memoria .
Ora avvia l'app e premi home. Il tuo onTrimMemory(final int level)metodo dovrebbe essere chiamato (suggerimento: aggiungi registrazione).
L'ultimo passaggio consiste nell'annullare la registrazione dal callback. Probabilmente il posto migliore è il onTerminate()metodo della tua app, ma quel metodo non viene chiamato su un dispositivo reale:
/**
* This method is for use in emulated process environments. It will
* never be called on a production Android device, where processes are
* removed by simply killing them; no user code (including this callback)
* is executed when doing so.
*/
Quindi, a meno che tu non abbia davvero una situazione in cui non desideri più essere registrato, puoi tranquillamente ignorarlo, poiché il tuo processo sta comunque morendo a livello di sistema operativo.
Se decidi di annullare la registrazione a un certo punto (se, ad esempio, fornisci un meccanismo di arresto per la tua app per ripulire e morire), puoi fare:
unregisterComponentCallbacks(mMemoryBoss);
E questo è tutto.
