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

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

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

  • Ручная модальная секция не работает, View Controller не находится в иерархии окон?
  • Почему я получаю эту ошибку при сохранении Twitter ACAccount?
  • Прочтите настройки iPhone программно (точно настройки-> Общие-> Дата и время-> Установить автоматически)
  • pushViewController не работает в iOS 5, но отлично работает в iOS6
  • Почему UITextview не имеет свойства заполнителя, такого как UITextField
  • Общий экземпляр NSHTTPCookieStorage не сохраняется.
  • XCode 4.4 iOS 5.1 Проблемы с симулятором
  • Adobe AIR и iPhone - как это работает?
  • 7 Solutions collect form web for “ARC, стоит того или нет?”

    Вот мой конкретный подход к ARC:

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

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

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

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

    3) Значительно ли это влияет на мои приложения?

    Никак нет.

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

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

    5) Любое Недостаток os движется к нему?

    Никак нет.

    Пожалуйста, возьми мое слово и начни использовать АРК. Нет причин (IMO) не делать этого, поэтому преимущества, безусловно, из-за недостатков!

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

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

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

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

    • Вы напишете гораздо менее скучный код. Код настолько скучный, что легко ошибаться.
    • Как смешанное время компиляции и время выполнения, у него есть доступ к трюкам, которых у вас нет.
      • Лучше работать над написанием кода управления памятью, чем вы можете, даже если вы напишете теоретический идеальный код управления памятью.
      • Это уменьшит использование памяти «прилив» (несколько) без каких-либо усилий с вашей стороны.
      • При обнулении слабых ссылок намного легче избежать сбоев, вызванных оборванными указателями.
    • Если вы начинаете новое приложение, перестань думать об этом и просто используйте его.
    • Если у вас есть существующее приложение:
      • Вам нужно будет перепроверить его. Вы должны убедиться, что у вас нет круглых ссылок.
      • Если у вас есть существующее приложение, предназначенное для iOS до iOS 5, обнуление слабых ссылок не поддерживается. Вы должны серьезно подумать о необходимости использования iOS 5.
      • Если у вас есть существующее приложение, которое предназначено для iOS перед iOS 4, вы не можете использовать его вообще. Что ты думаешь, поддерживая дерьмо, что старый?!?
    • В последней версии Xcode это не было полностью ошибкой. Вероятно, это еще не так. Но это все равно стоит использовать.
    1. Если вы используете Core Foundation или не-Objective-C-код, то это не так просто, как вам придется вручную пройти через ваш код и убедиться, что все трансляции между Objective-C и Core Foundation мосты (если у вас есть бросает). Вы также должны будете управлять памятью для кода, отличного от Objective-C.

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

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

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

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

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

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

    Основываясь на моем опыте, вот что я думаю:

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

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

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

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

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

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

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

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

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

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

    PhoneC: Разработка iOS проста с помощью XCode, Swift3, UITableView, cocatouch, давайте создадим приложения для iPhone, iPad и Macbook.