2012-01-26 2 views
2

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

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

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

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

+2

Не может отвечать лучше, чем Роб. См. Принятый ответ в этом разделе: http: //stackoverflow.com/questions/8760431/ios-to-arc-or-not-to-arc-pros-and-cons – Vin

+1

user1038017, ARC улучшает структуру распределения большинства приложений , Он часто уменьшает отметку «высокая вода» в распределении памяти. Это очень хорошо на машинах, таких как iPhone 3G, которые застревают в iOS v4.2.1. Поскольку 'unsafe_unretained' имеет ту же самую семантику, что и политика распределения назначений для приложения MRR, вы не меняете ничего, что вам уже нужно было управлять. ARC не делает ваше приложение неустойчивым. Нестабильность всегда была там. ARC особо не раскрывает его. Andrew – adonoho

ответ

6

Нет причины не использовать 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]; 
} 

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

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

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

Вкратце: USE ARC.

-1

Это неверно.В iOS4 время выполнения не будет автоматически равным нулю слабых ссылок, вы можете использовать только __unsafe_unretained (non-zeroing), а не __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

+1

Это может привести только к сбоям, если вы код, чтобы это могло произойти. Мы все это время кодировали. Я не понимаю, почему люди думают, что внезапно с ARC это означает, что ваши приложения * будут разбиваться только потому, что слабые ссылки не будут автоматически заполнены. – mattjgalloway

+0

Мэтт прав, небезопасные объекты не более опасны, чем назначенные указатели, которые мы использовали все время. Просто новые слабые ссылки добавляют уровень безопасности, которого у нас раньше не было. Вы не открыты для каких-либо сбоев, используя небезопасные переменные, чем при ручном управлении памятью, поэтому их нельзя использовать в качестве причины для предотвращения целей ARC для целей развертывания 4.x. –

0

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

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