Как продолжительность жизни (неатомного, сильного) свойства работает в iOS?

Скажем, у меня есть свойство, объявленное как @property (nonatomic, strong) NSArray *menuArr; ИЛИ @property (strong) NSArray *menuArr;, и установите это свойство в viewDidLoad. Как долго устройство будет «помнить» информацию, которую я храню в массиве?

Свойство объявляется и устанавливается в viewController, который встроен в navigationViewController, который сам является первым контроллером представления в TabBarViewController. Другими словами, это первое представление, которое видит пользователь, после чего он может перейти от него и обратно.

Не вдаваясь в дискуссию об атомном и неатомном, мой вопрос:

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


Чтобы это не превратилось в "проблему x y", я спрашиваю:

Я работаю над приложением, которое включает в себя меню, разбитое на несколько категорий с несколькими элементами в каждой категории ... как и следовало ожидать от меню. Все пункты меню хранятся на parse.com. Сначала я делал отдельный PFQuery на каждой странице, один на странице категорий, чтобы получить категории, когда пользователь выбирает категорию, нажимается новая страница, а второй PFQuery получает все элементы в выбранной категории. Это сработало, но страницы загружались довольно долго, вероятно, иногда 10-15 секунд без каких-либо реальных указаний на то, что приложение просто не зависло.

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

//get e reference to the first view controller, the one that has the menu array 
FirstViewController *myVC1ref = (FirstViewController *)[[[self.navigationController.tabBarController.viewControllers objectAtIndex:0] viewControllers]  objectAtIndex:0];

//set thisviewController's `menuArr` property to point to the menuArr on the first viewController.

_menuArr=myVC1ref.menuArr;

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

Этот метод занимает около 10-15 секунд для загрузки и сортировки массива один раз, но тогда навигация между страницами происходит мгновенно после этого, что намного лучше.

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

Пока что в моем тестировании приложение, кажется, прекрасно запоминает информацию в массиве в течение дня при обычном несвязанном использовании телефона, но должны быть некоторые ограничения для этого, верно?


