Каковы преимущества и недостатки использования ARC?

Ответ 1

Каковы преимущества и недостатки использования нового стиля управления памятью автоматического подсчета (ARC) в проекте iOS?

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

Если вы уже знаете, как реализовать приложения OS X или iOS с использованием ручного подсчета ссылок (MRC), ARC не добавляет функциональности - это просто позволяет вам удалить операции подсчета ссылок из ваших источников.

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

Я не оценил это, но, возможно, стоит упомянуть, что для компиляции источников ARC потребуется больше времени и ресурсов.

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

Можете ли вы не использовать ARC при разработке с iOS 5.0 SDK?

Да, используя CLANG_ENABLE_OBJC_ARC. ARC совместим с двоичными файлами, и все, что действительно происходит, заключается в том, что компилятор делает все возможное, чтобы автоматически вводить соответствующие операции подсчета ссылок для вас на основе объявлений, видимых для текущего перевода (см. Мой ответьте здесь, почему важна трансляционная видимость). Поэтому вы также можете включить и отключить его для некоторых источников в проекте и включить его для других.

Смешанный режим (некоторые MRC и некоторые источники ARC), однако, довольно сложный и тонко, особенно для реализаций, которые могут быть дублированы компилятором (например, тело встроенной функции может быть неверным). Такие проблемы с смешанным режимом будут очень трудно изолировать. Программы и источники ObjС++ будут особенно сложными в этом отношении. Кроме того, поведение может отличаться в зависимости от настроек оптимизации (как один пример); программа, которая отлично работает в сборке отладки, может ввести утечку или зомби в выпуске.

Вы рекомендуете ARC или ручной подсчет ссылок (MRC) для нового проекта?

Лично я буду придерживаться MRC в течение некоторого времени. Даже если ARC был протестирован в реальном мире, вероятно, останется ряд проблем, которые появятся в сложных сценариях, которые вы захотите избежать, чтобы первыми узнать и отладить. OS X Garbage Collection - пример того, почему вы можете подождать. В качестве одного из примеров коммутатор может измениться при уничтожении объектов - ваши объекты могут быть уничтожены раньше и никогда не будут помещены в пулы автозапуска. Он также может изменить порядок выпуска иваров, который может иметь некоторые побочные эффекты.

У меня также есть большая база кода, в которой я не хочу терять неделю тестирование этой функции в настоящее время. Наконец, для меня важна обратная совместимость.

Будет ли приложение, использующее ARC, работать в более старых версиях ОС, чем iOS 5.0?

Если вы работаете с MRC, он будет обратно совместим. Если вы работаете с ARC, это не обязательно будет совместимо. Фактически, он может даже не компилироваться без небольшой дополнительной работы. Требования к среде исполнения доступны в некоторых более ранних версиях. См. также этот вопрос. Если вам нужна обратная совместимость, ARC не будет вариантом для некоторых версий ОС.

Наконец, если бы вы ограничили выбор GC или ARC, я бы рекомендовал ARC.

Ответ 2

вы отключите/включите его с помощью CLANG_ENABLE_OBJC_ARC = NO Преимущество заключается в том, что вам приходится меньше писать код и управлять памятью. Недостатком является то, что вам нужно поцарапать все, что вы узнали об управлении памятью. Я предпочитаю отключить его.

Ответ 3

Вы можете включить ARC через "Edit- > Refactor- > Convert to Objective C Arc", это полностью реорганизует ваш код (избавиться от всех вызовов управления памятью и т.д.). Нет обратной операции, поэтому убедитесь, что у вас есть вещи под контролем источника, если у вас есть мысли. В этом сообщении показано, как отключить его для определенных файлов. Я не думаю, что есть слишком много аргументов в пользу того, чтобы не обращать на него внимания, кроме того, что ему больно видеть, что все это усилие, поставленное в правильное управление памятью, идет вниз, и что нам придется прекратить прыгать к потолку каждый раз, когда мы видим init, new, копируем без соответствующего релиза /autorelease (и это немного привыкает). Возможно, можно утверждать, что в некоторых случаях ручное управление памятью приводит к действительно заметным улучшениям производительности и памяти, поэтому мне также было бы интересно.

Ответ 4

Я использую Lion и xcode 4.3. У меня была та же проблема.

Чтобы исправить это, я переключил "Настройки сборки → Objective-C Автоматическая ссылка" на "Нет".

Чтобы убедиться, что он установлен в "Да", мне также нужно было включить параметры "Все" и "Уровни" на панели инструментов, которая находится чуть ниже панели инструментов "Настройки сборки".

Как только эти параметры были включены, я мог видеть, что у моего проекта была опция, установленная на "Да". Мне потребовалось некоторое время, чтобы понять, что значение по умолчанию было "Нет", что отображалось до тех пор, пока я не включил опцию "Уровни".