如果需要，在头文件中使用前向声明，并为在实现中使用的任何类导入头文件。换句话说，您总是#import您在实现中使用的文件，如果您需要在头文件中引用一个类，也可以使用forward声明。

例外的是，你应该在头文件中导入一个类或正式协议(在这种情况下，你不需要在实现中导入它)。

如果你看到这个警告:

警告:接收端MyCoolClass是转发类，对应的@interface可能不存在

您需要#导入文件，但是您可以在实现文件(.m)中这样做，并在头文件中使用@class声明。

@class并不(通常)消除#import文件的需要，它只是把需求移到更接近信息有用的地方。

例如

如果你说@class MyCoolClass，编译器知道它可能会看到类似这样的东西:

MyCoolClass *myObject;

除了MyCoolClass是一个有效的类之外，它不需要担心其他任何事情，并且它应该为指向它的指针保留空间(实际上，只是一个指针)。因此，在头文件中，@class占据了90%的时间。

然而，如果你需要创建或访问myObject的成员，你需要让编译器知道这些方法是什么。在这一点上(大概在你的实现文件中)，你需要#import "MyCoolClass.h"，告诉编译器除了"这是一个类"之外的其他信息。

常见的做法是在头文件中使用@class(但仍然需要#import父类)，在实现文件中使用#import。这样可以避免任何圆形夹杂物，而且效果很好。

查看关于ADC的Objective-C编程语言文档

在定义类|类接口一节中，它描述了为什么这样做:

@class指令最大限度地减少了编译器和链接器看到的代码量，因此是给出类名正向声明的最简单方法。由于简单，它避免了导入仍然导入其他文件的文件时可能出现的潜在问题。例如，如果一个类声明了另一个类的静态类型实例变量，并且它们的两个接口文件相互导入，那么两个类都不能正确编译。

三个简单的规则:

只在头文件(.h文件)中#导入超类和采用的协议。 #导入所有类和协议，你发送消息到实现(。m文件)。 其他所有东西的前向声明。

如果在实现文件中进行前向声明，则可能会出错。

另一个优点:快速编译

如果包含头文件，其中的任何更改都会导致当前文件也被编译，但如果类名被包含为@class name，则不会出现这种情况。当然，您需要在源文件中包含头文件

当我发展的时候，我脑中只有三件事，这三件事从来不会给我带来任何问题。

导入超类 导入父类(当您有子类和父类时) 在项目外部导入类(比如在框架和库中)

对于所有其他类(我的项目中的子类和子类)，我通过forward-class声明它们。

我看到很多“这样做”，但我没有看到任何“为什么”的答案。

那么:为什么在头文件中使用@class，而在实现中使用#import呢?一直使用@class和#import会使你的工作加倍。除非你使用继承。在这种情况下，您将为单个@class #import多次。然后，如果您突然决定不再需要访问某个声明，您必须记得从多个不同的文件中删除。

由于#import的性质，多次导入同一个文件不是问题。 编译性能也不是真正的问题。如果是的话，我们就不会在几乎每个头文件中都使用#importing Cocoa/Cocoa.h之类的代码了。

如果我们这么做

@interface Class_B : Class_A

意味着我们将Class_A继承到Class_B，在Class_B中我们可以访问Class_A的所有变量。

如果我们这样做

#import ....
@class Class_A
@interface Class_B

这里我们说我们在程序中使用Class_A，但如果我们想在Class_B中使用Class_A变量，我们必须在.m文件中#import Class_A(创建一个对象并使用它的函数和变量)。

我的问题是这样的。什么时候使用#import，什么时候使用@class?

简单的回答:当存在物理依赖时，使用#import或#include。否则，使用正向声明(@class MONClass, struct MONStruct， @protocol MONProtocol)。

以下是一些常见的身体依赖的例子:

任何C或c++值(指针或引用不是物理依赖项)。如果您将CGPoint作为ivar或属性，编译器将需要看到CGPoint的声明。 你的超类。 你使用的方法。

有时如果我使用@class声明，我看到一个常见的编译器警告，如下所示: “警告:接收端‘FooController’是转发类，对应的@interface可能不存在。”

The compiler's actually very lenient in this regard. It will drop hints (such as the one above), but you can trash your stack easily if you ignore them and don't #import properly. Although it should (IMO), the compiler does not enforce this. In ARC, the compiler is more strict because it is responsible for reference counting. What happens is the compiler falls back on a default when it encounters an unknown method which you call. Every return value and parameter is assumed to be id. Thus, you ought to eradicate every warning from your codebases because this should be considered physical dependence. This is analogous to calling a C function which is not declared. With C, parameters are assumed to be int.

The reason you would favor forward declarations is that you can reduce your build times by factors because there is minimal dependence. With forward declarations, the compiler sees there is a name, and can correctly parse and compile the program without seeing the class declaration or all of its dependencies when there is no physical dependency. Clean builds take less time. Incremental builds take less time. Sure, you will end up spending a little more time making sure the all the headers you need are visible to every translation as a consequence, but this pays off in reduced build times quickly (assuming your project is not tiny).

如果您使用#import或#include来代替，则会向编译器抛出大量不必要的工作。您还引入了复杂的头依赖项。你可以把它比作一个蛮力算法。当您使用#import时，会拖入大量不必要的信息，这需要大量内存、磁盘I/O和CPU来解析和编译源代码。

ObjC is pretty close to ideal for a C based language with regards to dependency because NSObject types are never values -- NSObject types are always reference counted pointers. So you can get away with incredibly fast compile times if you structure your program's dependencies appropriately and forward where possible because there is very little physical dependence required. You can also declare properties in the class extensions to further minimize dependence. That's a huge bonus for large systems -- you would know the difference it makes if you have ever developed a large C++ codebase.

因此，我的建议是尽可能使用forward，然后在有物理依赖的地方使用#import。如果您看到警告或其他暗示身体依赖的警告，请全部修复。修复方法是在实现文件中使用#import。

在构建库时，您可能会将一些接口分类为一组，在这种情况下，您将#导入引入物理依赖的库(例如#import <AppKit/AppKit.h>)。这可能会引入依赖关系，但是库维护者通常可以根据需要为您处理物理依赖关系——如果他们引入了一个特性，他们可以将其对构建的影响最小化。

向前声明只是为了防止编译器显示错误。

编译器会知道你在头文件中声明的类的名称。

如果你试图在头文件中声明一个变量，或者一个属性，你还没有导入，你会得到一个错误，说编译器不知道这个类。

你的第一个想法可能是导入它。 在某些情况下，这可能会导致问题。

例如，如果你在头文件中实现了一堆c方法，或者结构，或者类似的东西，因为它们不应该被多次导入。

因此你可以用@class告诉编译器:

我知道你不知道那门课，但它确实存在。它将被导入或在其他地方实现

它基本上告诉编译器关闭并编译，即使它不确定这个类是否会被实现。

通常在.m文件中使用#import，在.h文件中使用@class。

编译器只有在编译器需要知道其实现的情况下才会报错。

Ex:

这可以是，如果你要从中派生你的类或者 如果你要将该类的一个对象作为成员变量(尽管很少)。

如果你只是把它用作指针，它不会抱怨。当然，您必须在实现文件中#import它(如果您正在实例化该类的对象)，因为它需要知道实例化对象的类内容。

注意:#import和#include不一样。这意味着没有所谓的循环导入。Import是一种请求，要求编译器查看特定文件以获取某些信息。如果该信息已经可用，编译器将忽略它。

试试这个，在B.h中导入A.h，在A.h中导入B.h。不会有任何问题或抱怨，它也会正常工作。

何时使用@class

只有当你不想在你的头文件中导入头文件时，你才可以使用@class。在这种情况下，你甚至不关心这个类是什么。在这种情况下，您甚至可能还没有该类的头文件。

例如，您正在编写两个库。一个类，我们称之为A，存在于一个库中。该库包含来自第二个库的标头。该头文件可能有一个指针a，但同样可能不需要使用它。如果库1还不可用，如果使用@class，库B将不会被阻塞。但是如果您想导入A.h，那么库2的进程就会被阻塞。

有关文件依赖关系& #import & @class的更多信息，请查看以下内容:

http://qualitycoding.org/file-dependencies/ 这是篇好文章

文章摘要

imports in header files: #import the superclass you’re inheriting, and the protocols you’re implementing. Forward-declare everything else (unless it comes from a framework with a master header). Try to eliminate all other #imports. Declare protocols in their own headers to reduce dependencies. Too many forward declarations? You have a Large Class. imports in implementation files: Eliminate cruft #imports that aren’t used. If a method delegates to another object and returns what it gets back, try to forward-declare that object instead of #importing it. If including a module forces you to include level after level of successive dependencies, you may have a set of classes that wants to become a library. Build it as a separate library with a master header, so everything can be brought in as a single prebuilt chunk. Too many #imports? You have a Large Class.

这是一个示例场景，其中我们需要@class。

考虑一下，如果您希望在头文件中创建一个协议，该协议的参数具有相同类的数据类型，那么您可以使用@class。请记住，您也可以单独声明协议，这只是一个示例。

// DroneSearchField.h

#import <UIKit/UIKit.h>
@class DroneSearchField;
@protocol DroneSearchFieldDelegate<UITextFieldDelegate>
@optional
- (void)DroneTextFieldButtonClicked:(DroneSearchField *)textField;
@end
@interface DroneSearchField : UITextField
@end

可以把@class看作是告诉编译器“相信我，这是存在的”。

可以把#import看作是复制-粘贴。

出于多种原因，您希望最小化导入的数量。在没有任何研究的情况下，首先想到的是它减少了编译时间。

注意，当从类继承时，不能简单地使用前向声明。您需要导入文件，以便您声明的类知道它是如何定义的。