ARC, стоит это или нет?

Question

Когда я перешел на Objective C (iOS) из C ++ (и немного Java), мне было трудно понять управление памятью в iOS. Но теперь все это кажется естественным, и я знаю, что нужно сохранять, автоматически выпускать, копировать и выпускать вещи. После прочтения о ARC, я задаюсь вопросом, есть ли еще преимущества использования ARC или просто вам не нужно беспокоиться об управлении памятью. Прежде чем перейти в ARC, я хотел знать, как стоит переходить в ARC.

1. XCode имеет меню «Преобразовать в цель C ARC». Является ли преобразование настолько простым (не о чем беспокоиться)?
2. Помогает ли это мне уменьшить объем памяти в моих приложениях, утечки памяти и т. Д. (Как-то?)
3. Оказывает ли это большое влияние на тестирование моих приложений?
4. Каковы неочевидные преимущества?
5. Есть ли недостатки в переходе на него?

Answer 1

Вот мой конкретный взгляд на ARC:

1) В XCode есть меню «Преобразовать в цель C ARC».Является ли преобразование настолько простым (не о чем беспокоиться)?

Это просто.Оно работает.Используй это.Тем не менее, как указывает Кевин Лоу, вам нужно будет пройтись и исправить биты, в которых вы используете объекты Core Foundation.Это только потребует здоровой привязки __bridge или __bridge_transfer, хотя.

2) Поможет ли это мне уменьшить объем памяти моих приложений, утечки памяти и т. Д.(как-то?)

Нет, не совсем.ОК, вроде.Это поможет уменьшить утечки памяти, если вы ранее неправильно кодировали.Это не уменьшит объем используемой памяти.

3) Оказывает ли это большое влияние на тестирование моих приложений?

Нет вообще.

4) Каковы неочевидные преимущества?

Будущее.Еще больше получится от бонуса, который дает компилятор с глубоким знанием того, как объекты считаются ссылками.Например, ARC уже предлагает прекрасную оптимизацию objc_retainAutoreleasedReturnValue, что очень приятно.

5) Есть ли какие-либо недостатки при переходе на нее?

Ничего подобного.

Пожалуйста, поверьте мне на слово и начните использовать ARC.Нет никаких оснований (IMO) не делать этого, поэтому преимущества определенно перевешивают недостатки!

Для более глубокого взгляда на то, как работает ARC, возможно, чтобы убедить вас в том, что это хорошо, пожалуйста, посмотрите на мойсообщения в блоге под названием «Взгляд под капот ARC» - здесь , здесь , здесь & здесь .

Answer 2

Вот что вам действительно нужно знать об ARC:

Компилятор понимает Objective-C и Cocoa лучше, чем вы. Я не считаю это оскорблением; это понимает это лучше меня. Я думаю, вы могли бы с уверенностью сказать, что он понимает правила лучше, чем все, но, может быть, дюжина человек во всем мире. И он знает хитрости, чтобы использовать их до такой степени, что вы и я не можем повторить, даже если мы поняли так же, как и он.

Остальное просто детали:

• Вы будете писать гораздо менее скучный код. Код настолько скучный, что легко ошибиться.
• Как смешанный процесс компиляции и времени выполнения, он имеет доступ к хитростям, которых у вас нет.
  • Написание кода для управления памятью лучше, чем для вас, даже если вы пишете теоретически совершенный код для управления памятью.
  • Это уменьшит использование памяти "прилива" (в некоторой степени) без каких-либо усилий с вашей стороны.
  • При обнулении слабых ссылок намного проще избежать сбоев, вызванных висячими указателями.
• Если вы запускаете новое приложение, перестаньте думать об этом и просто используйте его.
• Если у вас уже есть приложение:
  • Вам нужно будет повторно протестировать его. Вы должны убедиться, что у вас нет циклических ссылок.
  • Если у вас есть приложение, предназначенное для iOS до iOS 5, обнуление слабых ссылок не поддерживается. Вы должны серьезно рассмотреть вопрос о необходимости iOS 5.
  • Если у вас есть приложение, предназначенное для iOS до iOS 4, вы вообще не сможете его использовать. О чем ты думаешь, поддерживая дерьмо такого старого?!?
• В последней версии XCode это не было полностью без ошибок. Это, вероятно, до сих пор нет. Но это все еще стоит использовать.

Answer 3

1. Если вы используете Core Foundation или не-Objective-C код, то это не так просто, как вам придется вручную пройтись по коду и убедиться, что все приведения между Objective-C и Core Foundation выполнены. соединенный мостом (если у вас есть забросы). Вам также все равно придется управлять памятью для кода без Objective-C.

2. Предполагается, что он по существу позаботится обо всех утечках памяти, поскольку он автоматизирует сохранение, освобождение, копирование и т. Д. До сих пор у меня никогда не было утечки Objective-C с момента перехода на ARC.

3. Нет. Сборка может занять немного больше времени, так как она должна пройти через весь ваш код и вставить весь код сохранения и освобождения.

4. Не уверен, что есть. В конце концов, все ARC является автоматом.

5. Вам нужно будет узнать о переходах через мост, а также вы не сможете собрать что-либо ниже iOS 4.

В конце концов, оно того стоит. Сначала я был настроен скептически, но после просмотра видео WWDC, где они объясняют, как оно работает, оно мне нравилось все больше и больше.

Answer 4

Читали ли вы документацию Apple по ARC ? Он отвечает на многие вопросы, которые вы задаете.

Исходя из моего опыта, вот что я думаю:

1. Да, все просто. Тем не менее, вам обязательно нужно протестировать ваше приложение после конвертации.
2. Это может помочь уменьшить использование памяти вашего приложения и утечки, но это не гарантировано.
3. Да. Вы захотите проверить после преобразования в ARC.
4. Вам не нужно тратить столько времени на размышления и отслеживание утечек. Вы можете тратить больше времени и энергии на реальный код вашего приложения, не беспокоясь о сохранении / выпуске. Даже если сохранить / выпустить код естественно и легко для вас, вы не непогрешимы, и вы иногда забудете выпустить что-то. ARC не забывает.
5. Если вы поддерживаете iOS 4, вам придется обрабатывать слабые ссылки, поскольку ARC не поддерживает их в iOS 4.

Answer 5

Я обнаружил: ARC делает ваш код ОЧЕНЬ быстрее. В видео «Яблоки WWDC» говорится, что для каждого метода сохранения и освобождения каждого объекта NSObject сохраняется пара циклов ЦП. Это связано с тем, что больше нет необходимости проверять его во время выполнения (теперь он передается компилятору). Это около 6 циклов процессора для каждого сохранения. Если вы используете цикл, который создает много объектов, то вы действительно почувствуете разницу.

ARC не только делает код быстрее, но вы пишете меньше кода, что значительно ускоряет процесс разработки. И последнее, но не менее важное: вы не должны искать утечки памяти примерно на 90% своего кода. Если вы не используете много низкоуровневых вещей, которые должны использовать «__bridge casts», вы ПОЛНОСТЬЮ исчерпали утечки памяти.

Вывод: если вы можете это сделать, сделайте это!

Answer 6

Посмотрите видео WWDC на ARC: https://developer.apple.com/videos/wwdc/2011/?id=323

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

Answer 7

3) Вы должны повторно протестировать свои приложения, но, по моему опыту, это будет в основном работать.Посмотрите на все предупреждения компилятора очень внимательно !!!

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

5) Недостатки: Единственный недостаток - отключение ARC для некоторых сторонних библиотек.

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