К ARC или не к ARC? Каковы плюсы и минусы?

Ответ 1

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

ОК, теперь я расскажу вам о небольших минусах:

• Если вы давний разработчик ObjC, вы будете подергиваться примерно на неделю, когда увидите код ARC. Вы очень быстро справитесь с этим.

• Есть некоторые (очень) небольшие осложнения при соединении с кодом Core Foundation. Есть несколько больше осложнений при работе со всем, что относится к id как к void*. Такие вещи, как C-массивы id, могут немного подумать о том, чтобы сделать правильно. Необычное обращение с ObjC va_args также может вызвать проблемы. Большинство вещей, связанных с математикой на указателе ObjC, сложнее. В любом случае вы не должны этого многого.

• Вы не можете поместить id в struct. Это довольно редко, но иногда оно используется для сбора данных.

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

• ARC будет утечка памяти во время сбоев исключения ObjC. Исключение ObjC должно быть очень близко к завершению вашей программы. Если вы перехватываете значительное количество исключений ObjC, вы используете их неправильно. Это можно устранить с помощью -fobjc-arc-exceptions, но оно предусматривает штрафные санкции, обсуждаемые ниже:

• ARC не будет утечка памяти во время исключения ObjC или С++ в коде ObjС++, но это связано как с производительностью времени, так и с пространством. Это еще один из длинного списка причин, чтобы свести к минимуму использование ObjС++.

• ARC вообще не работает на iPhoneOS 3 или Mac OS X 10.5 или ранее. (Это исключает возможность использования ARC во многих проектах.)

• __weak указатели не работают корректно на iOS 4 или Mac OS X 10.6, что является позором, но довольно легко работать. __weak указатели велики, но они не являются точкой продажи № 1 ARC.

Для 95% + кода там ARC блестящий, и нет причин вообще его избегать (при условии, что вы можете использовать ограничения версии ОС). Для кода, отличного от ARC, вы можете передать -fno-objc-arc по каждому файлу. К сожалению, Xcode делает это намного сложнее, чем нужно делать на практике. Вероятно, вы должны перенести не-ARC-код в отдельный xcodeproj, чтобы упростить это.

В заключение перейдите в ARC, как только сможете и не оглядитесь назад.

ИЗМЕНИТЬ

Я видел пару комментариев по строкам "использование ARC не заменяет знания правил управления памятью Cocoa". Это в основном верно, но важно понять, почему и почему нет. Во-первых, если весь ваш код использует ARC, и вы нарушаете Three Magic Words повсюду, у вас все равно не будет проблем. Шокировать, чтобы сказать, но там вы идете. ARC может сохранить некоторые вещи, которые вы не имели в виду, чтобы сохранить их, но они также выпустят их, поэтому это никогда не имеет значения. Если бы я преподавал новый класс в Cocoa сегодня, я бы, вероятно, потратил не более пяти минут на фактические правила управления памятью, и я бы, вероятно, упомянул только правила управления именами при обсуждении имен KVC. С ARC я считаю, что вы действительно можете стать достойным начинающим программистом, не изучая правила управления памятью вообще.

Но вы не могли стать достойным программистом. Вы должны знать правила, чтобы правильно сфокусироваться с Core Foundation, и каждый промежуточный программист должен иметь дело с CF в какой-то момент. И вам нужно знать правила для смешанного кода ARC/MRC. И вам нужно знать правила, когда вы начинаете возиться с указателями void* до id (которые вы по-прежнему должны выполнять для KVO правильно). И блоки... ну, управление блочной памятью просто странно.

Итак, я хочу сказать, что основное управление памятью по-прежнему важно, но там, где я обычно тратил значительное время и формулировал правила для новых программистов, ARC становится более продвинутой темой. Я предпочел бы, чтобы новые разработчики думали с точки зрения графиков объектов, а не заполняли их основными вызовами на objc_retain().

Ответ 2

Лучше, больше технических ответов, чем мое, придет:

• ARC!= сбор мусора. Отсутствует штраф за выполнение, это делается во время компиляции.
• ARC также!= просто автоматическое освобождение всего, как вы предлагаете в своем комментарии. Прочитайте документы
• Это потрясающе, как только вы осознаете, сколько ручного управления ссылками вы делали.
• Используйте его!
• Один недостаток - сохранение старого, не дугового кода внезапно становится очень утомительным.

Ответ 3

Сколько выгоды может принести ARC проекту?

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

Сколько сбор мусора действительно "стоит"?

В iOS нет сборки мусора. ARC похож на GC, так как вам не нужно вручную сохранять или отпускать объекты. Это, в отличие от GC, в том, что нет сборщика мусора. Модель сохранения/выпуска по-прежнему применяется, так как компилятор вставляет в ваш код соответствующие вызовы управления памятью во время компиляции.

Используете ли вы ARC, и если да, то как вы его нашли до сих пор?

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

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

Ответ 4

Я думаю, что ARC - отличная идея. По сравнению с GC вы можете получить свой торт и съесть его тоже. Я склонен полагать, что MRC налагает бесценную "дисциплину" на управление памятью, которую каждый может извлечь из этого. Но я также согласен с тем, что реальная проблема, о которой нужно знать, - это Object Ownership and Object Graphs (как многие указали), а не подсчеты на уровне низкого уровня как таковой.

В заключение: ARC НЕ является свободным пропуском для бессмысленной памяти; это инструмент, помогающий людям избежать повторяющихся задач, которые вызывают стресс и подвержены ошибкам, поэтому лучше делегировать машину (в этом случае компилятор).

Тем не менее, я лично являюсь мастером и еще не сделал переход. Я только начал использовать Git...

ОБНОВЛЕНИЕ:. Итак, я перенес всю свою игру, библиотеку gl, и никаких проблем до сих пор (кроме помощника по миграции в Xcode 4.2). Если вы начинаете новый проект, идите на него.

Ответ 5

Я использовал его в нескольких (по общему признанию, небольших) проектах, и у меня есть только хорошие впечатления, как производительность, так и надежность.

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

Ответ 6

Единственный недостаток, с которым я столкнулся, - это использовать библиотеку с множеством функций и данных CoreFoundation. В MRC вам не нужно беспокоиться об использовании CFStringRef вместо NSString*. В ARC вы должны указать, как эти два взаимодействуют (базовый мост? Освобождают объект CoreFoundation и переносят его в ARC?). Создайте объект Cocoa как объект с сохранением +1 CoreFoundation?) Кроме того, в OS X он доступен только на 64-битный код (хотя у меня есть заголовок, который работает вокруг этого...).