Безопасно ли использовать ARC при развертывании на iOS 4.x? - PullRequest
2 голосов
/ 26 января 2012

Мы разрабатываем приложение, которое хотим запустить на iOS 4.3 и выше.

Наш старший разработчик считает, что использование ARC - это плохо, и это вызывает сбои и проблемы во всем, что ниже iOS 5. Это правда?Какие проблемы могут быть при использовании ARC на iOS 4.3?

Я знаю, что вы должны использовать unsafe_unretained вместо слабых ссылок.Какие проблемы это может вызвать?

Если мы вообще не будем использовать ARC, если мы также разрабатываем для iOS 4.3 или возможно ли разработать надежное приложение для iOS 5 и выше и iOS 4.3 с использованием ARC?

Ответы [ 3 ]

6 голосов
/ 26 января 2012

Нет причины , а не , чтобы использовать ARC при развертывании на 4.x. Абсолютно неверно говорить, что ARC вызывает сбои и проблемы на всем, что ниже iOS 5. Это полностью упускает суть и не понимает, что такое ARC, вероятно.

ARC - это "funkiness" времени компиляции. Это то, что я люблю называть так или иначе! Он просто добавляет правильное количество сохранений и выпусков или авто-выпусков, чтобы ваши объекты оставались там так долго, как и должны. Мне нравится думать об этом почти как о превращении объектов в переменные стека. Так что рассмотрите этот код:

- (void)methodA {
    NSNumber *number = [[NSNumber alloc] initWithInt:5];
    [someObject doSomethingWithANumber:number];
}

ARC добавит release из number, когда переменная number выйдет из области видимости. В этом случае он выходит из области видимости, когда возвращается methodA. Итак, рассмотрим этот более сложный фрагмент кода:

- (void)methodB {
    NSNumber *number = [[NSNumber alloc] initWithInt:5];
    if (<some_expression>) {
        return;
    }
    [someObject doSomethingWithANumber:number];
}

В этом случае без ARC нам пришлось бы делать 2 [number release] вызовов. Один раз до преждевременного возвращения и один раз в конце метода. Между прочим, это, кстати, надуманный пример - просто чтобы показать идею. С ARC нам не нужно вводить эти 2 звонка, это делает это за нас. Я думаю, вы можете увидеть силу ARC здесь, потому что в этом сценарии, если ваш метод стал немного больше и сложнее, вы могли бы очень легко забыть освободить вещи до преждевременного возврата из метода.

Вернемся к вопросу о 4.x ... Вы правы, что не можете использовать weak ссылки. Это потому, что это единственная часть ARC, которая требует помощи от среды выполнения, и это не часть среды выполнения, поставляемой с 4.x. Среда выполнения автоматически удалит слабые ссылки, когда объект, на который он указывает, исчезнет. Таким образом, если у вас есть ObjectA со слабой ссылкой на ObjectB (например, шаблон делегата), то если ObjectB исчезнет из-за того, что он больше не используется, то ссылка ObjectA будет исключена. Это только служит защитной сеткой на мой взгляд. Вы должны кодировать так, чтобы этот сценарий никогда не происходил в любом случае. Так было с тех пор, как появились слабые ссылки, и вам просто нужно кодировать так, чтобы не допустить, чтобы это стало проблемой - то, чем мы все занимаемся уже много лет.

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

Вкратце: ИСПОЛЬЗОВАТЬ ARC.

0 голосов
/ 30 января 2012

Я полностью согласен, они идентичны использованию assign в iOS4, однако предположить, что они больше не вызывают сбои, в этом случае не продумано до конца. Кто пишет код, чтобы он вылетал? Ни один. Никто. Приложения по-прежнему аварийно завершают работу, несмотря на это намерение? Конечно. По всему спектру виновных вырисовывается управление памятью и смысл ARC. Интересно, что наименьшая осторожность для разработчиков iOS заключается в назначении - и здесь кроется опасность. Как часто вы видели код, в котором делегаты и источники данных не обнулялись в dealloc? Нет надежды на то, что уровень осторожности при работе с ними в ARC будет расти, поскольку мы наслаждаемся нашим более чистым кодом, не задумываясь об опасностях висящих указателей. Этот риск в iOS4 не очевиден и может быть очень трудно отследить.

ARC - путь вперед, однако у тех, кто поддерживает приложения в iOS4, есть веские причины для принятия взвешенного подхода.

0 голосов
/ 26 января 2012

Это неверно. В iOS4 среда выполнения не будет автоматически обнулять слабые ссылки, вы можете использовать только __unsafe_unretained (не обнуление), а не __weak (обнуление), что может привести к сбоям. Некоторое полезное справочное чтение здесь:

http://mikeash.com/pyblog/friday-qa-2010-07-16-zeroing-weak-references-in-objective-c.html

http://www.mikeash.com/pyblog/friday-qa-2011-09-30-automatic-reference-counting.html

...