Должен ли я использовать сборку мусора Objective-C при записи для 10.5+?

Question

При написании довольно типичного кода Mac в среде OS X 10.5+, каковы недостатки использования сборки мусора?

Пока что все остальное, что я написал, было либо 10.4-совместимым, либо на iPhone, так что мне стало довольно удобно с сохранением / выпуском, но теперь, когда я работаю над более крупным проектом, только 10.5 Интересно, есть ли какие-то недостатки в том, чтобы просто идти вперед и использовать сборщик мусора Objective-C 2.0.

Что вы, ребята, думаете?

Answer 1

Если вы пишете новый код Какао и нацелены на Mac OS X 10.5, используйте сборку мусора Objective-C.

Если вы пишете какой-то код, который также может потребоваться для запуска на iPhone, вы можете написать и протестировать этот код для обеих моделей очень просто, сохранив этот код в отдельной инфраструктуре, написав его со свойством -retain и -release и установите для своей платформы и целевого объекта тестирования для нее значение с поддержкой GC вместо только для GC .

Xcode запустит ваш пакет модульных тестов дважды, один раз с включенным GC и один раз с выключенным GC, и ваш фреймворк будет использоваться в обеих моделях исполнения. Затем, если вы в конечном итоге захотите перенести этот код уровня модели на iPhone, вы можете поместить его в статическую библиотеку, предназначенную для iPhone, или включить ее непосредственно в проект iPhone.

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

Answer 2

Я предпочитаю заниматься управлением памятью сам, просто потому что мне нравится иметь этот уровень контроля. Я знаю из опыта других языков (C #), что GC не позволяет вам полностью игнорировать проблемы с памятью, и то же самое в Какао с такими вещами, как слабые ссылки и обратные вызовы, использующие (void *), где объект явно не принадлежит другим объектом. Вы в основном меняете один набор проблем (утечки памяти) на другой. Лично я не склонен делать слишком много ошибок управления памятью в наши дни, и те, которые я делаю, довольно легко отследить.

В некоторых ситуациях (например, при реализации методов источника данных для NSOutlineView, когда вы не хотите сохранять объект, представляемый в виде структуры), где я думал, что GC будет действительно полезен, но у меня нет ' с ним пока не проводилось никаких реальных испытаний.

Apple перечисляет некоторые другие преимущества и недостатки в руководстве по программированию GC .

Answer 3

Если есть возможность портировать ваше приложение на iPhone, вы не должны его использовать.

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

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

Answer 4

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

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