Я неправильно выразился. Он не может быть уничтожен, он может быть «забыт» системой.
Я поясню на примере:
Представьте, что ваше приложение состоит из двух Activity: ListActivity и DetailsActivity.
Когда пользователь запускает приложение, он попадает на ListActivtiy. Когда он выбирает элемент в ListActivity, открывается DetailsActivity.
Пользователь запускает приложение и система автоматически создает экземпляр класса ListActivity; назовем его объект 1. Вы сохраняете ссылку на этот объект в статической переменной. После этого пользователь переходит на экран DetailsActivity. В этот момент система создает экземпляр класса DetailsActivity; назовем его объект 2. После некоторого времени пользователь нажимает кнопку back и возвращается на экран ListActivity. Вот тут и начинаются проблемы.
В любой момент между тем, как пользователь ушел с экрана ListActivity и вернулся к нему обратно, система может «забыть» про объект 1. Это не значит, что объект будет обязательно уничтожен сборщиком мусора (вы же держите на него ссылку). Это значит, что в момент, когда пользователь вернется на экран ListActivity вместо того, чтобы использовать старый объект 1, система создаст новый экземпляр класса ListActivity, объект 3. У вас в системе будет одновременно два экземпляра класса ListActivity: объект 1, хранящийся в вашей статической переменной и объект 3, отображаемый пользователю.
Про объект 1 будете знать только вы — он уже никогда не будет показан пользователю. Вы можете изменять его поля, вызывать его методы, но визуально это не будет приводить ни к чему — ведь пользователь видит на экране объект 3, а не объект 1.
Вы можете легко добиться описанного эффекта с двумя экземплярами ListActivity включив опцию Settings>Developer options>Don't keep activities.
Поэтому ваше утверждение о том, что
Собственно, ссылки на GUI элементы и держат, когда нужно чтобы их не убило, и не надо было заново создавать и грузить экран при каждом переключении.
в корне неверно относительно Activity (с fragments или views так получится — их созданием управляете вы сами, а не система).
На данный момент плагинов для Android Studio, решающих эту задачу, нет.
Поставьте MAT как отдельную программу и воспользуйтесь инструкцией со stackoverflow.
Либо поставьте Eclipse с ADT и MAT и воспользуйтесь им. Вам даже проект импортировать в eclipse не потребуется.
Вам вообще ничего не может гарантировать их отсутствие, как и это статья. Так стоит ли об этом говорить вообще?
Жизнь вообще бессмысленная штука :)
Но вы правы — ничто не может гарантировать отсутствие ошибок. Даже если вы прекрасно понимаете всю теорию, вы все равно будете иногда делать опечатки или просто забывать про какие-то моменты.
Именно поэтому я рекомендую перед релизом приложения один раз пройтись по всему приложению и отловить все такие ошибки с помощью алгоритма, приведенного в конце статьи. Это занимает достаточно много времени, но это полезная практика. А теория — она больше для того, чтобы понимать что нужно искать.
Я поясню на примере:
Представьте, что ваше приложение состоит из двух Activity: ListActivity и DetailsActivity.
Когда пользователь запускает приложение, он попадает на ListActivtiy. Когда он выбирает элемент в ListActivity, открывается DetailsActivity.
Пользователь запускает приложение и система автоматически создает экземпляр класса ListActivity; назовем его объект 1. Вы сохраняете ссылку на этот объект в статической переменной. После этого пользователь переходит на экран DetailsActivity. В этот момент система создает экземпляр класса DetailsActivity; назовем его объект 2. После некоторого времени пользователь нажимает кнопку back и возвращается на экран ListActivity. Вот тут и начинаются проблемы.
В любой момент между тем, как пользователь ушел с экрана ListActivity и вернулся к нему обратно, система может «забыть» про объект 1. Это не значит, что объект будет обязательно уничтожен сборщиком мусора (вы же держите на него ссылку). Это значит, что в момент, когда пользователь вернется на экран ListActivity вместо того, чтобы использовать старый объект 1, система создаст новый экземпляр класса ListActivity, объект 3. У вас в системе будет одновременно два экземпляра класса ListActivity: объект 1, хранящийся в вашей статической переменной и объект 3, отображаемый пользователю.
Про объект 1 будете знать только вы — он уже никогда не будет показан пользователю. Вы можете изменять его поля, вызывать его методы, но визуально это не будет приводить ни к чему — ведь пользователь видит на экране объект 3, а не объект 1.
Вы можете легко добиться описанного эффекта с двумя экземплярами ListActivity включив опцию Settings>Developer options>Don't keep activities.
Поэтому ваше утверждение о том, что
в корне неверно относительно Activity (с fragments или views так получится — их созданием управляете вы сами, а не система).
Поставьте MAT как отдельную программу и воспользуйтесь инструкцией со stackoverflow.
Либо поставьте Eclipse с ADT и MAT и воспользуйтесь им. Вам даже проект импортировать в eclipse не потребуется.
Жизнь вообще бессмысленная штука :)
Но вы правы — ничто не может гарантировать отсутствие ошибок. Даже если вы прекрасно понимаете всю теорию, вы все равно будете иногда делать опечатки или просто забывать про какие-то моменты.
Именно поэтому я рекомендую перед релизом приложения один раз пройтись по всему приложению и отловить все такие ошибки с помощью алгоритма, приведенного в конце статьи. Это занимает достаточно много времени, но это полезная практика. А теория — она больше для того, чтобы понимать что нужно искать.
В начале статьи я написал про это, но, возможно, недостаточно четко.