logo标签列表

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

objective-cimportheaderdependenciesheader-files
9
这可能看起来是一个非常愚蠢的问题，但是在Objective-C中包含（实际上是调用#import）头文件的成本是多少？我厌倦了在各个位置不断地包含相同的头文件，所以我决定简单地创建一个GlobalReferences.h文件，其中包括几个常用的引用头文件。
如果根本没有使用其他文件，包含对其他文件的引用是否会有任何显着的成本？我的直觉告诉我“不会”，因为似乎链接器只是在使用#import时意识到其他文件，但我不确定是否需要特别考虑iPhone开发，这就是我的项目关注的内容。有什么想法吗？
6个回答
7
链接器对于使用#import导入的文件一无所知。实际上，Objective-C编译器也对它们一无所知，它们被预处理器预处理掉了。预处理器会将头文件的内容插入到你在源代码文件中包含它们的位置。即使这些文件没有被使用，实际的Objective-C编译器仍需要处理额外的函数原型和类接口定义。虽然这通常不是一个耗时的任务，但它可能会增加编译时间。应用程序的大小和性能不应受影响。
要查看原始源代码的样子（包括所有头文件和扩展宏等），请执行以下操作：
gcc -E your-source-file.m
3

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

2

最大的缺点在于编译时间。如果你的每个源文件都引入了所有的头文件，那么每次你修改一个头文件时就需要重新构建整个项目。

1
1
在Objective-C中包含（实际上是调用＃import）头文件的成本是多少？
编译器可能会不必要地运行以读取这些文件。一旦被＃import，附加文件将需要被解析、编译等，对于每个它可见的翻译（例如.m文件）-- 使您的构建和链接时间更长。10倍长并不令人惊讶。
我厌倦了在各个位置不断包含相同的头文件，所以我决定简单地创建一个GlobalReferences.h文件，其中包括几个常用引用的头文件。
通常，这是一个非常糟糕的方法。常见的问题是，每当GlobalReferences.h包含的任何文件发生更改时，您的整个项目和所有中间依赖项都需要重新构建、重新链接等。
我的偏好是将程序分成小型库或包，其中存在这种相互依赖关系（例如StoreKit.framework是一个小型包/库）--但是将这些库/框架/包塞入头文件中解决不了任何问题。此外，前向声明和将数据存储在类继续或@implementation中可以显着减少依赖性（因为您可以将库/头文件的包含局限于仅必要的翻译）。
最后，清理懒惰引用非常耗时，特别是当有很多引用并且你等到项目的构建时间变得难以忍受时。基本上，你必须回去挑出不必要的依赖项，重新构建，重复（数天）。
“如果根本没有使用其他文件的引用，是否会有任何显著成本呢？”
绝对有。你的项目越大，懒惰引用就越糟糕。在一个大型项目中，几个懒惰引用可能会向大多数编译文件添加数万或数十万行，并且可能会触发许多源代码的频繁重新编译。这增加了构建过程的复杂性——CPU需求大幅上升，RAM使用量大幅上升，磁盘IO大幅上升...而且，随着你的代码库/项目变得越来越复杂，这将成为一个更大的问题。
0

继续前进并完成它。除非你包含的头文件很大且你没有使用预编译头文件，否则你不应该看到任何差异。正如其他人所说，#import是一个预处理器指令。这对运行时没有影响，在许多情况下也没有显著的编译时间影响。

谢谢大家对这个问题的澄清。 - CIFilter
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接