objective-c - 在 Objective-C 中包含头文件的成本

Question

这似乎是一个非常愚蠢的问题，但是#import在 Objective-C 中包含（实际上是调用）头文件的成本是多少？我厌倦了在不同位置不断包含相同的标题，因此我决定简单地创建一个GlobalReferences.h包含几个常用标题的文件。

如果甚至不使用对其他文件的引用，是否有任何可观的成本？我的直觉告诉我“不”，因为链接器似乎只是在使用时知道其他文件#import，但我不确定是否需要对 iPhone 开发采取特殊考虑，这是我的项目所关注的。有什么想法吗？

Answer 1

#import链接器对ed 文件一无所知。事实上，Objective-C 编译器也对它们一无所知，它们是由预处理器预处理出来的。预处理器有效地将标头的内容插入到您将它们包含在源文件中的位置。实际的 Objective-C 编译器将不得不处理额外的函数原型和类接口定义，即使它们没有被使用。虽然这通常不是一项冗长的任务，但它会增加编译时间。应用程序的最终大小和性能应该不受影响。

要查看原始源代码的样子（包括所有头文件和扩展宏等）：

gcc -E your-source-file.m

Answer 2

导入/包含比您需要的更多的头文件会增加编译时间。您可以使用预编译的头文件来减轻一些痛苦。

Answer 3

最大的缺点是编译时间。如果在每个源文件中都导入了所有头文件，那么每次更改头文件时都必须重新构建整个项目。

Answer 4

我的印象是它不会太受欢迎： http ://en.wikipedia.org/wiki/Objective-C#.23import

Answer 5

在 Objective-C 中包含（实际上是调用#import）头文件的成本是多少？

编译器可能会不必要地读取这些文件。编辑#import后，对于每个可见的翻译（例如文件），都需要解析、编译等附加文件.m——使您的构建和链接时间更长。长 10 倍也就不足为奇了。

我厌倦了在不同的位置不断包含相同的标头，因此我决定简单地创建一个包含几个常用标头的 GlobalReferences.h 文件。

通常，这是一个非常糟糕的方法。常见的问题是，每当 GlobalReferences.h 包含的任何文件发生更改时，您的整个项目和所有中间依赖项都需要重新构建、重新链接等。

我的偏好是将程序分成存在这种相互依赖关系的小库或包（例如，StoreKit.framework 是一个小包/库）——但是将这些库/框架/包填充到标头中并不能解决任何问题。此外，前向声明和将数据存储在类延续中或@implementation可以显着减少依赖关系（因为您可以将包含的库/标题本地化为仅必要的翻译）。

最后，在惰性包含之后进行清理非常耗时，尤其是当有很多并且您一直等到项目的构建时间慢得无法忍受时。基本上，你必须回去挑选不必要的依赖关系，重建，重复（几天）。

如果甚至不使用对其他文件的引用，是否有任何可观的成本？

绝对地。你的项目越大，惰性包含变得越糟糕。大型项目中的一些惰性包含可能会在大多数已编译文件中添加数万或数十万行，并可能触发对许多源代码的频繁重新编译。这大大增加了构建过程的复杂性——CPU 需求上升，RAM 使用率上升，磁盘 IO 上升......随着代码库/项目复杂性的增加，这再次成为一个更大的问题。

Answer 6

继续做吧。除非您包含的标头很大并且您没有使用预编译的标头，否则您不应该看到任何差异。正如其他人所说，#import是一个预处理器指令。这没有运行时后果，在许多情况下也没有显着的编译时间后果。