didReceiveMemoryWarning and viewDidUnload

Question

Из Руководства по программированию Apple View View/Управление памятью эффективно;

didReceiveMemoryWarning

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

viewDidUnload

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

http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/BasicViewControllers/BasicViewControllers.html

1. Для didReceiveMemoryWarning, мы рекомендуем освободить непринципиальные структуры данных. Итак, что критично, а что некритично?

2. Кроме того, в нем говорится о выпуске того, что мы еще не выпустили в viewDidUnload. Но когда появляется предупреждение о сохранении памяти, вызываемая reReceiveMemoryWarning и просмотр может быть выгружен, тогда вызывается viewDidUnload. Итак, речь идет о перемещении этих кодов в метод прежнего события (didReceiveMemoryWarning) или я что-то пропустил о порядке событий?

3. Для просмотраDidUnload рекомендуется позаботиться о легко, воссоздавая данные при перезагрузке. Итак, если представление используется и не может быть выгружено, почему мы будем отнимать трудоемкие данные в didReceiveMemoryWarning? После того, как эти данные будут выпущены, когда пользователь попытается что-то сделать в текущем представлении, потребуется также много времени для их загрузки.

Answer 1

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

Re (1): Критический и некритический - это ваш призыв. Только вы можете действительно определить, какие данные вы держите, что считаете критическими. Хотя это, вероятно, будет тесно связано с вашим (3), то есть что-то, что легко воссоздано, вероятно, не слишком критично.

Re (2): Я не думаю, что это утверждение относится к порядку вызовов. Как вы поняли, в целом viewDidUnload будет вызван после didReceiveMemoryWarning (поскольку didReceiveMemoryWarning может вызывать viewDidUnload). Например, в viewDidUnload будут выпущены ссылки на элементы пользовательского интерфейса из наконечника. Поэтому не выпускайте их также в didReceiveMemoryWarning.

Re (3): Если вид используется и, следовательно, не может быть выгружен, то да, очевидно, не обязательно иметь смысл его выпускать в didReceiveMemoryWarning. Тем не менее, на самом деле у вас могут быть экземпляры, в которых нельзя было выгрузить представление, но, как известно, оно не будет видимым (не очень нормальным), и в этом случае имеет смысл разгрузить его данные и воссоздать его, когда вид будет виден еще раз ,

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

Мой личный подход к этим методам, как правило, это:

• viewDidUnload - Освободить все ссылки на элементы пользовательского интерфейса, загруженных из кончика пера. Отпустите все элементы пользовательского интерфейса, которые я создал сам в viewDidLoad.
• didReceiveMemoryWarning - освободить любые данные, которые используются при представлении пользовательского интерфейса, которые я могу восстановить, если/viewDidLoad вызывается снова (или какое-либо другое конкретное событие). НЕ выпускайте ничего, что невозможно воссоздать.

Answer 2

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

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