Toll-Free Bridging

发布于:2014-04-25 10:35阅读数:

转自Lancy's Blog 什么是 Toll-Free Bridging 有一些数据类型是能够在 Core Foundation Framework 和 Foundation Framework 之间交换使用的。这意味着,对于同一个数据类型,你既可以将其作为参数传入 Core Foundat

转自Lancy's Blog

什么是 Toll-Free Bridging

有一些数据类型是能够在 Core Foundation Framework 和 Foundation Framework 之间交换使用的。这意味着,对于同一个数据类型,你既可以将其作为参数传入 Core Foundation 函数,也可以将其作为接收者对其发送 Objective-C 消息(即调用ObjC类方法)。这种在 Core Foundation 和 Foundation 之间交换使用数据类型的技术就叫 Toll-Free Bridging.

举例说明,NSString和CFStringRef即是一对可以相互转换的数据类型:

  1. // ARC 环境下 
  2. // Bridging from ObjC to CF 
  3. NSString *hello = @"world"
  4. CFStringRef world = (__bridge CFStringRef)(hello); 
  5. NSLog(@"%ld", CFStringGetLength(world)); 
  6.  
  7. // Bridging from CF to ObjC 
  8. CFStringRef hello = CFStringCreateWithCString(kCFAllocatorDefault, "hello", kCFStringEncodingUTF8); 
  9. NSString *world = (__bridge NSString *)(hello); 
  10. NSLog(@"%ld", world.length); 
  11. CFRelease(hello); 

 

大部分(但不是所有!)Core Foundation 和 Foundation 的数据类型可以使用这个技术相互转换,Apple 的文档里有一个列表(传送门),列出了支持这项技术的数据类型。

MRC 下的 Toll-Free Bridging 因为不涉及内存管理的转移,可以直接相互 bridge 而不必使用类似__bridge修饰字,我们之后再讨论这个问题。

 

Toll-Free Bridging 是如何实现的?

1. 每一个能够 bridge 的 ObjC 类,都是一个类簇(class cluster)。类簇是一个公开的抽象类,但其核心功能的是在不同的私有子类中实现的,公开类只暴露一致的接口和实现一些辅助的创建方法。而与该 ObjC 类相对应的 Core Foundation 类的内存结构,正好与类簇的其中一个私有子类相同。

 

举个例子,NSString是一个类簇,一个公开的抽象类,但每次创建一个NSString的实例时,实际上我们会获得其中一个私有子类的实例。而NSString的其中一个私有子类实现既为NSCFString,其内存的结构与CFString是相同的,CFString的isa指针就指向NSCFString类,即,CFString对象就是一个NSCFString类的实例。

 

所以,当NSString的实现刚好是NSCFString的时候,他们两者之间的转换是相当容易而直接的,他们就是同一个类的实例。

 

2. 当NSString的实现不是NSCFString的时候(比如我们自己 subclass 了NSString),我们调用 CF 函数,就需要先检查对象的具体实现。如果发现其不是NSCFString,我们不会调用 CF 函数的实现来获得结果,而是通过给对象发送与函数功能相对应的 ObjC 消息(调用相对应的NSString的接口)来获得其结果。

 

例如CFStringGetLength函数,当收到一个作为参数传递进来的对象时,会先确认该对象到底是不是NSCFString实现。如果是的话,就会直接调用CFStringGetLength函数的实现来获得字符串的长度;如果不是的话,会给对象发送length消息(调用NSString的- (NSUInteger)length接口),来得到字符串的长度。

 

通过这样的技术,即使是我们自己子类了一个NSString,也可以和CFStringRef相互 Bridge。

 

3. 其他支持 Toll-Free Bridging 的数据类型原理也同NSString一样,比如NSNumber的NSCFNumber和CFNumber。

 

ARC 下的 Toll-Free Bridging

如之前提到的,MRC 下的 Toll-Free Bridging 因为不涉及内存管理的转移,相互之间可以直接交换使用:

  1. // bridge 
  2. NSString *nsStr = (NSString *)cfStr;  
  3. CFStringRef cfStr = (CFStringRef)nsStr; 
  4.  
  5. // 调用函数或者方法 
  6. NSUInteger length = [(NSString *)cfStr length]; 
  7. NSUInteger length = CFStringGetLength((CFStringRef)nsStr); 
  8.  
  9. // release 
  10. CFRelease((CFStringRef)nsStr); 
  11. [(NSString *)cfStr release]; 

 

而在 ARC 下,事情就会变得复杂一些,因为 ARC 能够管理 Objective-C 对象的内存,却不能管理 CF 对象,CF 对象依然需要我们手动管理内存。在 CF 和 ObjC 之间 bridge 对象的时候,问题就出现了,编译器不知道该如何处理这个同时有 ObjC 指针和 CFTypeRef 指向的对象。

 

