Обзор того, как действия уничтожаются системой - PullRequest
0 голосов
/ 28 ноября 2010

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

Я думаю, что если действие приостановлено из-за входящего телефонного звонка (который внезапно вызывает низкий уровень активности)ситуация с памятью) система просто предпочитает высвобождать ресурсы прекращенной деятельности.Но как это сделать?Когда система «любезно запрашивает» действие, вызывая метод finish (), а когда нет, и когда по-прежнему вызывается onDestroy ()?

Ответы [ 2 ]

4 голосов
/ 06 июня 2011

Пар за курс, я вижу! Я вижу некоторую ценную информацию, смешанную с дорогой дезинформацией. Нет, онлайн-документы НЕ точно указывают, при каких обстоятельствах процесс прекращается. Это преднамеренно, так как может быть изменено без предварительного уведомления. Несомненно, наиболее распространенная причина вызова onDestroy () заключается в том, что системе не хватает памяти, что не так часто встречается на новых телефонах (так как у них так много памяти). Но нет никакой гарантии, что это ЕДИНСТВЕННАЯ причина, по которой это называется.

Но да, «контракт» между Android и разработчиками заключается в том, что если вы будете следовать правилам, реализуя необходимые обратные вызовы жизненного цикла, когда они необходимы, то это сработает, и вам НЕ НУЖНО точно знать, при каких обстоятельствах onStop (), onSaveInstanceState () и onDestroy () вызываются.

Теперь, в отличие от Google, я признаю, что формулировка контракта в некоторых моментах несколько расплывчата. Это связано с тем, что среди прочих менее важных причин они используют термины, которые имеют стандартное отраслевое значение, например «передний план», но используют их в слегка измененных смыслах. И изменение никогда не объясняется или объясняется только в неясных местах. Также не помогает то, что диаграмма имеет целью показать «пути, по которым активность может проходить между состояниями», но не в состоянии показать, что onDestroy () может вызываться много раз, даже в обход перехода от Resumed к Stopped. Тем не менее, текст четко описывает эту возможность.

Вот почему, к сожалению, просто недостаточно прочитать раздел «Жизненный цикл приложения» «Основы приложения». Вместо этого нужно также прочитать Javadoc для КАЖДОГО из обратных вызовов для этого для Activity, а также раздел «Основы применения» по процессам.

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

4 голосов
/ 28 ноября 2010

Большая часть того, что вы спросили, довольно хорошо описана в документации, но я думаю, что могу уточнить пару вещей.

Я хотел бы знать разницу между приостановленным и остановленным состоянием.

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

Я думаю ... система просто предпочитает освободить ресурсы остановленных деятельность. Но как это сделать?

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

Когда система «просит» активность по вызову finish () и когда нет, а когда делает onDestroy () еще позвонить?

Система выполнит упорядоченное уничтожение, когда сможет, но API только гарантирует, что активность когда-либо увидит onPause() и onSaveInstanceState().

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

...