2018: Android prend en charge cela nativement via les composants du cycle de vie.
MISE À JOUR DE MARS 2018 : Il y a maintenant une meilleure solution. Voir ProcessLifecycleOwner . Vous devrez utiliser les nouveaux composants de l'architecture 1.1.0 (les plus récents à l'heure actuelle), mais il est spécialement conçu pour cela.
Il y a un exemple simple fourni dans cette réponse, mais j'ai écrit un exemple d'application et un blog à ce sujet.
Depuis que j'ai écrit cela en 2014, différentes solutions sont apparues. Certains fonctionnaient, certains étaient censés fonctionner , mais avaient des défauts (y compris le mien!) Et nous, en tant que communauté (Android), avons appris à vivre avec les conséquences et avons écrit des solutions de contournement pour les cas spéciaux.
Ne présumez jamais qu'un seul extrait de code est la solution que vous recherchez, il est peu probable que ce soit le cas; mieux encore, essayez de comprendre ce qu'il fait et pourquoi il le fait.
La MemoryBossclasse n'a jamais été utilisée par moi comme écrit ici, c'était juste un morceau de pseudo-code qui fonctionnait.
À moins qu'il n'y ait une raison valable pour que vous n'utilisiez pas les nouveaux composants de l'architecture (et il y en a certains, surtout si vous ciblez de super vieux API), alors allez-y et utilisez-les. Ils sont loin d'être parfaits, mais aucun ne l'était ComponentCallbacks2.
MISE À JOUR / NOTES (novembre 2015) : Les gens ont fait deux commentaires, le premier est que cela >=devrait être utilisé au lieu de ==parce que la documentation indique que vous ne devriez pas vérifier les valeurs exactes . C'est très bien dans la plupart des cas, mais gardez à l'esprit que si vous ne voulez faire quelque chose que lorsque l'application est passée en arrière-plan, vous devrez utiliser == et la combiner avec une autre solution (comme les rappels de cycle de vie d'activité), ou vous peut ne pas obtenir l'effet souhaité. L'exemple (et cela m'est arrivé) est que si vous voulez verrouillervotre application avec un écran de mot de passe en arrière-plan (comme 1Password si vous le connaissez), vous pouvez accidentellement verrouiller votre application si vous manquez de mémoire et que vous testez soudainement >= TRIM_MEMORY, car Android déclenchera un LOW MEMORYappel et c'est plus élevé que le vôtre. Soyez donc prudent comment / ce que vous testez.
De plus, certaines personnes ont demandé comment détecter quand vous revenez.
La manière la plus simple à laquelle je pense est expliquée ci-dessous, mais comme certaines personnes ne la connaissent pas, j'ajoute un pseudo-code ici. En supposant que vous avez YourApplicationet les MemoryBossclasses, dans votre class BaseActivity extends Activity(vous devrez en créer un si vous n'en avez pas).
@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);
}
}
Je recommande onStart car Dialogs peut suspendre une activité, donc je parie que vous ne voulez pas que votre application pense "qu'elle est passée en arrière-plan" si tout ce que vous avez fait était d'afficher une boîte de dialogue en plein écran, mais votre kilométrage peut varier.
Et c'est tout. Le code dans le bloc si vous ne sera exécutée une fois la nouvelle (qui a également, même si vous allez à une autre activité, extends BaseActivity) fera rapport wasInBackgroundest falsedonc il ne sera pas exécuter le code, jusqu'à ce que l' onMemoryTrimmedon appelle et le drapeau est défini sur true à nouveau .
J'espère que cela pourra aider.
MISE À JOUR / NOTES (avril 2015) : Avant de commencer à copier et coller sur ce code, notez que j'ai trouvé quelques exemples où il peut ne pas être fiable à 100% et doit être combiné avec d'autres méthodes pour obtenir les meilleurs résultats. Il existe notamment deux cas connus où le onTrimMemoryrappel n'est pas garanti d'être exécuté:
Si votre téléphone verrouille l'écran pendant que votre application est visible (par exemple, votre appareil se verrouille après nn minutes), ce rappel n'est pas appelé (ou pas toujours) parce que l'écran de verrouillage est juste au-dessus, mais votre application est toujours en cours d'exécution, bien que couverte.
Si votre appareil est relativement faible en mémoire (et soumis à un stress mémoire), le système d'exploitation semble ignorer cet appel et passer directement à des niveaux plus critiques.
Maintenant, selon l'importance pour vous de savoir quand votre application est passée en arrière-plan, vous devrez peut-être étendre cette solution avec le suivi du cycle de vie de l'activité et ainsi de suite.
Gardez simplement à l'esprit ce qui précède et ayez une bonne équipe d'AQ;)
FIN DE MISE À JOUR
Il peut être tard, mais il existe une méthode fiable dans Ice Cream Sandwich (API 14) et au-dessus .
Il s'avère que lorsque votre application n'a plus d'interface utilisateur visible, un rappel est déclenché. Le rappel, que vous pouvez implémenter dans une classe personnalisée, s'appelle ComponentCallbacks2 (oui, avec deux). Cette fonction de rappel n'est disponible qu'en API niveau 14 (Ice Cream Sandwich) et au-dessus.
Vous obtenez essentiellement un appel à la méthode:
public abstract void onTrimMemory (int level)
Le niveau est de 20 ou plus spécifiquement
public static final int TRIM_MEMORY_UI_HIDDEN
J'ai testé cela et cela fonctionne toujours, car le niveau 20 n'est qu'une "suggestion" que vous souhaitiez peut-être libérer certaines ressources car votre application n'est plus visible.
Pour citer les documents officiels:
Niveau pour onTrimMemory (int): le processus montrait une interface utilisateur et ne le fait plus. De grandes allocations avec l'interface utilisateur doivent être libérées à ce stade pour permettre une meilleure gestion de la mémoire.
Bien sûr, vous devez l'implémenter pour faire ce qu'il dit (purger la mémoire qui n'a pas été utilisée depuis un certain temps, effacer certaines collections qui étaient inutilisées, etc. Les possibilités sont infinies (voir les documents officiels pour d'autres plus possibles). niveaux critiques ).
Mais, ce qui est intéressant, c'est que le système d'exploitation vous dit: HEY, votre application est passée en arrière-plan!
C'est exactement ce que vous vouliez savoir en premier lieu.
Comment déterminez-vous votre retour?
Eh bien c'est facile, je suis sûr que vous avez une "BaseActivity" afin que vous puissiez utiliser votre onResume () pour signaler le fait que vous êtes de retour. Parce que la seule fois où vous direz que vous n'êtes pas de retour, c'est lorsque vous recevez réellement un appel à la onTrimMemoryméthode ci-dessus .
Ça marche. Vous n'obtenez pas de faux positifs. Si une activité reprend, vous êtes de retour, 100% du temps. Si l'utilisateur retourne à l'arrière, vous recevez un autre onTrimMemory()appel.
Vous devez vous inscrire à vos activités (ou mieux encore, un cours personnalisé).
Le moyen le plus simple de garantir que vous recevez toujours ceci est de créer une classe simple comme celle-ci:
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.
}
}
Pour l'utiliser, dans votre implémentation d'application ( vous en avez un, DROIT? ), Faites quelque chose comme:
MemoryBoss mMemoryBoss;
@Override
public void onCreate() {
super.onCreate();
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.ICE_CREAM_SANDWICH) {
mMemoryBoss = new MemoryBoss();
registerComponentCallbacks(mMemoryBoss);
}
}
Si vous créez un, Interfacevous pouvez ajouter un elseà cela ifet implémenter ComponentCallbacks(sans le 2) utilisé dans quoi que ce soit en dessous de l'API 14. Ce rappel n'a que la onLowMemory()méthode et n'est pas appelé lorsque vous passez en arrière-plan , mais vous devez l'utiliser pour réduire la mémoire .
Maintenant, lancez votre application et appuyez sur home. Votre onTrimMemory(final int level)méthode doit être appelée (indice: ajouter la journalisation).
La dernière étape consiste à se désinscrire du rappel. Le meilleur endroit est probablement la onTerminate()méthode de votre application, mais cette méthode n'est pas appelée sur un appareil réel:
/**
* 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.
*/
Donc, sauf si vous avez vraiment une situation où vous ne voulez plus être enregistré, vous pouvez l'ignorer en toute sécurité, car votre processus est en train de mourir au niveau du système d'exploitation de toute façon.
Si vous décidez de vous désinscrire à un moment donné (si vous fournissez, par exemple, un mécanisme d'arrêt pour que votre application se nettoie et meure), vous pouvez faire:
unregisterComponentCallbacks(mMemoryBoss);
Et c'est tout.
