2018: Android поддерживает это изначально с помощью компонентов жизненного цикла.
Март 2018 ОБНОВЛЕНИЕ : теперь есть лучшее решение. Смотрите ProcessLifecycleOwner . Вам нужно будет использовать новые компоненты архитектуры 1.1.0 (последние на данный момент), но они специально предназначены для этого.
В этом ответе приведен простой пример, но я написал пример приложения и пост в блоге об этом.
С тех пор, как я написал это в 2014 году, возникли разные решения. Некоторые работали, некоторые, как думали, работали , но имели недостатки (включая мою!), И мы, как сообщество (Android), научились справляться с последствиями и писали обходные пути для особых случаев.
Никогда не предполагайте, что один фрагмент кода является решением, которое вы ищете, это маловероятно; еще лучше, попытайтесь понять, что это делает и почему это делает.
Этот MemoryBossкласс никогда не использовался мной, как написано здесь, это был просто кусок псевдокода, который сработал.
Если у вас нет веской причины не использовать новые компоненты архитектуры (а некоторые есть, особенно если вы нацелены на супер старые apis), тогда используйте их. Они далеки от совершенства, но ни один не был ComponentCallbacks2.
ОБНОВЛЕНИЕ / ЗАМЕТКИ (ноябрь 2015 г.) : люди делали два комментария, во-первых, это >=следует использовать вместо того, ==потому что в документации говорится, что вы не должны проверять точные значения . Это хорошо для большинства случаев, но имейте в виду, что если вы заботитесь только о чем-то когда приложение перешло в фоновый режим, вам придется использовать ==, а также объединить его с другим решением (например, обратными вызовами Activity Lifecycle), или вы может не получить желаемого эффекта. Пример (и это случилось со мной): если вы хотите заблокироватьВаше приложение с экраном паролей, когда оно переходит в фоновый режим (например, 1Password, если вы знакомы с ним), вы можете случайно заблокировать свое приложение, если у вас мало памяти и вы вдруг тестируете >= TRIM_MEMORY, потому что Android вызовет LOW MEMORYвызов, и это выше твоего. Так что будьте осторожны, как / что вы тестируете.
Кроме того, некоторые люди спрашивают о том, как определить, когда вы вернетесь.
Простейший способ, который я могу придумать, объясняется ниже, но, поскольку некоторые люди не знакомы с ним, я добавляю здесь псевдокод. Предполагая, что у вас есть YourApplicationи MemoryBossклассы, в вашем class BaseActivity extends Activity(вам нужно будет создать один, если у вас его нет).
@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);
}
}
Я рекомендую onStart, потому что диалоги могут приостанавливать действие, поэтому держу пари, что вы не хотите, чтобы ваше приложение считало «оно ушло на задний план», если все, что вы делали, это отображали полноэкранное диалоговое окно, но ваш пробег может отличаться.
И это все. Код в блоке if будет выполнен только один раз , даже если вы перейдете к другому действию, новый (который также extends BaseActivity) сообщит о wasInBackgroundтом, falseчто он не будет выполнять код, пока не onMemoryTrimmedбудет вызван и флаг снова не будет установлен в true ,
Надеюсь, это поможет.
ОБНОВЛЕНИЕ / ЗАМЕТКИ (апрель 2015 г.) : Прежде чем перейти к копированию и вставке этого кода, обратите внимание, что я обнаружил пару случаев, когда он может быть ненадежным на 100% и должен сочетаться с другими методами для достижения наилучших результатов. В частности, есть два известных случая, когда onTrimMemoryобратный вызов не гарантированно будет выполнен:
Если ваш телефон блокирует экран, когда ваше приложение видно (скажем, ваше устройство блокируется через nn минут), этот обратный вызов не вызывается (или не всегда), потому что экран блокировки находится сверху, но ваше приложение все еще «работает», хотя и закрыто.
Если у вашего устройства относительно мало памяти (и он испытывает недостаток памяти), операционная система, похоже, игнорирует этот вызов и сразу переходит к более критическим уровням.
Теперь, в зависимости от того, насколько важно для вас знать, когда ваше приложение перешло в фоновый режим, вам может понадобиться, а может и не понадобиться расширять это решение вместе с отслеживанием жизненного цикла активности и так далее.
Просто имейте это в виду и получите хорошую команду по тестированию;)
КОНЕЦ ОБНОВЛЕНИЯ
Это может быть поздно, но есть надежный метод в Ice Cream Sandwich (API 14) и выше .
Оказывается, что когда ваше приложение не имеет больше видимого интерфейса, вызывается обратный вызов. Обратный вызов, который вы можете реализовать в пользовательском классе, называется ComponentCallbacks2 (да, с двумя). Этот обратный вызов доступен только в API уровня 14 (Ice Cream Sandwich) и выше.
Вы в основном получаете вызов метода:
public abstract void onTrimMemory (int level)
Уровень 20 или более конкретно
public static final int TRIM_MEMORY_UI_HIDDEN
Я тестировал это, и оно всегда работает, потому что уровень 20 - это просто «предложение», что вы можете захотеть освободить некоторые ресурсы, так как ваше приложение больше не видно.
Цитировать официальные документы:
Уровень onTrimMemory (int): процесс показывал пользовательский интерфейс и больше не делает этого. На этом этапе следует освободить большие выделения с помощью пользовательского интерфейса, чтобы обеспечить лучшее управление памятью.
Конечно, вы должны реализовать это, чтобы на самом деле делать то, что он говорит (очистить память, которая не использовалась в определенное время, очистить некоторые коллекции, которые оставались неиспользованными, и т. Д. Возможности безграничны (другие официальные документы см. Для более подробной информации). критические уровни).
Но, что интересно, ОС говорит вам: ЭЙ, ваше приложение ушло на второй план!
Что именно то, что вы хотели знать в первую очередь.
Как вы определяете, когда вернулись?
Ну, это легко, я уверен, что у вас есть «BaseActivity», так что вы можете использовать onResume (), чтобы отметить тот факт, что вы вернулись. Потому что единственный раз, когда вы будете говорить, что вы не вернулись, это когда вы на самом деле получаете вызовonTrimMemory методу.
Оно работает. Вы не получаете ложных срабатываний. Если действие возобновляется, вы возвращаетесь в 100% случаев. Если пользователь снова идет назад, вы получаете другойonTrimMemory() звонок.
Вы должны подписать ваши действия (или еще лучше, пользовательский класс).
Самый простой способ гарантировать, что вы всегда получите это, - создать простой класс, подобный этому:
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.
}
}
Чтобы использовать это, в вашей реализации приложения (у вас есть одна, RIGHT? ), Сделайте что-то вроде:
MemoryBoss mMemoryBoss;
@Override
public void onCreate() {
super.onCreate();
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.ICE_CREAM_SANDWICH) {
mMemoryBoss = new MemoryBoss();
registerComponentCallbacks(mMemoryBoss);
}
}
Если вы создадите объект, Interfaceвы можете добавить elseк нему ifи реализовать ComponentCallbacks(без 2), который используется в API ниже 14. Этот обратный вызов имеет только onLowMemory()метод и не вызывается при переходе в фоновый режим. , но вы должны использовать его для обрезки памяти. ,
Теперь запустите приложение и нажмите «Домой». Ваш onTrimMemory(final int level)метод должен быть вызван (подсказка: добавить ведение журнала).
Последний шаг - отменить регистрацию в обратном вызове. Вероятно, лучшим местом является onTerminate()метод вашего приложения, но этот метод не вызывается на реальном устройстве:
/**
* 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.
*/
Поэтому, если у вас действительно нет ситуации, когда вы больше не хотите регистрироваться, вы можете игнорировать ее, поскольку ваш процесс в любом случае умирает на уровне ОС.
Если в какой-то момент вы решите отменить регистрацию (например, если вы предоставите механизм завершения работы своего приложения для очистки и смерти), вы можете сделать следующее:
unregisterComponentCallbacks(mMemoryBoss);
И это все.
