前言
首先这篇是译文，原文在这里
如果有不正确的地方，欢迎指正。进入正题：
Toll Free Bridging
Toll-free bridging(TFB)，是允许某些OC类和某些CF类之间可转换的一种机制。例如：NSString和CFString是可桥接的，这意味着你可以将NSString当做CFString来用，反之亦然。代码：
CFStringRef cfStr = SomeFunctionThatReturnsCFString();
NSUInteger length = [(NSString *)cfStr length];
NSString *nsStr = [self someString];
CFIndex length = CFStringGetLength((CFStringRef)nsStr);
大多数（不是全部！）的Cocoa和CoreFoundation的类都是通过这种方式桥接的。一个可桥接的类在Apple官方文档中会有提及其对应的桥接后的类。
CF桥接到OC
从CoreFoundation的类桥接到OC的类的方法（CFString如何表现得像一个NSString）非常简单。
每一个可桥接的类实际都是一个类簇，就是说我们所能看到的公共类(如NSString)是一个抽象类，核心的功能的实现都在其私有的子类中。CoreFoundation类给定了一个内存布局来匹配这些私有的子类，这是为了能够成为OC对应的CoreFoundation类。其他的（不可桥接）OC类也有可能就是一个独立的类，而非一个抽象。从外面看来，他们的表现和工作起来都一样，因为他们都共享相同的接口。
具体的，看一下NSString。NSString是一个抽象类。每次你手动创建一个字符串，你实际是获取了一个NSString子类的实例。
NSString其中一个子类就是NSCFString，其直接对应的是CFString。CFString结构体中的isa指针指向的就是一个NSCFString类，这就能够让他在功能上表现的和一个OC对象一样。
NSCFString实现所有方法，来当作一个NSString正常工作。有两种方法，方法之一是作为一个存根，调用时通过他对应的CoreFoundation来实现每个方法。另一种方法是实现每个方法来匹配他对应的CoreFoundation的工作。现实情况中，内部实现的代码或许混合了这两种方式的。
为了这个目的，桥接的机制是非常简单的。CFString对象会变成一个NSString 的子类 ->NSCFString的实例，通过他来实现方法，所以他们表现的就像同一个一样。许多实现是调用CoreFoundation来完成他们的工作的。
从Objc到CF的桥接
这种桥接稍微复杂一点。这是因为任何给定的TFB OC类的实例能够成为一个任意数量类的实例，甚至是在应用中创建的自定义的类。例如你创建一个NSString的子类，然后你有了一个自定义的类，可是这些自定义的类仍旧很明显的通过调用CoreFoundation的函数来工作。你可以对你自定义的NSString的子类的实例调用CFStringGetLength方法，然后他会唤起你的-length方法，返回结果给调用者。给人的感觉是，你的实例即是你自定义类的实例，又是NSCFString类的实例，但是你创建的却是NSString的子类。
事实证明，这其中并没有什么特别的魔法。这只是种纯粹的暴力。CFStringGetLength的实现是这样的：
CFIndex CFStringGetLength(CFStringRef str) {
CF_OBJC_FUNCDISPATCH0(__kCFStringTypeID, CFIndex, str, "length");
__CFAssertIsString(str);
return __CFStrLength(str);
}
第一行中一个丑陋的宏定义隐藏了TFB工作的秘密。这个宏检查了对象的isa指针是否是NSCFString。如果他不是，那么他不是一个“真正”的CFString，那只会是其他的OC类。在这种情况下，CoreFoundation 代码不知道怎么查找length，所以他只是发送length消息到对象，然后返回结果。这就是自定义的子类如何工作的。如果他是一个“真”的CFString，那么他简单的调用__CFStrLength，做一些在CFString结构体中查找字符串长度的实际工作，并返回这个结果。
简单来说：每个TFB类的CoreFoundation函数第一步是检查传入的这个对象是一个“真”的CoreFoundation对象还是一个纯粹的OC类。如果是一个纯粹的OC，他简单的通过OC的方法来调用，然后结束。否则，就正常执行。这就是为什么我说他是纯粹的暴力：为了使TFB工作，每个方法的调用在最开始会有一次检查。
这种实现由一个有趣的问题。考虑一下如果你搞混了，对CFArray发送了CFStringGetLength方法。isa指针检查会发现这不是一个NSCFString，所以他会由ObjC来调度。最终结果，会报这样的错：
-[NSCFArray length]: unrecognized selector sent to instance 0x100108e50
一段纯粹的CoreFoundation代码，竟然爆出一个OC方法调用错误，呵呵哒。。
桥接的基本行为
以上就是类的明确的桥接工作。但是还有一个TFB更有趣的地方：基本行为通过所有对象也为所有类桥接来共享。本质上，NSObject是桥接到CFType的。作为一个最常见的例子，桥接后，有可能CFRetain任意OC对象，retain任意CoreFoundation对象。就像其他的桥接，如果你在OC代码中重写了retain方法，CFRetain将会调用你重写的方法。这个工作不仅仅是内存管理，对于任何CFType的函数，像CFCopyDescription方法，以及对于任何NSObject方法，就好比是执行了：
performSelector:withObject:afterDelay:
为了桥接到OC，CoreFoundation对象的第一个字段isa指针指向一个OC类。对于桥接后的类，它指向OC对应的类；对于非桥接的类，它指向一个特殊的__NSCFType 类。这些类都是NSObject的子类（大多数都是间接的子类），所以自然的，他们继承所有行为。方法会映射到CoreFoundation对应的部分，这些类单纯是重写了这些方法，并且在必要时通过CoreFoundation来调用。
桥接到CF的机制就像是特殊的桥接。CFRetain的第一行，以及所有其他的CFType函数会检查：对象是一个“真”的CF对象还是一个其他乱七八糟的OC类。如果他是一个“真”的CF对象，那么他就正常的工作。否则，他会通过OC来派发，并通过OC来执行所有的工作。
创建桥接后的类
我希望这个标题不要让大家报太大希望，因为，简单的说：你，不能。现在我们知道桥接是怎么工作的，为什么不能也就很明显了。你不能创建桥接一个存在的，未桥接的CF类，因为他需要CoreFoundation大量的协作。每一个函数调用需要在顶部有一行代码来检查这个传入的对象的类，并且，如果必要的话派发给OC，而且你添加不了这些。你也不能创建一个新的桥接后的CF类，因为你不能创建一个新的CF类。Apple不会对外揭露这些。（讲真，你想要在你写的每个函数中都布满类的检查吗？写一个纯粹的OC类不就好了，简单又漂亮）
结论
现在你知道toll-free bridging的基础工作了。如果你对派发的代码以及他是如何工作的等这些更深入的技术细节感兴趣，点这里。