person Wesley Smith    schedule 01.06.2014    source источник
comment
В наши дни почти нет причин использовать слово «неатомный». Я бы почти забыл об этом. Что было «неатомным»? В iOS свойства (конечно) полностью безопасны для использования при многопоточном программировании. В древней истории были некоторые неясные ситуации, когда опытные программисты хотели сказать: в этом случае НЕ ДОЛЖНА делать это безопасным для многопоточного программирования. Обратите внимание, что лучшим словом для неатомного 'было бы что-то вроде' небезопасный ',' небезопасный для потоков ' или расширенный-no-thread-proptection'. Сегодня он буквально бесполезен в нормальной работе. Так что забудь об этом.   -  person Fattie    schedule 01.06.2014
comment
Очень важно понимать, что из-за копирования и вставки вы получаете буквально тысячи примеров фрагментов кода в Интернете, которые все еще включают «неатомические». Это - очень просто - совершенно неправильно. Просто невероятно, что вы захотите использовать потокобезопасный режим. (В горстке совершенно непонятных, скажем, ситуаций научного программирования, в этом могут нуждаться высокоразвитые инженеры (хотя на мобильных устройствах это невероятно маловероятно). В любом нормальном приложении это просто совершенно неправильно. Если только вы не хотите, чтобы приложение вылетало из строя каждый раз, когда он тред.)   -  person Fattie    schedule 01.06.2014
comment
@JoeBlow Достаточно справедливо. Похоже, я должен использовать атомарное значение по умолчанию. Можете ли вы дать какое-нибудь представление о том, как работает продолжительность жизни?   -  person Wesley Smith    schedule 01.06.2014
comment
Я не голосовал против этого вопроса, и кажется глупым, что кто-то проголосует против него - в последнее время наблюдается волна голосов против. Да, просто никогда не используйте неатомные, это древняя история, и не утруждайтесь набирать «атомарный», как все. Что касается сильного использования strong каждый раз для класса (например, UIButton, NSString, вашего собственного класса или любого другого класса). В редких случаях, когда у вас есть базовый тип (например, логический, целочисленный и т. Д.), Используйте assign. Вот и все. (На самом деле сейчас совершенно бессмысленно, что яблоко заставляет вас вводить эти два, поскольку они в основном высечены в камне. Class - strong, bool / int / etc - assign).   -  person Fattie    schedule 01.06.2014
comment
относительно того, почему. Я не могу утруждать себя объяснениями, чувак :) Я бы не стал беспокоиться об этом :) Кто-то другой может объяснить.   -  person Fattie    schedule 01.06.2014
comment
и сортировка занимает нулевое время для сортировки (буквально несколько миллионных долей секунды), единственное, что вы видите, - это время работы в сети.   -  person Fattie    schedule 01.06.2014
comment
Что, черт возьми, вы спрашиваете? Будут ли ваши данные исчезать во время работы вашего приложения? Как такое могло случиться и что-нибудь еще функционировало?   -  person jscs    schedule 01.06.2014
comment
Это сработало, но страницы загружались довольно долго, чувак, ты доволен удивительной системой кеширования Parse? это один из самых удивительных трюков парсинга. Вам нужно использовать это здесь, вы будете поражены. Между прочим, вы были совершенно правы, следуя своему сердцу, выполняя все запросы заранее, а затем используя его при необходимости.   -  person Fattie    schedule 01.06.2014
comment
@JoshCaswell Я спрашиваю, есть ли какие-либо ограничения на то, как долго приложение будет обрабатывать данные, хранящиеся в свойстве. Я вижу, что он, похоже, сохраняет информацию о свойствах в течение дня, но будет ли информация там через неделю, если приложение тем временем не будет открыто? Будут ли предупреждения о нехватке памяти в другом месте в другом приложении, возможно, информация будет отброшена. Я не смог найти никакой информации по этому поводу.   -  person Wesley Smith    schedule 01.06.2014
comment
@JoeBlow, это ужасный совет. Неатомные - это не древняя история, и они должны быть предпочтительным типом собственности. См. stackoverflow.com/questions/588866/ для обсуждения.   -  person jrturton    schedule 01.06.2014
comment
lol @Josh - где твое чувство открытия, чувак? :) УДИВИТЕЛЬНО, что, как ни странно, iPhone все запоминает !!   -  person Fattie    schedule 01.06.2014
comment
Привет @jrturton ... Я всегда готов выслушать ВСЕ, ты молодец; не могли бы вы сказать мне, какой ответ вы там думаете? (Пожалуйста, сделайте ссылку для общего доступа внизу ответов.) Ответы, которые я вижу там (возможно, я пропустил один), невероятно устарели и (сегодня) по существу неверны. {Я имею в виду, вы бы не сказали, что не используйте NSString! это медленно! используйте сырую память! вот как выделить память .. .. верно?}   -  person Fattie    schedule 01.06.2014
comment
Например, @jrturton, обратите внимание на ответ Дураяма, который совершенно неверен. (Я добавил комментарий внизу.) (Другие ответы, полученные много лет назад, имеют только историческую ценность.)   -  person Fattie    schedule 01.06.2014
comment
Ух ты, действительно ... жаль ... что два инженера проголосовали за комментарий о неатомных! Мы никогда и никогда не работали над какой-либо базой кода, где неатомарность была бы приемлемой, от самых больших до самых маленьких доткомов. (Все просто скажут, почему?)   -  person Fattie    schedule 01.06.2014
comment
Старый не значит устаревший.   -  person jrturton    schedule 01.06.2014
comment
Я плохо признаю достоинства или атомное против неатомного, неатомное против атомного, или солнце против луны, если бы кто-то мог объяснить, живет ли свойство (объявленное в любом случае) бесконечно в среде iOS или его продолжительность жизни ограничена такими факторами, как время, использование памяти в другом месте, выключение устройства и т. д.   -  person Wesley Smith    schedule 01.06.2014
comment
старый не значит устаревший? хорошо, придерживаясь решаемой проблемы: Неатомный должен быть предпочтительным типом свойства, что совершенно неверно. 100% неверно. С таким же успехом можно сказать, что отказ от использования ARC является предпочтительным подходом к разработке для iOS. совершенно неправильно. относительно этого ответа stackoverflow.com/a/17571453/294884 я добавил поясняющий комментарий внизу.   -  person Fattie    schedule 01.06.2014
comment
Извините но нет. Вы говорите глупости.   -  person jrturton    schedule 01.06.2014


Ответы (1)


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

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

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

person jscs    schedule 01.06.2014
comment
Большое Вам спасибо. Это именно то, чего я ожидал, я просто не мог найти нигде, чтобы это было на самом деле заявлено. - person Wesley Smith; 01.06.2014