Core Foundation框架 (CoreFoundation.framework) 是一組C語言接口范舀，它們?yōu)閕OS應(yīng)用程序提供基本數(shù)據(jù)管理和服務(wù)功能肘迎。下面列舉該框架支持進(jìn)行管理的數(shù)據(jù)以及可提供的服務(wù)：
群體數(shù)據(jù)類型 (數(shù)組艺智、集合等)
程序包
字符串管理
日期和時(shí)間管理
原始數(shù)據(jù)塊管理
偏好管理
URL及數(shù)據(jù)流操作
線程和RunLoop
端口和soket通訊
Core Foundation框架和Foundation框架緊密相關(guān)父叙，它們?yōu)橄嗤δ芴峁┙涌卺愕妫獸oundation框架提供Objective-C接口饺汹。如果您將Foundation對(duì)象和Core Foundation類型摻雜使用蛔添，則可利用兩個(gè)框架之間的 “toll-free bridging”。所謂的Toll-free bridging是說您可以在某個(gè)框架的方法或函數(shù)同時(shí)使用Core Foundatio和Foundation 框架中的某些類型。很多數(shù)據(jù)類型支持這一特性迎瞧，其中包括群體和字符串?dāng)?shù)據(jù)類型夸溶。每個(gè)框架的類和類型描述都會(huì)對(duì)某個(gè)對(duì)象是否為 toll-free bridged，應(yīng)和什么對(duì)象橋接進(jìn)行說明凶硅。
如需進(jìn)一步信息缝裁，請(qǐng)閱讀Core Foundation 框架參考。
Objective-C指針與CoreFoundation指針之間的轉(zhuǎn)換】
ARC僅管理Objective-C指針（retain足绅、release捷绑、autorelease），不管理CoreFoundation指針氢妈，CF指針由人工管理粹污，手動(dòng)的CFRetain和CFRelease來管理，注首量，CF中沒有autorelease壮吩。
CocoaFoundation指針與CoreFoundation指針轉(zhuǎn)換，需要考慮的是所指向?qū)ο笏袡?quán)的歸屬加缘。ARC提供了3個(gè)修飾符來管理鸭叙。
1. __bridge，什么也不做拣宏，僅僅是轉(zhuǎn)換沈贝。此種情況下：
i). 從Cocoa轉(zhuǎn)換到Core，需要人工CFRetain勋乾，否則宋下，Cocoa指針釋放后， 傳出去的指針則無效市俊。
ii). 從Core轉(zhuǎn)換到Cocoa杨凑，需要人工CFRelease滤奈，否則摆昧，Cocoa指針釋放后，對(duì)象引用計(jì)數(shù)仍為1蜒程，不會(huì)被銷毀绅你。
2. __bridge_retained，轉(zhuǎn)換后自動(dòng)調(diào)用CFRetain昭躺，即幫助自動(dòng)解決上述i的情形忌锯。
2. __bridge_transfer，轉(zhuǎn)換后自動(dòng)調(diào)用CFRelease领炫，即幫助自動(dòng)解決上述ii的情形偶垮。
英文解釋（更全面）：
What's the point of them both existing? There are a few reasons.
If you want to provide a C API, like the Carbon API, and you need things like arrays and dictionaries of referenced-counted objects, you want a library like Core Foundation (which providesCFArray), and of course it needs to have a C API.
If you want to write libraries for third-parties to use on Windows (for example), you need to provide a C API.
If you want to write a low-level library, say for interfacing with your operating system's kernel, and you don't want the overhead of Objective-C messaging, you need a C API.
So those are good reasons for having Core Foundation, a pure C library.
But if you want to provide a higher-level, more pleasant API in Objective-C, you want Objective-C objects that represent arrays, dictionaries, reference-counted objects, and so on. So you need Foundation, which is an Objective-C library.
When should you use one or the other? Generally, you should use the Objective-C classes (e.g.NSArray) whenever you can, because the Objective-C interface is more pleasant to use:myArray.count(or[myArray count]) is easier to read and write thanCFArrayGetCount(myArray). You should use the Core Foundation API only when you really need to: when you're on a platform that doesn't have Objective-C, or when you need features that the Core Foundation API provides but the Objective-C objects lack. For example, you can specify callbacks when creating aCFArrayor aCFDictionarythat let you store non-reference-counted objects. TheNSArrayandNSDictionaryclasses don't let you do that - they always assume you are storing reference-counted objects.
Are the CF objects just legacy objects? Not at all. In fact, Nextstep existed for years with just the Objective-C Foundation library and no (public) Core Foundation library. When Apple needed to support both the Carbon API and the Cocoa API on top of the same lower-level operating system facilities, they created (or made public) Core Foundation to support both.
Incidentally, some of Core Foundation is open source. You can find the open source part of it for Mac OS X 10.10.5 here:https://opensource.apple.com/source/CF/CF-1153.18/. I have found the source code ofCFRunLoopandCFStreamto be very informative.
參考資料：
http://stackoverflow.com/questions/9353804/cf-objects-vs-ns-objects
http://m.blog.csdn.net/article/details?id=8271867
