Android studio system exit

Android Process: Я тебя породил, я тебя и …

Вы когда-нибудь задумывались о том, что происходит с вашим приложением после того, как система убила его процесс за ненадобностью? Печально, но многие об этом даже не беспокоятся, словно это будет происходить в параллельной вселенной и их это не касается. Особенно этому подвержены новички. Их слепая вера в непоколебимость статик ссылок просто поражает.

В этой статье я расскажу о некоторых ошибках, которые могут возникнуть в результате нарушения шестой заповеди (не убей) по отношению к процессу приложения, и о том как проверить на сколько качественно он возвращается с того света.

Ни для кого не секрет, что процесс может быть убит системой. А вы интересовались, реально ли сымитировать это? Можно попробовать“натравить” систему на свое приложение, запуская кучу других приложений, съедающих знатный кусок памяти, а затем надеяться, что система таки снизошла до нас убив нужное приложение. Прямо какой-то шаманизм получается, а это стезя админов, но никак не программистов. Меня заинтересовало, как можно легко и быстро убить приложение, да так, будто это сделала система для освобождения ресурсов. Ведь если получится повторить подобное поведение в “лабораторных условиях”, можно будет отлавливать множество ошибок ещё на стадии разработки, либо с лёгкостью воспроизвести их для выявления причин.

Как оказалось, нужный механизм уже имеется в SDK, и это… барабанная дробь… Кнопка «Terminate Application».

Нажатие на нее аналогично выполнению следующего кода:
Это, собственно, и убивает процесс. Похожее действие происходит когда система пытается избавиться от ненужного процесса.

Для того, чтобы воспроизвести ситуацию с возобновлением работы приложения после его полной остановки, нужно проделать следующую последовательность действий:

1. Используя Android Stidio запустить приложение;
2. Свернуть приложение нажатием кнопки «Home»;
3. В Android Studio, перейти на вкладку Android, выбрать приложение и нажать кнопку «Terminate Application»;
4. Развернуть свернутое приложение.

Если Activity не совсем корректно обрабатывает восстановление после уничтожения, вы сразу это заметите. В лучшем случае оно упадёт, в худшем зависнет.

Итак, мы научились выманивать один из самых скрытных типов ошибок. Давайте научимся эти ошибки предвидеть. Начнем с самых очевидных случаев, а затем плавно перейдем к менее однозначным случаям.

Ситуация 1: Статик — это не надёжно

Как видно из кода, в первой Activity разработчик решил не “заморачиваться” и поместил данные в статические переменные. Это весьма соблазнительно, когда нужно передать достаточно неординарный объект, не поддающийся простой сериализации. Над второй Activity он тоже не долго думал и не сделал проверки на нул. Зачем, когда первая Activity всё уже сделала?

Проделываем описанную ранее последовательность по корректному уничтожению процесса на второй Activity. Приложение падает.

Что случилось?
Проблема тут не в отсутствии проверки на null. Самая страшная проблема — это потеря пользовательских данных. Статические объекты не должны быть хранилищем данных, особенно если это их единственное место. Касается это как обычных переменных так и синглтонов. Так что если в статике хранится что-то важное, будьте готовы это важное потерять в любой момент.

Что делать?
Наличие таких ошибок, зачастую, свидетельствует о низкой квалификации программиста, либо о слишком высоком чувстве лени. О том как делать правильно, написано огромное количество туториалов. В приведенном примере лучше всего подойдёт передача данных через бандл. Также можно писать эти данные в SharedPreferences, либо стоит задуматься о создании базы данных.
Важно: Не стоит забывать, что синглтон это тоже статик переменная. Если вы используете синглтон, то он должен выступать лишь как инструмент облегчающий доступ к данным, но ни как не быть единственным хранилищем для них.

