Не одобряется ли выход из приложения?

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

System.exit() не убивает ваше приложение, если в стеке есть более одного действия. На самом деле происходит то, что процесс убит и сразу же перезапускается с помощью одного меньше активности в стеке. Это также происходит, когда ваше приложение убивается диалогом Force Close или даже когда вы пытаетесь убить процесс из DDMS. Насколько мне известно, это факт, который, как мне кажется, полностью не документирован.

Короткий ответ: если вы хотите выйти из приложения, вам нужно отслеживать все действия в вашем стеке и finish() ВСЕ, когда пользователь хочет выйти (и нет, нет способа для итерации по стеку активности, поэтому вам нужно все это самостоятельно управлять). Даже это фактически не убивает процесс или какие-либо болтающиеся ссылки, которые у вас могут быть. Он просто заканчивает деятельность. Кроме того, я не уверен, работает ли Process.killProcess(Process.myPid()) лучше; Я не тестировал его.

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

Длинный ответ включает объяснение философии, лежащей в основе этого поведения. Философия рождается из ряда предположений:

• Прежде всего, это происходит только тогда, когда ваше приложение находится на переднем плане. Если он находится в фоновом режиме, процесс завершится просто отлично. Однако, если он находится на переднем плане, ОС предполагает, что пользователь хочет продолжать делать то, что он/она делает. (Если вы пытаетесь убить процесс из DDMS, сначала нажмите кнопку "домой", а затем убейте его).
• Он также предполагает, что каждое действие не зависит от всех других видов деятельности. Это часто бывает так, например, в том случае, если ваше приложение запускает действие браузера, которое полностью разделено и не написано вами. Активность браузера может создаваться или не создаваться в одной и той же Задаче, в зависимости от ее атрибутов манифеста.
• Предполагается, что каждая ваша деятельность полностью независима и может быть убита/восстановлена ​​в одно мгновение. (Мне скорее не нравится это конкретное предположение, поскольку в моем приложении много действий, которые основаны на большом количестве кэшированных данных, слишком больших, чтобы эффективно сериализоваться во время onSaveInstanceState, но что делать?). Для большинства хорошо написанных приложений для Android это должно быть правдой, так как вы никогда не знаете, когда ваше приложение будет убито в фоновом режиме.
• Конечным фактором является не столько предположение, сколько ограничение ОС: убийство приложения явно такое же, как и при сбое приложения, а также то же, что Android, убивающий приложение для восстановления памяти. Это завершает наш coup de grace: поскольку Android не может сказать, что приложение вышло из строя или было разбито или было убито в фоновом режиме, предполагается, что пользователь хочет вернуться туда, где они остановились, и поэтому ActivityManager перезапустит этот процесс.

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

Скажите, что я хочу, чтобы мои пользователи могли делать снимок и загружать его. Я запускаю Camera Activity из своей активности и прошу вернуть изображение. Камера помещается в верхнюю часть моей текущей задачи (а не создается в ее собственной Задаче). Если у камеры есть ошибка, и она падает, это должно привести к сбою всего приложения? С точки зрения пользователя только сбой камеры, и они должны быть возвращены к предыдущему действию. Таким образом, он просто перезапускает процесс со всеми теми же действиями в стеке, минус камера. Поскольку ваши действия должны быть разработаны так, чтобы их можно было убить и восстановить при падении шляпы, это не должно быть проблемой. К сожалению, не все приложения могут быть спроектированы таким образом, поэтому это проблема для многих из нас, независимо от того, что говорит Ромен Гай или кто-либо еще. Итак, нам нужно использовать обходные пути.

Итак, мой заключительный совет:

• Не пытайтесь убить процесс. Вызывайте finish() для всех действий или вызывайте moveTaskToBack(true).
• Если ваш процесс вылетает из строя или его убивают, и если, как и мне, вам нужны данные, которые были в памяти, которые теперь потеряны, вам нужно вернуться к корневой активности. Чтобы сделать это, вы должны вызвать startActivity() с намерением, который содержит флаг Intent.FLAG_ACTIVITY_CLEAR_TOP.
• Если вы хотите убить свое приложение с точки зрения Eclipse DDMS, лучше не быть на переднем плане или перезапустить его. Сначала вы должны нажать кнопку "Домой", а затем убейте процесс.

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

