#import的用法 - 在非常大的项目中使用#import的一般指导原则(ObjC)

Question

#import我的标题和实现在哪里？
我应该做什么规则？
有没有办法在单个头文件中导入所有内容？

Answer 1

给出了"在非常大的项目中使用#import的一般指导原则 ".

那么,在这方面,Objective-C很像C和C++.将所有#includes/#imports 填充到标题中会引入许多不必要的依赖,这会为您的构建增加大量时间.因此,还可以在有关C和C++依赖关系的主题中寻求进一步的信息.

#import我的标题和实现在哪里？

通常,您应该#import只写存在物理依赖的位置.由于每个objc对象都是引用计数,并且您的属性/ ivars通常不需要存在于标头中,因此#imports远低于C++.

Robin van Dijke在他的回答中概述了身体依赖的常见情况(+1).

我应该做什么规则？有没有办法在单个头文件中导入所有内容？

嗯,这取决于你的项目的大小.有些人将他们使用的所有框架添加到PCH(预编译头).有些人把最常用的人放在PCH中,有些人根本不使用PCH文件.构建时间越长,项目越复杂,PCH应包括的越少.

如果您正在处理"非常大"的项目,您可能不应该为您的PCH添加多个Foundation.

另一个常见错误是有些人会使用PCH,所以他们需要输入更少(相当多).问题是他们的项目的常见包含/标题更改,当发生这种情况时,必须完全重建目标.

此外,如果您可以避免#import标题中的框架/库,则可以节省大量构建时间.

向#import标头添加s会导致依赖性进一步扩散.对于大量不相关的代码/框架来说很容易,只有少数源文件才能看到这些代码/框架对于大部分源文件实际可见.

最后,您应该尝试保留经常更改其他标头的标头.

最重要的是你应该:

• 根据功能分离您的程序
• 赞成前瞻性声明#import.编译器必须知道名称,但只有在创建/发送对象时才需要导入.
• 尝试将依赖项繁重的实现保留在*.m文件中.

每隔一段时间,它可以帮助查看一些源文件的预处理输出 - 看看实际#import编辑的内容 - 结果可能非常令人惊讶.

笔记:

• 必须为项目中的每种语言生成PCH.
• 根据需要编制来源; 例如,如果您有C程序,请不要将它们编译为ObjC.
• 随着项目复杂性的增加,通过除以目标(例如静态库,模块,逻辑划分测试......)所获得的收益将会增加.正确地构建具有低依赖性的依赖目标本身就是一个很大的主题.当结构正确时,它可以真正帮助您在更高频率下构建和测试(如果您使用持续集成或有多个开发人员,这也很重要).像标题依赖项一样,如果你从一开始就不考虑这个问题,那么旧的问题可能需要花费大量的工时才能纠正(在它已经变得无法忍受的速度之后).