这时候,我们需要使用__bridge, __bridge_retained, __bridge_transfer 修饰符来告诉编译器该如何去做。

 

__bridge

最常用的修饰符,这意味着告诉编译器不做任何内存管理的事情,编译器仍然负责管理好在 Objc 一端的引用计数的事情,开发者也继续负责管理好在 CF 一端的事情。举例说明:

例子1

  1. // objc to cf 
  2. NSString *nsStr = [self createSomeNSString]; 
  3. CFStringRef cfStr = (__bridge CFStringRef)nsStr; 
  4. CFUseCFString(cfStr); 
  5. // CFRelease(cfStr); 不需要 

在这里,编译器会继续负责nsStr的内存管理的事情,不会在 bridge 的时候 retain 对象,所以也不需要开发者在 CF 一端释放。需要注意的是,当nsStr被释放的时候(比如出了作用域),意味着cfStr指向的对象被释放了,这时如果继续使用cfStr将会引起程序崩溃。

 

例子2

  1. // cf to objc 
  2. CFStringRef hello = CFStringCreateWithCString(kCFAllocatorDefault, "hello", kCFStringEncodingUTF8); 
  3. NSString *world = (__bridge NSString *)(hello); 
  4. CFRelease(hello); // 需要 
  5. [self useNSString:world]; 

在这里,bridge 的时候编译器不会做任何内存管理的事情,bridge 之后,会负责 ObjC 一端的内存管理的事情 。同时,开发者需要负责管理 CF 一端的内存管理的事情,需要再 bridge 之后,负责 release 对象。

 

__bridge_retained

接__bridge一节的第一个例子,objc to cf。为了防止nsStr被释放,引起我们使用cfStr的时候程序崩溃,可以使用__bridge_retained修饰符。这意味着,在 bridge 的时候,编译器会 retain 对象,而由开发者在 CF 一端负责 release。这样,就算nsStr在 objc 一端被释放,只要开发者不手动去释放cfStr,其指向的对象就不会被真的销毁。但同时,开发者也必须保证和负责对象的释放。例如:

  1. // objc to cf 
  2. NSString *nsStr = [self createSomeNSString]; 
  3. CFStringRef cfStr = (__bridge_retained CFStringRef)nsStr; 
  4. CFUseCFString(cfStr); 
  5. CFRelease(cfStr); // 需要 

 

__bridge_transfer

接__bridge一节的第二个例子,cf to objc。我们发现如果使用__bridge修饰符在cf转objc的时候非常的麻烦,我们既需要一个CFTypeRef的变量,还需要在 bridge 之后负责释放。这时我们可以使用__bridge_transfer,意味着在 bridge 的时候,编译器转移了对象的所有权,开发者不再需要负责对象的释放。例如:

  1. // cf to objc 
  2. CFStringRef hello = CFStringCreateWithCString(kCFAllocatorDefault, "hello", kCFStringEncodingUTF8); 
  3. NSString *world = (__bridge_transfer NSString *)(hello); 
  4. // CFRelease(hello); 不需要 
  5. [self useNSString:world]; 

 

甚至可以这么写:

  1. // cf to objc 
  2. NSString *world = (__bridge_transfer NSString *)CFStringCreateWithCString(kCFAllocatorDefault, "hello", kCFStringEncodingUTF8); 
  3. [self useNSString:world]; 

 

小结

(__bridge T) op:告诉编译器在 bridge 的时候不要做任何事情

(__bridge_retained T) op:( ObjC 转 CF 的时候使用)告诉编译器在 bridge 的时候 retain 对象,开发者需要在CF一端负责释放对象

(__bridge_transfer T) op:( CF 转 ObjC 的时候使用)告诉编译器转移 CF 对象的所有权,开发者不再需要在CF一端负责释放对象

 

参考

Concepts in Objective-C Programming 

Core Foundation Design Concepts 

Toll Free Bridging Internals 

Clang documentation: Objective-C Automatic Reference Counting (ARC)


CocoaChina是全球最大的苹果开发中文社区,官方微信每日定时推送各种精彩的研发教程资源和工具,介绍app推广营销经验,最新企业招聘和外包信息,以及Cocos2d引擎、Cocostudio开发工具包的最新动态及培训信息。关注微信可以第一时间了解最新产品和服务动态,微信在手,天下我有!

 

请搜索微信号“CocoaChina”关注我们!

CocoaChina是全球最大的苹果开发中文社区,官方微信每日定时推送各种精彩的研发教程资源和工具,介绍app推广营销经验,最新企业招聘和外包信息,以及Cocos2d引擎、Cocos Studio开发工具包的最新动态及培训信息。关注微信可以第一时间了解最新产品和服务动态,微信在手,天下我有!

请搜索微信号“CocoaChina”关注我们!

搜索CocoaChina微信公众号:CocoaChina

顶部