Прекратите рассматривать приложение как монолитное приложение. Это набор экранов пользовательского интерфейса, которые пользователь может взаимодействовать с вашим "приложением" и "функциями", предоставляемыми через службы Android.

Не зная, что ваше таинственное приложение "делает" не очень важно. Предположим, что он туннелируется в суперсерверную корпоративную интрасеть, выполняет некоторый мониторинг или взаимодействие и остается включенным до тех пор, пока пользователь не "покинет приложение". Поскольку ваш ИТ-отдел командует им, пользователи должны быть очень внимательны, когда они находятся в IN или OUT из интрасети. Следовательно, ваше мышление важно для пользователей "выйти".

Это просто. Сделайте службу, которая отправляет текущее уведомление на панели уведомлений, говоря: "Я в интрасети, или я запущен". Попросите эту службу выполнить все функции, необходимые для вашего приложения. Имейте действия, которые привязаны к этой службе, чтобы позволить вашим пользователям получать доступ к битам пользовательского интерфейса, которые им необходимы для взаимодействия с вашим "приложением". И у вас есть кнопка Android Menu → Quit (или выход из системы или что-то еще), которая сообщает службе о завершении работы, а затем закрывает сама деятельность.

Это, для всех целей и целей, именно то, что вы говорите, чего хотите. Сделал способ Android. Посмотрите на Google Talk или Google Maps Navigation, примеры этого "выхода" - это возможный менталитет. Единственное различие заключается в том, что нажатие кнопки "Назад" из вашей активности может привести к тому, что ваш процесс UNIX будет ждать, если пользователь захочет оживить ваше приложение. Это ничем не отличается от современной операционной системы, которая кэширует недавно полученные файлы в памяти. После того, как вы покинете свою программу Windows, скорее всего, ресурсы, которые ей нужны, все еще находятся в памяти, ожидая замены другими ресурсами, поскольку они загружаются сейчас, когда они больше не нужны. Android - это то же самое.

Я действительно не вижу твоей проблемы.

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

Я также хотел бы добавить здесь свои два цента.

До сих пор я был впечатлен Android-способом обработки событий жизненного цикла, в результате чего концепция веб-подобных впечатлений появилась в родных приложениях.

Сказав, что я все еще считаю, что должна быть кнопка Quit. Зачем?... не для меня или Теда или любого из технических гуру здесь, но с единственной целью удовлетворения потребностей конечного пользователя.

Хотя я не большой поклонник Windows, но долго назад они представили концепцию, к которой привыкли большинство конечных пользователей (кнопка X)... "Я хочу отказаться от запуска виджета, когда" я "хочу",.

Это не значит, что кто-то (ОС, разработчик?) позаботится об этом по своему усмотрению... это просто означает "где моя кнопка" Красный X ", к которой я привык". Мое действие должно быть аналогично "завершать вызов нажатием кнопки", "выключать устройство, нажимая кнопку" и т.д. И т.д.... это восприятие. Это приносит удовлетворение как таковое, что мои действия действительно достигают своей цели.

Несмотря на то, что разработчик может обманывать это поведение, используя приведенные здесь предложения, восприятие по-прежнему остается, т.е. приложение должно полностью перестать функционировать (сейчас) независимым, надежным и нейтральным источником (ОС) по требованию конечного пользователя.

Вы можете выйти, нажав кнопку Back или позвонив finish() в Activity. Просто вызовите finish() из MenuItem, если вы хотите явно отключить его.

Ромен не говорит, что это невозможно сделать, просто это бессмысленно; пользователям не нужно заботиться о выходе или сохранении своей работы или что-то еще, поскольку способ жизненного цикла приложения побуждает вас писать интеллектуальное программное обеспечение, которое автоматически сохраняет и восстанавливает его состояние независимо от того, что происходит.

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

Тед сделал вывод, что одним из самых загруженных приложений на рынке является "Убийца приложений". Люди получают немного лишнего серотонина, когда они прекращают применение. Они привыкли к этому с помощью настольного компьютера/ноутбука. Это заставляет вещи двигаться быстро. Он поддерживает охлаждение процессора и включение вентилятора. Он использует меньше энергии.

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

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

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

