3

为什么 iOS 中的某些库提供了基于 C 的 API？例如，Core Graphics 库是由基于 C 的 API 提供的。但是，我无法理解苹果这样做的原因。

而且，[[UIColor red] setStroke]drawRect中的那种代码：也让我很困惑！如果 Apple 决定使用基于 C 的 API，为什么他们使用面向对象样式的代码来处理图形？

并且CGContextAddLineToPoint()，例如，接受参数CGContextRef c。我认为它完全适合使用面向对象的东西。

// current
CGContextRef context = UIGraphicsGetCurrentContext();
CGContextMoveToPoint(context, 0, 0);
CGContextAddLineToPoint(context, 10, 10);

// looks better
CGContext *context = [UIGraphics getCurrentContext]
[context moveToPoint: CGMakePoint(0, 0)] // or [context moveToPointX: 0 y: 0]
[context addLineToPoint: CGMakePoint(10, 10)]  // or [context addLineToPointX: 10 y: 10]

那么，为什么 Apple 在某些库上使用基于 C 的 API？

4

4 回答 4

7

表现

  1. 因为与 Objective-C 对象相比，C 中的内存开销更少
  2. 加速，因为不需要通过 Objective-C 运行时
于 2013-02-12T19:25:20.080 回答
6

一个可能的原因是性能。

当您向对象发送消息时，编译器会将其转换为对名为 C 函数的调用，该函数将objc_msgSend()您发送消息的对象、消息和消息的任何参数作为参数。然后它会进行查找以确定与该消息对应的实际函数的位置并将控制权传递给它。

我确信 Apple 已经优化了它，objc_msgSend因为它被频繁调用，但它仍然会比简单的函数调用慢很多。

于 2013-02-12T19:30:28.417 回答
4

抽象的原因之一可以在 Apple 的历史中找到。当 Cocoa 首次亮相 Mac（作为 Rhapsody OS 中的 Yellow Box）时，许多大型开发人员不愿意将他们的用户界面移植到它。因此，在 Mac OS X 10.0 发布时，现有的 Mac Toolbox 被清理并与 Cocoa 一起作为“Carbon”发布。

Carbon 和 Cocoa 有很多功能重叠，因此创建共享的、基于 C 的库很有意义。虽然 Carbon 的受欢迎程度下降了，但 iOS 已经出现，C 库对于 Apple 操作系统之间的抽象仍然有用——在 AppKit 和 UIKit 之间。

注意：根据经验，您应该尝试使用满足您需求的最高级别的 API。例如，如果UIBezierPath并且UIColor会给你想要的东西，那么你可以（并且可能应该）留在 Objective-C 花园中以获得可读性、易于调试和面向未来。但是，根据功能和性能要求，您始终可以退回到 CoreGraphics。同样，如果您需要在应用程序中处理线程并发任务，NSOperation子类是一种干净且一致的方式，但如果您的需求是独特的，您总是可以回退到 GCDdispatch_()方法。

于 2013-02-12T20:58:32.003 回答
2

一方面，C它是一种开销较小的低级语言。当您引入对象时，您会引入一些开销以换取在大多数情况下更易于遵循的程序结构。

此外，由于 iOS 和 OS X 都基于 Unix 内核，Apple API 中提供的任何低级操作系统集成要么用更常用的跨平台语言C编写，要么编写为这些相同C功能的包装器。在某些时候，Apple 不值得花时间Objective-C为所有内容提供包装器。

于 2013-02-12T19:28:47.503 回答