Главная » Разработка для Android » Изменения конфигурации и жизненный цикл активности в Android приложении

0

 

Выше мы рассказали, как можно спровоцировать систему Android завершить процесс, в котором работает активность или любой другой компонент приложения. Для этого нужно просто запустить достаточно много приложений, чтобы системе пришлось завершить некоторые процессы. Если после этого просмотреть регистрационный журнал и рис. 11.5, то можно увидеть, что ID процесса изменяется и что создается новый экземпляр подкласса Activity, определяющий, как программа будет взаимодействовать с пользователем. Этот новый экземпляр перезагружает все ресурсы для данной активности, а если в программе имеются какие-либо данные приложения, которые требуется перезагрузить, то они также будут загружены заново. В итоге получается, что пользователь продолжает работать с якобы «той же самой» активностью, как будто ничего и не произошло. Новый экземпляр выглядит точно как старый, поскольку имеет ровно то же состояние, что и старый.

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

Простейший способ убедиться в том, что все ресурсы, используемые в активности, перезагружены с учетом новой конфигурации, – обязательно сбрасывать старый экземпляр активности и создавать новый, чтобы при этом и перезагружались все ресурсы. Чтобы это произошло, когда приложение работает в эмуляторе, нажмите клавишу 9 на числовой клавиатуре. После этого в эмуляторе изменится ориентация экрана. В регистрационном журнале вы увидите примерно такую же информацию, как на рис. 11.6. В журнале будет показано, что вызван метод onDestroy, поскольку экземпляр Actіvity сбрасывается в рамках процесса изменения конфигурации, а не из-за того, что в системе не хватает памяти и она пытается завершить процесс, чтобы высвободить память. Вы также заметите, что во всех новых экземплярах объекта Actіvity ID (идентификатор) процесса остается одним и тем же – системе не приходится восстанавливать ту память, которую использует приложение.

Рис. 11.6. При вызове метода onDestroy идентификационный номер процесса не изменяется

Такой подход может показаться расточительным: новый экземпляр Activity? Зачем? Почему бы не пользоваться тем, который уже есть? Разве создание нового экземпляра не замедлит работу? Тем не менее в большинстве случаев ресурсы, загружаемые активностью, когда она запускается, составляют основную часть состояния экземпляра Activity. Во многих случаях основной объем вычислений, протекающих в активности, происходит тогда, когда она считывает XML-файл и рассчитывает компоновку. И, как правило, изменения конфигурации – например, ориентации экрана или локали – требуют пересчета практически для всех макетов, загруженных из ресурсов. Итак, изменение конфигурации практически неизбежно приводит к перезапуску активности, а также к затратам процессорного времени, которые требуются для такого перезапуска.

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

Источник: Android. Программирование на Java для нового поколения мобильных устройств

По теме:

  • Комментарии