Я предлагаю вам ознакомиться с разделами "Деятельность и услуги". Прекратите использовать термин "приложение" и начните ссылаться на компоненты, то есть на Activity, Service. Я думаю, вам просто нужно больше узнать о платформе Android; это изменение в мышлении из стандартного приложения для ПК. Тот факт, что ни одно из ваших сообщений не содержало слова "Активность" (за исключением часто задаваемых вопросов, т.е. Не ваших слов), говорит мне, что вам нужно прочитать еще кое-что.

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

Выдержки:

По моему опыту, что [пользователи] действительно хотят: Недвусмысленный способ гарантировать, что приложение перестанет потреблять ресурсы (батарея, циклы CPU, передача данных и т.д.).

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

• В большинстве случаев кнопка выхода просто вызывает Activity.finish(). Это в точности эквивалентно нажатию кнопки "Назад". Точно. Службы продолжают работать, и опрос продолжается. Пользователи могут подумать, что они убили приложение, но они этого не сделали, и вскоре они будут еще более раздражены.
• Теперь поведение вывода неоднозначно. Если ваша кнопка выхода просто закроет Activity или она также остановит все связанные службы, приемники и сигналы тревоги? Что делать Back? Что произойдет, если они ударят Home вместо этого? Что произойдет, если ваше приложение имеет виджет? Должна ли кнопка выхода останавливать это от обновления?

Решение состоит в том, чтобы заставить кнопку "Назад" вести себя так, как вы ожидали кнопку выхода. Еще лучше, просто перестаньте потреблять ресурсы всякий раз приложение не видно.

Идите дальше и прочитайте полную статью.

Если вы не можете понять, как сделать ваши данные/подключения (и тем самым ваше "приложение") постоянным, вы не сможете делать то, что вам "нужно" для Android.

Те, кто действительно загружает этих причудливых App Killers, обычно считают, что они не помогают использовать батареи или использование памяти, но препятствуют тому, чтобы ОС выполняла работу по эффективному управлению памятью...

http://android-developers.blogspot.com/2010/04/multitasking-android-way.html

Я думаю, что дело в том, что нет необходимости покидать приложение, если у вас нет программного обеспечения с ошибками. Android закрывает приложение, когда пользователь не использует его, и устройству требуется больше памяти. Если у вас есть приложение, которое должно запустить службу в фоновом режиме, вам, скорее всего, захочется отключить службу.

Например, Google Listen продолжает воспроизводить подкаст, когда приложение не отображается. Но всегда есть кнопка паузы, чтобы отключить подкаст, когда пользователь с ним работает. Если я правильно помню, Listen, даже добавляет ярлык в панель уведомлений, чтобы вы могли быстро перейти к кнопке паузы. Другим примером является приложение, например приложение twitter, которое постоянно проверяет службу в Интернете. Эти типы приложений должны действительно позволять пользователю выбирать, как часто опросить сервер, или даже опросить фоновый поток.

Если вам нужен код, который выполняется при выходе, вы можете переопределить onPause(), onStop() или onDestroy(), если это необходимо. http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle

Ответ: (Romain Guy): Пользователь этого не делает, система обрабатывает это автоматически. Это то, что жизненный цикл деятельности (особенно onPause/onStop/onDestroy) - для. Независимо от того, что вы делаете, не ставьте кнопка "выйти" или "выйти". Это бесполезно для Android модель приложения. Это также противоречит тому, как основные приложения работа.

1: Полностью выход из приложения может быть вообще неуправляемым, но это не бесполезно. Что делать, если у окон не было выхода? Система была бы медленной, поскольку память была заполнена, и OS должна была угадать, с какими программами вы были сделаны. Меня не волнует, что говорят Ромен Гай или даже Ларри Пейдж и Сергей Брин - это неоспоримые факты: системы работают медленнее, когда им приходится убивать задачи, чтобы получить их память, прежде чем можно будет запустить новое приложение. Вы просто не можете сказать мне, что не требуется время, чтобы убить приложение! Даже свет от далеких звезд требует времени... Там есть, что позволяет пользователю полностью закрыть приложения.

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

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

Если пользователь хочет свести к минимуму приложение, лучше всего его минимизировать. Если пользователь хочет выйти из приложения, то, в любом случае, лучше выйти.

