Класс приложения: иногда он воссоздается
Скажите, есть ли у меня это право: если при запуске приложения Android существует класс, который расширяет android.app.Application, этот класс будет создан при запуске приложения.Но если приложение не используется, этот экземпляр может быть удален, а затем создан заново, когда приложение снова выйдет на передний план.Поэтому, если есть какие-либо переменные экземпляра, которые были инициализированы ранее, эти переменные больше не устанавливаются.
Проверка надежности воссоздания экземпляра приложения
Этот вопрос о том, как проверить, насколько хорошоприложение переживает процесс воссоздания своего класса приложения.
Я обнаружил, что могу заняться делом в своем приложении, а затем переключаться на другие приложения на «долгое время» (порядка часов)и когда я возвращаюсь, я вижу, что конструктор работает в моем классе, который расширяет android.app.Application.Проблема в том, что я не знаю, как заставить это воссоздание, чтобы я мог эффективно тестировать.
Перезапуск с различных действий
Я добавляю этот абзац к первоначальному вопросу, чтобы привлечь вниманиена тестирование, которое я хотел бы провести.Я хотел бы остановиться на вышесказанном, где я сказал "... перейти к операции в моем приложении, а затем переключиться (от моего приложения) ...". Идея в том, чтобы НЕ убиватьвсе приложение и начать 'сверху' .Пользователь находится внутри действия, которое в случае выживания экземпляра Application может вести себя односторонне, но если экземпляр Application будет воссоздан, то может вести себя по-другому.
Я не спрашиваюдля решения следующей проблемы в этом вопросе (она рассматривается в другом месте).Я прошу процесс, с помощью которого подобные проблемы могут быть обнаружены при тестировании.Итак, пример: предположим, что переменная экземпляра сохраняется в экземпляре Application при запуске начальной операции.Классы, которым нужна эта переменная, могут получить ее из экземпляра Application, но только в том случае, если первоначальная активность уже установила ее.Теперь ОС решает уничтожить и заново создать экземпляр Application.Когда пользователь выводит приложение на передний план, и он выполняет некоторую случайную активность (никогда не проходя через onCreate () начальной активности), переменная экземпляра имеет значение null.Если действие хорошо закодировано, оно не просто рухнет с NPE.Поэтому я пытаюсь проверить, чтобы в описанной выше ситуации, когда переменная экземпляра была равна нулю, приложение работало хорошо.Я думаю, что у меня есть, но я хотел бы убедиться, и я хотел бы убедиться, что независимо от того, какие действия выполняются, когда пользователь кладет трубку.
Как выглядит журнал
Если приложение оставлено на одном из дочерних действий и приложение находится в фоновом режиме на «долгое время», ОС уничтожает некоторые экземпляры класса.Когда приложение снова получает фокус, возникают некоторые процессы создания.Вот как выглядит журнал.
I/zygote: Late-enabling -Xcheck:jni
V/DaleApplication: DaleApplication constructor.
I/InstantRun: starting instant run server: is main process
V/DaleApplication: DaleApplication onCreate.
V/DaleDatabaseAdapter: constructor.
V/DaleListActivity: onCreate() is pulling records from the database.
V/DaleListActivity: >>>>>> Selection Args T
Вы можете видеть, что я включил регистрацию в DaleApplication, что расширяет android.app.Application.Кроме того, мы также видим, что он также воссоздает адаптер базы данных и начинает извлекать записи из базы данных, возвращая пользователя туда, где он был до того, как все эти объекты были уничтожены.
Ответ, который я ищу в этомвопрос может заключаться в том, что какой-нибудь процесс, который я мог бы предпринять, позволил бы мне вызывать уничтожение экземпляра класса по требованию, что позволило бы мне проверить, что процесс восстановления является правильным.* Хотя я полагал, что уничтожение всего приложения не сработает, ответ ниже предложил мне попробовать.Но, конечно, мне нужно действие, которое пользователь использовал во время возобновления работы телефона.
1) Я попытался уничтожить через adb:
После того, как моя командная строка adb.exe заработала, я смог получить pid для своего приложения, используя adb shell, затем pidof ..(aid)..,где ..(aid).. - это ApplicationId в build.gradle.Это вернуло 13488.
Я пытался убить приложение, используя am kill ..(aid).., но это ничего не сказало, и pid все еще был там.Я пытался kill 13488, но это сказал Operation not permitted.С -9 не помогло.
РЕДАКТИРОВАТЬ: я наконец-то заставил этот метод работать после того, как наконец выяснил, с каким экземпляром adb.exe взаимодействовать.Это было эквивалентно нажатию кнопки «Завершить приложение» [см. Пункт «3)» ниже.
2) Я попытался нажать «красный квадрат» в окне средства отладки:
ВВ окне инструмента отладки я выбрал «Потоки».Там было много вещей.Я понятия не имел, какую нить прекратить, чтобы подражать пользователю, отключившему телефон на час.После остановки main, когда я вернулся к приложению на своем телефоне, приложение запустило основное действие (не так, как если бы воссоздается только класс Application, который запускается независимо от того, какое дочернее действие выполнялось ранее).
РЕДАКТИРОВАТЬ: Я думаю, что это не очень хороший подход, но здесь может быть какой-то поток, который не заставляет Android начать предыдущее действие вместо последнего действия.Больше не расследовал, потому что этот ответ решил проблему для меня .
3) Завершить работу кнопки приложения в Logcat:
Я смог нажать«Домой» на телефоне, затем нажмите «красный квадрат» в окне logcat, но это заставило меня заняться до активностью, которой я занимался, когда нажимал кнопку домой.
Из того, что я понимаю, когда вы закрываете приложение из Android Studio (logcat) , Android предполагает, что текущая активность ведется плохопоэтому вместо запуска запускается предыдущая операция. Это не соответствует поведению, когда телефон откладывается в течение длительного времени, а затем приложение восстанавливается на переднем плане.