Волшебная сила Application
Как часто я вижу советы использовать класс Application как синглтон либо инициализировать синглтон в методе onCreate() класса Application. Якобы после этого он станет круче чем Ленин, то есть будет живее всех живых при любых обстоятельствах. Возможно, это частный случай заблуждения встретившийся только мне. Причем, все публикации которые я находил, явно не заявляют о подобных свойствах синглтона. В некоторых из них говорится, что синглтон может быть уничтожен сборщиком мусора если инициировать его в классе Activity (что для меня звучит немного дико). В других пугают выгрузкой класса из класслоадера (а это уже похоже на правду).

Сейчас я не собираюсь выяснять, что тут правда а что домыслы. В любом случае это лишь снижает вероятность потери статик ссылки но ни как не спасает от остановки процесса. Остановка процесса приведет к полному уничтожению класслоадера, а вместе с ним и уничтожению всех классов, включая класс Application.

Ситуация 2: setRetainInstance как решение всех проблем

Такая реализация — стойка к любым вращениям экрана. Все будет работать как часы. До поры до времени…
Применим последовательность действий для хитрого уничтожения процесса, когда диалог открыт. При разворачивании ничего не произойдет. Однако, при вызове invokePersonChoose приложение вылетит с NullPointerException.

Что случилось?
setRetainInstance(true) не позволяло диалогу уничтожиться. После уничтожения процесса диалог все-таки был уничтожен. Activity восстанавливает фрагмент насколько это возможно. К сожалению, слушатель не восстанавливается, так как он был установлен совершенно в другом месте для совершенно другого объекта. Когда в диалоге, в методе invokePersonChoose, происходит обращение к слушателю, выбрасывается исключение. И беда тут не в отсутствии проверки на null. Поставить проверку на null без должной реакции на пустую ссылку будет еще более худшим решением.

Что делать?
В интернете описана куча способов передачи сообщений из фрагмента в Activity. К сожалению, не все из них правильные. Следующий способ правильный и один из моих любимых:

Activity реализует нужный интерфейс:

Единственное, что не стоит забывать, Activity может быть уже уничтожена когда дело дойдет до отправки сообщения. Поэтому обязательно проверьте добавлен ли фрагмент на Activity.
По мимо Activity можно использовать родительский фрагмент или Target фрагмент.

Еще пара слов про setRetainInstance
Замечу, это лишь частный случай с setRetainInstance. Количество проблем которые он может скрыть(а не решить) немного больше. Вместе со слушателями также теряются и все остальные переменные. Все, что не было сохранено в методе onSaveInstanceState, будет потеряно.
Также, он скрывает проблему когда класс диалога анонимный. Допустим, в момент создания нового объекта диалога, переопределен какой либо метод, в этом случае создастся объект анонимного класса.

Если этот диалог будет уничтожен и система попытается его восстановить выбросится исключение ClassNotFoundException.

Ситуация 3: Разорванные нити

Если запустить этот код и не дожидаясь его завершения свернуть приложение, а затем вырубить процесс, то при разворачивании ничего не предвещает беды, приложение не падает, а диалог показывается. Ждём немножко… Ещё ждём… Потом ещё ждём… Диалог не закрывается, хоть и должен был сделать это уже давно.

Что случилось?
При уничтожении процесса останавливаются все его потоки, а при восстановлении запускается только главный поток. Так что если ваш поток работает слишком долго, будьте готовы к тому, что он будет остановлен. Причём не обязательно делать что-то долго, на эти грабли можно наступить и при использовании wait notify. Особенно забавно будет, если в качестве объекта для блокировки использовать public static final Object, ведь мы то уже знаем, что статик объекты не исключение при уничтожении процесса.

Что делать?
Если задача занимает много времени вынести ее в отдельный сервис и запустить в новом процессе, плюс вывести foreground Notification, иначе процесс все равно будет убит. В случае с wait notify все немного сложнее и зависит от конкретной ситуации. Вообще, тема работы с потоками достаточно обширна, и давать какой-то конкретный совет тут неуместно. Разве что не усложнять и не лезть в дебри, из которых не сможешь вылезти.

Ситуация 4: Письмо в никуда

Для того чтобы первая Activity не уничтожалась при поворотах экрана, в файл манифеста добавлены configChanges.