Он нахмурился? Этот вид Android - они нахмурились. И многие многие независимые разработчики Android-новичков нахмурились.

Но когда дело доходит до него, есть хорошее кодирование и плохое кодирование. Есть хорошие модели потока программ, и есть плохие модели потока программ.

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

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

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

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

Приостановка и выход - две жизненно важные задачи и не выполняет роль другого.

Я бы подумал о том, чтобы прочитать "Android Wireless Application Development", опубликованную Addison-Wesley. Я просто заканчиваю его, и это ОЧЕНЬ тщательно.

Похоже, что у вас есть некоторые фундаментальные недоразумения на платформе Android. Я тоже был немного разочарован в первую очередь жизненным циклом приложений приложений для Android, но, подойдя к более глубокому пониманию, мне очень понравился этот подход. Эта книга ответит на все ваши вопросы и многое другое. Это действительно лучший ресурс, который я нашел для новых разработчиков Android.

Кроме того, я думаю, вам нужно отпустить линейный порт существующего приложения. Чтобы перенести приложение на платформу Android, часть дизайна приложения изменится. Используемый жизненный цикл приложения необходим, поскольку мобильные устройства имеют очень ограниченные ресурсы по сравнению с настольными системами и позволяют устройствам Android запускать несколько приложений в упорядоченном и ресурсосберегающем режиме. Сделайте еще более углубленное изучение платформы, и я думаю, вы поймете, что то, что вы хотите сделать, вполне осуществимо. Удачи.

Кстати, я не отношусь к Аддисону-Уэсли или к любому человеку или организации, связанной с этой книгой. После повторного чтения моего сообщения я чувствую, что я отрылся от маленького фанатика. Я просто действительно наслаждался этим и нашел его чрезвычайно полезным.:)

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

Но если сказать, где есть воля, есть способ. Android обеспечивает через класс android.os.Process гораздо лучший API, чем Java, для управления базовым процессом. И в отличие от Java, он не рассматривает разработчика как придурок, скрывая все это за простым вызовом java.lang.System.exit().

Итак, как вы просите свое приложение совершить самоубийство в Android? Ну, трюк прост:

Создайте свой собственный класс приложений Android, наследуя его от стандартного класса android.app.Application(не забудьте объявить его в файле AndroidManifest.xml).

Переопределите метод onCreate() и сохраните идентификатор процесса, который запустил ваше приложение:

this.pid = android.os.Process.myPid(); // Save for later use.

Теперь, чтобы убить ваше приложение, предоставьте метод kill():

android.os.Process.sendSignal(pid, android.os.Process.SIGNAL_KILL);

Теперь, когда вам нужно приложение для совершения самоубийства, просто введите приведение контекста приложения и вызовите метод kill!

((MySuicidalApp) context.getApplicationContext()).kill()

Просто помните, что из-за политик управления процессами в Android, особенно связанных с сервисами, Android может просто выбрать перезапуск службы (см. Вы не должны использовать убийцы задач на Android).

Когда я представляю приложение на Android, я вижу его так:

• Вы работаете с вашим приложением
• Телефон зазвонил
• Вы берете вызов
• В конце вызова вы вернетесь в свое приложение в том же месте, где вы были.

Для этого вам нужна кнопка Back или кнопка Home вашего телефона (короткое или длинное нажатие) и панель уведомлений.

Когда я выхожу из своего приложения, я использую только кнопку Back, пока не выйду из нее, или кнопку Home.

То, как большинство приложений задумано, я думаю. Но если мне нужна какая-то сессия или соединение, я дал понять пользователю с кнопкой входа/выхода из системы и уведомлением (панель заголовка или что-то еще). Это совсем другой стиль, чем чистое приложение "выход".

На ПК у вас есть компьютер с несколькими GUI, и на Android у вас, очевидно, есть несколько задач, но вы показываете только одно приложение за раз (я не рассматриваю виджеты здесь ^^). И на мобильном телефоне в любое время вы можете получить уведомление о чем-то более важном, чем то, что вы делаете.

Таким образом, вся концепция приложения зависит от чего-то другого, что "введите приложение - работа - выход из приложения".

Хммм...

Я думаю, что вы просто не видите приложение Android правильным способом. Вы можете сделать что-то почти так же, как легко:

