Объекты CF против объектов NS

Между прочим, часть Core Foundation имеет открытый исходный код. Вы можете найти его часть с открытым исходным кодом для Mac OS X 10.10.5 здесь: https://opensource.apple.com/source/CF/CF-1153.18/. Я нашел исходный код CFRunLoop и CFStream очень информативным.

Core Foundation — это C API для множества общих структур данных. У большинства этих структур данных есть эквиваленты в Cocoa, но не у всех. Большинство из эквивалентных являются бесплатными мостами, что позволяет использовать их взаимозаменяемо, но не все из них.

Бесплатный мост - это очень хитрый прием. Если вам нужны подробности, см. запись ridiculous_fish, на которую указывает @Matt Wilding. Это наиболее авторитетный источник информации по этому вопросу (и он оказал большое влияние на главу 19 iOS:PTL, в которой также объясняется, как все это работает). Но это не имеет большого значения для большинства целей. Как отмечает Мэтт, обычно можно представить, что NSArray — это то же самое, что CFArrayRef. Во многих случаях это не совсем так, но иногда это так, и в большинстве случаев достаточно близко. Это то же самое, что сказать, что @"stuff" совпадает с NSString, содержащим stuff. В основном это правда, но не совсем так.

Когда OS 9 перешла на OS X, было очень удобно предоставлять C доступ к структурам данных, подобным Objective-C. Сегодня многие низкоуровневые фреймворки предоставляют C API из соображений производительности. Вы не должны думать о CF как о «устаревшем» или «внутреннем». Вы должны думать об этом как о низкоуровневом, и вы должны использовать его только тогда, когда вам нужна мощность, которую он предоставляет, или вы имеете дело с низкоуровневой структурой, которая требует этого.

Объекты CF часто более гибкие, чем их аналоги NS. Например, CFDictionaryRef может содержать необъектные ключи и значения, а NSDictionary — нет. (Конечно, они соединяются бесплатно, так что вы можете создать CFDictionaryRef без удержания, а затем рассматривать его как NSDictionary. Хитрость....)

По мере того как Apple выпускает новые платформы, вы заметите, что они часто сначала раскрывают API-интерфейсы C, а затем добавляют API-интерфейсы Objective-C. Это причина, по которой полезно изучить Core Foundation, даже если вы не используете его каждый день. Но когда это возможно, вы обычно должны использовать ObjC.

У этого вопроса есть история. Core Foundation — это мозг операции. Он написан в основном на C. Он был создан с приобретением Apple NEXT и их API и многим им обязан. Классы NS* часто представляют собой просто абстрактные интерфейсы Objective C, построенные поверх типов CF*. Итак, когда вы спрашиваете, почему существуют и CFArray, и NSArray, ответ заключается в том, что на самом деле их нет. NSArrays являются CFArrays, NSStrings являются CFStrings и т. д. Вот почему возможно бесплатное соединение.

Для более интересного и подробного чтения я бы отослал вас к этой записи в блоге.

CF означает CoreFoundation. Открытые объекты с CF в именах являются обычными объектами Core Foundation, написанными на C. Все объекты связаны бесплатным мостом со своими друзьями Cocoa Touch Foundation в стране Objective-C. Обычно это непрозрачные указатели.

NS означает NextStep, старую ОС, на которой была построена Mac OS X. Объекты с префиксом NS обычно полностью написаны на Objective-C или C или даже на C++.

Это действительно зависит от того, что вам нужно, чтобы каждый объект делал. Мне, конечно, проще работать на чистом Objective-C с NSString, чем на смеси C и Objective-C с CFString, но есть некоторые вещи, которые объекты CF могут делать, а объекты NS просто не могут. t (в основном вещи очень низкого уровня). Объекты CF также гораздо больше балуются ссылками, мутациями и проверками, чем их аналоги NS.

(Для справки в будущем существует еще несколько префиксов: CG для CoreGraphics, UI для UIKit, QL для QuickLook, AV для AVFoundation, MP для MediaPlayer, MF для MessageFoundation, GL для GLKit и MK для MapKit) (если я пропустил, с удовольствием отредактирую).