Во второй Activity есть кнопка, нажатие по которой шлет сообщение для смены цвета.

При возвращении на первую Activity цвет View будет изменен.

Однако, если перейти на вторую Activity, свернуть приложение, убить процесс, а затем развернуть приложение, случится кое-что не предвиденное. Сколько бы раз вы не нажимали на кнопку смены цвета, при возвращении на первую Activity ее View будет белоснежной.

Что случилось?
Не смотря на то, что стек активностей сохранился, после разворачивания приложения была восстановлена только вторая Activity. Фактически, сообщения о смене цвета уходили в никуда. Так как на тот момент не существовало объектов, подписанных на это событие. При возвращении на первую Activity она была восстановлена, но подписываться на событие смены цвета было уже поздно.

Что делать?
Первым делом нужно уяснить главное — если вы работаете с одной Activity, остальные для нее не существуют. Если нужно донести какую либо информацию, используйте предназначенный для этого setResult. Еще не следует слепо полагаться на жизненные циклы. Как видно из примера, если Activity 1 запустила Activity 2 то это еще не значит, что метод onCreate первой Activity был выполнен.
Также замечу, этот пример показывает не только на проблемы со стеком активностей, но и проблемы со всем, что связано с посылкой сообщений. Исключением будут только BroadcastReceiver-ы, прописанные в манифесте, либо запланированные через AlarmManager. Все остальное не дает 100% гарантии на доставку сообщения адресату.

Заключение

“Бывалым кодерам” эти ситуации могут показаться очевидными, а примеры на столько не естественными, что просто воротит. Однако, все мы когда-то начинали с нуля и писали код от которого сейчас было бы стыдно. Знай я об этих граблях в самом начале своего пути, шишек на лбу было бы меньше. Надеюсь, эта статья поможет наставить на путь истинный большое количество начинающих Android программистов. От “Бывалых” буду рад увидеть комментарии. А еще лучше если вы дополните список или напишете, помогла ли эта статья в ловле багов из разряда “Как?! Такого не может быть!”.

На этом закончу. Спасибо за внимание. Напоследок замечу, в рукаве у меня еще остался один неординарный случай. Он еще не изучен мной до конца, но я надеюсь в скором времени расколоть этот крепкий орешек. Так что ждите продолжения.

Источник

Разница между финишем () и System.exit (0)

Я говорю о программировании в Android.

В первые дни я думал, что finish() закрывает текущую активность и возвращается к предыдущему в Activity Activity, а System.exit(0) закрывает все приложение .

Но я был неправ. Я сделал небольшой эксперимент и понял, что Both закончат только текущую активность .

Единственные различия, которые я мог заметить, это то, что в Android 2.3.3

Но в Android 4.2.2 вызывается onActivityResult () для обоих! И Intent был null для выхода (). (Я тестировал только в этих двух устройствах)

• При использовании exit () существует временная задержка, тогда как finish() выполняется быстрее . (Похоже, что в exit () больше фоновых операций)

В чем разница между двумя?

В каких ситуациях я могу использовать exit ()?

Я считаю, что есть что-то большее, чего я не вижу между этими двумя методами. Надеюсь, кто-нибудь может объяснить и исправить меня.

РЕДАКТИРОВАТЬ ПО ЗАПРОСУ:

Сделайте приложение для Android с 2 мероприятиями. Вызовите вторую активность из деятельности Launcher, используя Intent. Теперь, во втором действии, нажав кнопку, вызовите System.exit(0); , « VM останавливает дальнейшее выполнение, и программа выйдет ». . (согласно документации )

Я вижу там первую активность. Зачем? (Вы можете доказать, что я ошибаюсь / я был прав)

На самом деле нет никакой разницы, если у вас есть только одно действие. Однако, если у вас есть несколько действий в стеке, тогда:

• Finish () – завершает действие, из которого он вызван, и вы видите предыдущую активность.
• System.exit (0) – перезапускает приложение с меньшим количеством действий в стеке. Итак, если вы вызвали ActivityB из ActivityA, а System.exit(0) вызывается в ActivityB, тогда приложение будет убито и немедленно запущено только с одним действием ActivityA