• Поддерживает ли приложение состояние сохранения/восстановления, как это рекомендуется в документации для разработчиков.

• Если на этапе восстановления требуется какой-либо логин (нет доступной информации входа/сессии), сделайте это.

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

Таким образом вам все равно, действительно ли приложение действительно удалено из памяти или нет.

Если вы действительно хотите удалить его из памяти (это обескуражено и BTW с какой целью?), вы можете убить его условно в конце onDestroy() с помощью java.lang.System.exit(0) (или, возможно, restartPackage(..)?). Конечно, сделайте это только в том случае, если вы хотите "действительно закончить приложение", потому что onDestroy() является частью обычного жизненного цикла действий, а не конца приложения.

Ядро Linux имеет функцию Убийца без памяти (как упоминалось выше, политики настраиваются на уровне пользовательского пространства как так как ядро ​​не является оптимальным, но отнюдь не ненужным).

И он сильно используется Android:

• Убийца OOM не для пользовательского пространства

• Заметки для Android (OOM Killer Info - где вы можете настроить функцию OOM на Android)

• Android Портирование по реальной цели

Некоторые приложения для пользовательского пространства доступны для помощи в этих приложениях для удаления, например:

• Autokiller/Настройка внутреннего убийцы задач Android

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

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

Я бы добавил только, что для достижения полного эффекта, который обычно имеет выход приложения, вы бы хотели reset состояние приложения независимо от того, что его состояние обычно в то время, когда оно запускается после загрузки устройство, непосредственно перед вызовом finish() для всех ваших действий. Таким образом, если пользователь снова выберет ваше приложение, он, кажется, будет запущен "свежим", без какого-либо состояния, оставшегося от точки до симулированного "выхода" .

Если есть некоторые специальные действия, которые должны выполняться только при "выходе", например, при сохранении работы пользователя или что-то еще, вы также можете выполнить их до части повторной инициализации описанной выше процедуры.

Этот подход позволяет вам выполнить свою команду "выхода" , не нарушая философии Android, оставляя управление ресурсами ОС, включая закрытие приложений, в руках операционной системы.

Лично я бы не использовал этот подход, потому что пользователи Android ожидают, что приложение сохранит свою преемственность, когда они пересмотрят его, и поэтому они не привыкли к модальности "выхода" из приложения. Вместо этого я бы поддержал "ясную" функцию, которую пользователь может вызвать в reset приложение в какое-то начальное состояние по умолчанию, без необходимости "оставить" его в процессе.

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

Что касается system.exit(0):

Если вы решили использовать system.exit(0), чтобы закрыть приложение с грубой завершенностью (например, в результате нажатия последней кнопки на кнопку), я предупредил бы вас, что, хотя для меня это "работает", и в некоторых случаях это единственный способ, которым я смог закрыть приложение без каких-либо следов его останова, есть один незначительный сбой, который возникает в желе Bean, когда вы используете этот подход.

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

Я подозреваю, что причиной этого является то, что список последних приложений поддерживает ссылку на ваше приложение, которое стало неработоспособным из-за закрытия приложения с помощью system.exit(0). Более цивилизованное закрытие вашего приложения с помощью функции finish() могло бы сообщить OS таким образом, который позволил бы ему обновить список последних приложений, но system.exit(0), по-видимому, этого не делает.

Это не огромная проблема сама по себе, так как очень немногие люди откроют приложение из последних приложений, а затем выйдут из него, а затем немедленно откроют его из того же открытого списка последних приложений. И если они нажмут кнопку "Домой", а затем снова откроют список "Недавние приложения", ваша запись в приложении будет там, и она будет полностью функциональной. Но я думаю, что это показывает, что использование system.exit(0) может помешать правильной связи между вашим приложением и ОС, и это говорит о том, что могут быть другие, более серьезные, возможно, тонкие последствия использования этого подхода.

Я согласен с Тедом. Я понимаю, что выход из приложения не "Android-путь", но похоже, что это не должно быть исключено. Вот три причины, по которым вам может потребоваться реальный выход приложения (не просто активность):

• Пользователь может захотеть получить контроль над тем, какое приложение будет убито в случай низкой памяти. Если важное приложение A работает в фоновом режиме, то вам может потребоваться выйти из приложения B, когда вы закончите с ним, так что что приложение A не уничтожается операционной системой.

• Если ваше приложение имеет секретные данные, кэшированные в памяти, вы можете например, убить приложение, чтобы приложение virus/worm/rogue не могло его получить. я знать, что модель безопасности должна предотвращать это, но на всякий случай...

• Если ваше приложение использует ресурсы (например, сеть, ЦП, датчики и т.д.), которые могут негативно повлиять на телефон, а затем один из способов эти ресурсы освобождаются, чтобы выйти из приложения. я понимаю что хорошо управляемые приложения должны освобождать ресурсы, когда они не нужны. Но опять же, выход из приложения кажется разумным способом обеспечения этого.

Прежде всего никогда никогда не используйте System.exit(0). Это как заставить человека спать, ударяя его по голове!

Во-вторых: Я столкнулся с этой проблемой. Прежде чем поделиться своим решением, я хочу поделиться своими мыслями.

Я думаю, что "кнопка выхода" глупа. На самом деле действительно глупо. И я думаю, что пользователи (потребители), которые просят кнопку выхода для вашего приложения, тоже глупы. Они не понимают, как работает ОС и как управляют ресурсами (и она отлично справляется).

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

Но для этого вам нужно учиться и учиться, как все работает на Android. Во всяком случае, это мое решение предоставить пользователям "кнопку выхода".

Я создал меню параметров, всегда отображаемое в каждом действии (у меня есть супер-активность, которая делает это).

Когда пользователь нажимает на эту кнопку, это происходит:

Intent intent = new Intent(this, DashBoardActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);

SharedPreferences settings = getSharedPreferences(getString(PREF_ID), Context.MODE_PRIVATE);
SharedPreferences.Editor editor = settings.edit();
editor.putBoolean(FORCE_EXIT_APPLICATION, true);

  // Commit the edits!
editor.commit();
startActivity(intent);
finish();

Итак, я сохраняю в SharedPreferences, что хочу убить свое приложение, и я начинаю намерение. Посмотрите на эти флаги; те очистят все мои стопы, называя мою активность DashBoard, которая является моей "домашней" деятельностью.

Итак, в моей работе с панелью инструментов я запускаю этот метод в onResume:

private void checkIfForceKill() {

    // CHECK IF I NEED TO KILL THE APP

    // Restore preferences
    SharedPreferences settings = getSharedPreferences(
            getString(MXMSettingHolder.PREF_ID), Context.MODE_PRIVATE);
    boolean forceKill = settings.getBoolean(
            MusicSinglePaneActivity.FORCE_EXIT_APPLICATION, false);

    if (forceKill) {

        //CLEAR THE FORCE_EXIT SETTINGS
        SharedPreferences.Editor editor = settings.edit();
        editor.putBoolean(FORCE_EXIT_APPLICATION, false);

        // Commit the edits!
        editor.commit();

        //HERE STOP ALL YOUR SERVICES
        finish();
    }
}

И все будет хорошо.

Единственное, что я не понимаю, почему это происходит, это то, что когда я делаю последний финиш (и я проверил: он после всего правильного потока onPause → onStop → onDestroy), приложение все еще находится в недавнем (но это пусто).

Похоже, что последнее намерение (которое запустило DashboardActivity) по-прежнему находится в системе.

Мне нужно больше копать, чтобы удалить его.

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

В сущности, потому что вы не можете выйти из ОС, вы просто превращаетесь в самосозданное ничто.

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

Жизненный цикл приложения Android предназначен для пользователей мобильных телефонов, а не для пользователей компьютеров.

Жизненный цикл приложения - это жестоко упрощенная парадигма, необходимая для превращения сервера Linux в потребительское устройство.

Android - это Java over Linux, настоящая кросс-платформенная серверная ОС. Так оно и распространилось так быстро. Жизненный цикл приложения инкапсулирует базовую реальность ОС.

Для мобильных пользователей приложения установлены или не установлены. Нет концепции запуска или выхода. Фактически, процессы приложений должны выполняться до тех пор, пока ОС не освободит их для своих ресурсов.

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

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

`YourActivityname.this.finish()`;

Пример:

Intent intent = new Intent(getApplicationContext(), SMS.class);