Согласно разработчику Android,

Назовите это, когда ваша деятельность будет завершена и должна быть закрыта. ActivityResult распространяется на тех, кто запустил вас через onActivityResult ().

VM останавливает дальнейшее выполнение, и программа выйдет.

Согласно документации, программа выйдет.
Но это похоже на ошибку в документации. В случае java-программы это правильно. Но, придя в Android, вы увидите предыдущую активность из стека.

Поскольку Android-кодирование выполняется с использованием java-кодирования, большая часть документации такая же, как и для Java.
Из документации,

System.exit (0)
VM останавливает дальнейшее выполнение, и программа выйдет.
Для аспект Android мы должны заменить слово «программа» на что-то еще. Может быть действием или контекстом.

Ответ Sa Qada правильный после моего тестирования.

Закончить будет закрывать эту деятельность и вернуться к прежнему.

Но выход также закроет текущую активность и опустят все действия в режиме «замораживания» и начнут снова предыдущую активность

На самом деле нет никакой разницы, если у вас есть только одно действие. Однако, если у вас есть несколько действий в стеке, тогда:

Источник

A cautionary tale on Android: do not call System.exit()

Once upon a time… there was an issue that was hidden in plain sight! It lived freely for years without no one noticing it. Until one day, during a connectivity problem, he appeared leaving us speechless.

Well, this is not going to be a fairytale but instead a cautionary tale. My goal with this article (and probably a couple more that are gaining some dust on drafts) is to create awareness on some scenarios that might arise during Android development — in this first one, why you should never call System.exit(n) or in Kotlin exitProcess(n)

Use case

Although the use case where I’ve found the issue is a bit complex to exemplify, I’ve created a simple project to easily show what was happening.

Imagine a simple application with just two activities:
— MainActivity
— SecondActivity

They extend from AppCompatActivity and don’t have any special attribute declared on the AndroidManifest (no launchMode , nothing)

The layout is also really simple on both — it has only one button with a defined user action.

On MainActivity it starts SecondActivity

And in SecondActivity the button, calls exitProcess(2) (Kotlin’s equivalent to Java’s System.exit() ) in order to terminate the app.

Now let’s follow this use case: the user opens the app, clicks on the first button, the second activity is displayed and now she clicks on btn_action defined above. What will happen to the application?

— It will terminate and the user gets back to the home screen?

Diving in

System.exit()
Terminates the currently running Java Virtual Machine. The argument serves as a status code; by convention, a nonzero status code indicates abnormal termination.

Or in other words, we can say that the system will terminate the application running process and along with it all the associated data — the current activity, app data, etc.

If we look at the device logs we’ll see exactly this:

Note: I’ve cleaned the logs to filter and highlight the important information.

What’s not explicitly said on the documentation is that if there’s any activity from the application paused — or in other words, that wasn’t finished — it will be kept on the back stack (activity stack) and will be resumed once there’s no more activities on top of it.

To make things easier, I’ve made a simple diagram where we can visualize the entire process:

When the application calls System.exit() the system will indeed kill the current process and remove the activity from the back stack (in this case SecondActivity ) and it will also resume the activity that it’s below on the stack — which in this case will be from the same application since there’s no call to finish() on our code.

With this, the application will restart.

Solution

The solution here is simple. If you want to exit an activity you should just call finish() . Of course, there are use cases where you have more activities on the back stack, for that you should call instead finishAffinity() which will remove all the activities that share the same affinity — which if you haven’t defined one it’s the same for all.

With this our updated diagram will be:

Notes

I’ve read that some people were expecting that calling System.exit() would be the equivalent to force stop the app, but as we could see it is not true.

If the user decides to force stop the app all the activities on the stack that belong to this application are also removed (and with this no restart will take place).

Have the system perform a force stop of everything associated with the given application package. All processes that share its uid will be killed, all services it has running stopped, all activities removed, etc.

Источник