startActivity(intent);
MainActivity.this.finish();

Чтобы никакая активность не выполнялась в фоновом режиме, и когда вы хотите выйти ваше приложение, используйте:

MainActivity.this.finish();
android.os.Process.killProcess(android.os.Process.myPid());
System.exit(0);
getParent().finish();

Этот выход работал как прелесть для меня:)

Для закрытия приложения в любой точке используйте флаг FLAG_ACTIVITY_CLEAR_TOP в Intent, а затем system.exit();

Или существует аналогичный способ, но без system.exit(), когда вы хотите выйти из этого метода:

public void exit() {
    startActivity(new Intent(this, HomeActivity.class).
    setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | IntentCompat.FLAG_ACTIVITY_CLEAR_TASK).putExtra(EXIT_FLAG, true));
}

В HomeActivity.onCreate() добавить следующий код

protected void onCreate(Bundle savedInstanceState) {
    if (getIntent().getBooleanExtra(EXIT_FLAG, false)) {
        if ((getIntent().getFlags() & Intent.FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY) == 0) {
            finish();
        }
    }
......................

Это будет работать без нарушения жизненного цикла Android.

Мне потребовалось больше времени, чтобы прочитать этот Q & A, чем фактически реализовать полузадачный жизненный цикл приложений Android.

Это приложение GPS, которое опросает точки и отправляет текущее местоположение в веб-службу каждые несколько секунд с помощью потока... Это может быть опрос каждые 5 минут в случае Ted для обновления, тогда onStop может просто запустить операцию обновления Тед беспокоился о том, что если кто-то был найден (асинхронный Тед, не кодируйте, как программист Windows, или ваши программы будут работать как программы Windows... eww, это не так сложно).

Я сделал некоторый исходный код в onCreate, чтобы настроить вещи для жизни активности, включая checkUpdate.start();:

...

@Override
public void onStart() {
    super.onStart();
    isRemote = true;
    checkUpdate.resume();

    locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 2000, 0, luh);
}

@Override
public void onPause() {
    isRemote = false;
    checkUpdate.suspend();
    locationManager.removeUpdates(luh);
    super.onStop();
}

Этот код может быть совершенно неправильным, но он работает. Это одно из моих первых приложений для Android.

Voilà, приложение, которое не потребляет процессор, когда оно находится в фоновом режиме, но сразу же готово к повторному открытию, потому что оно находится в ОЗУ (хотя и не содержит RAM, как и жизненный цикл Android)... приложение всегда готово, это телефон, парни/девушки. Если приложение должно было использовать всю оперативную память и не могло быть выключено ОС, тогда вещь может перестать звонить = P. Поэтому ОС должна иметь возможность закрыть приложение, когда оно находится в фоновом режиме (если ваше приложение не является 't ресурс hog он не будет закрыт BTW), поэтому давайте просто писать лучшие приложения.

Без функции выхода для разработчика приложения для их собственного приложения это очень плохой дизайн.

Мое приложение должно позволить динамически динамически изменять данные динамически во время выполнения, и пользователю необходимо перезапустить мое приложение, чтобы сделать эффект изменения, но Android не разрешил мое приложение перезапускать сам по себе. Android OS имеет очень плохой жизненный цикл приложения.

В любом случае, если вы хотите завершить свое приложение, вы всегда можете позвонить System.exit(0);.

Если у вас есть 10,20.. несколько активных операций, и вы хотите закончить их все и выйти из системы.

Создайте статический массив в application class или constants class.

Константы

public class Constants {

public static ArrayList<Activity> activities = new ArrayList<Activity>();

}

MainActivity Добавьте текущий массив ссылок в этот массив

activity = MainActivity.this; Constants.activities.add(activity);

public class MainActivity extends Activity {

    private ImageView imageButton;
    private Activity activity;


    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        activity = MainActivity.this;
        Constants.activities.add(activity);

        imageButton = (ImageView) findViewById(R.id.camera);
        imageButton.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {

                // existing app.
                if (Constants.activities != null) {
                    for (int i = 0; i < Constants.activities.size(); i++) {
                        Activity s = Constants.activities.get(i);
                        s.finish();
                    }
                }
                //super.finish();
                finish();
                android.os.Process.killProcess(android.os.Process.myPid());
                System.exit(1);
            }
        });
    }
}

Для первой (начальной) активности приложения

@Override
public void onBackPressed(){

    // Exit
    moveTaskToBack(true);
}

работал у меня. Я хочу закрыть приложение здесь. И вернуться от других видов деятельности; Я использовал намерения, например.

@Override
public void onBackPressed(){

    // Going back....
    Intent intent = new Intent(ActivityB.this, ActivityA.class);
    startActivity(intent);
    finish();
}

Примечание. Этот код полезен для сценария, в котором разработчик хочет вернуться из ActivityZ в ActivityA, а затем закрыть приложение.

Это довольно просто. Просто следуйте этим инструкциям, которые я вам скажу:

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

Intent i1 = new Intent(this, AnotherActivity);
startActivity(i1) 

Вам нужно только добавить finish(); после запуска активности намерения по каждому виду деятельности от начала до конца, например,

Intent i1=new Intent(this, AnotherActivity);
startActivity(i1) 
finish();

Поэтому всякий раз, когда вы нажимаете эту кнопку выхода, которая использует финиш() или System.exit(0), которые должны полностью закрыть ваше приложение.

Используйте этот код:

Intent i = new Intent();
i.setAction(Intent.ACTION_MAIN);
i.addCategory(Intent.CATEGORY_HOME);
ListActivity.this.startActivity(i);
finish();

Еще одним вариантом могут быть службы доступности Android, которые используют Greenify Application, для принудительного закрытия приложений для ускорения работы с памятью. Имея доступ к службе доступности приложений, вы можете щелкнуть по кнопкам, так что в основном Greenize Application нажимает кнопку закрытия силы, найденную в настройках приложения:

Здесь вы можете изучить службы доступности: https://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html

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

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

1) Зарегистрировать приложение для служб доступности. 2) В зависимости от ваших требований, если вы хотите убить все приложения, получите список всех пакетов. 3) Перейдите к экрану настроек и нажмите кнопку "Закрыть ключ". Я могу поделиться примером кода. Я также создал приложение, такое как greenify, как домашнее задание. спасибо

Обновление: "Пользователь этого не делает, система обрабатывает это автоматически". Таким образом, в основном с этим решением мы косвенно используем силу системы, но по запросу пользователя. Итак, чтобы оба остались довольны :-)

Если вы укажете API >= 16, Activity # finishAffinity() удовлетворит ваши потребности.

Вы можете использовать Process.killProcess(Process.myPid());, чтобы убить ваше приложение, но, возможно, это не безопасно? Я не сталкивался с какой-либо проблемой или сбой после использования этого метода, и после того, как я использовал это, процесс моего приложения в списке DDMS исчез.

В настоящее время я применил следующее в своем приложении. Пусть это поможет выходить из приложения из любой нужды. Я вызываю эту функцию из меню панели действий.

public static void exitApplication(Context context) {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
        exitApplicationHC(context);
    }
    else {
        exitApplicationPreHC(context);
    }
}

private static void exitApplicationPreHC(Context context) {
    Intent i = new Intent(context, LoginActivity.class);
    i.putExtra(EXTRA_EXIT, true);
    i.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
    i.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
    context.startActivity(i);
    if (context instanceof Activity) {
        ((Activity) context).finish();
    }
}

@TargetApi(Build.VERSION_CODES.HONEYCOMB)
private static void exitApplicationHC(Context context) {
    Intent i = new Intent(context, LoginActivity.class);
    i.putExtra(EXTRA_EXIT, true);
    i.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
    i.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
    i.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TASK);
    context.startActivity(i);
}

Одной из важных причин появления кнопки выхода является реклама "on exit". На выходе можно отобразить какое-то объявление, приносящее доход. Это все еще несколько раздражает, как и все объявления, но может быть менее раздражающим, чем что-то, что держится все время, используя драгоценное пространство экрана. Некоторые рекламные сети предлагают такой способ рекламы. Но, действительно, вы не можете просто поместить кнопку выхода, которая ничего не делает после показа этого объявления!

В результате в некоторых случаях требуется тот или иной способ прекратить работу программы, и "никогда не понадобится" может быть не самым полным ответом.

Activity.finish() или System.exit(0).