Post

iOS 开发基石：深入解析 `#import`、`#include` 与 `@import`

深入探讨

Posted Updated
By ledgerheath
8 min read
iOS 开发基石：深入解析 `#import`、`#include` 与 `@import`

iOS 开发基石：深入解析 #import、#include 与 @import

在 iOS 开发的漫长岁月中，许多开发者在编写 Objective-C 代码时，往往下意识地敲下 #import，却很少思考其背后的编译器行为。作为一名资深开发者，理解这些预处理指令的区别，不仅是基础知识的体现，更是优化编译时间、规避依赖冲突的关键。

本文将深入探讨 #include、#import 以及现代化的 @import 之间的区别，并补充关于头文件引用的最佳实践。

一、 历史的包袱：#include vs #import

1. C 语言的 #include：傻瓜式拷贝

#include 是 C/C++ 中最原始的预处理指令。它的工作原理非常简单粗暴：文本替换。 编译器预处理器（Preprocessor）在遇到 #include "A.h" 时，会直接将 A.h 文件的所有内容复制粘贴到当前位置。

存在的问题（Diamond Problem）： 假设 A.h 和 B.h 都引用了 Base.h。如果你在 main.m 中同时写了：

1
2

#include "A.h"
#include "B.h"

编译器实际上会将 Base.h 的内容复制两次。这会导致结构体、枚举或类的重定义错误（Redefinition Error）。

在 C/C++ 中，我们通常需要使用“宏卫兵”（Include Guards）来手动解决这个问题：

1
2
3
4
5

// Base.h
#ifndef BASE_H
#define BASE_H
   // 代码内容
#endif

2. Objective-C 的 #import：智能引入

Objective-C 为了解决 C 语言的繁琐，引入了 #import。 它的核心特性是：智能防止重复包含。 编译器在处理 #import 时，会先检查该文件是否已经被引入过。如果是，则直接跳过。这意味着我们在编写 Objective-C 头文件时，完全不需要编写 #ifndef 这种防御性代码。

结论：在 Objective-C 开发中，永远使用 #import。只有当你编写纯 C/C++ 代码或跨平台 C 库时，才考虑使用 #include。

二、 路径的艺术：双引号 "" vs 尖括号 <>

决定使用引号还是尖括号，取决于你希望编译器去哪里找这个文件。

1. #import "X.h"（自定义文件）

  • 搜索逻辑：
    1. Local Path：首先搜索包含该指令的源文件所在的当前目录。
    2. User Header Search Paths：搜索 Xcode Build Settings 中配置的用户头文件路径。
    3. System Paths：如果都没找到，最后才会去系统路径搜索。
  • 适用场景：项目内的业务代码、自定义类、PCH 文件。

2. #import <X.h>（库文件）

  • 搜索逻辑：
    1. 忽略当前目录：直接跳过本地文件搜索。
    2. System/Framework Paths：直接去 Xcode 配置的系统框架路径（如 SDK 目录）或第三方库路径中搜索。
  • 适用场景：iOS SDK（UIKit, Foundation）、第三方静态库、CocoaPods 管理的库。

3. 为什么要区分？

虽然在很多时候，用 "" 引用系统库也能编译通过（因为编译器最终会兜底去查系统路径），但这是一种Bad Smell：

  • 编译性能：使用 "" 引用系统库会增加编译器在本地目录的无效 I/O 查找，积少成多会拖慢编译速度。
  • 歧义风险：如果你的项目中碰巧有个文件叫 UIKit.h，使用 "" 可能会意外引入你自己的文件而不是系统库，导致难以排查的 Bug。

三、 现代化的演进：Modules 与 @import

从 iOS 7 / Xcode 5 开始，Apple 引入了 Modules（模块） 机制。

1. 什么是 @import？

1
2

@import UIKit;
@import MapKit;

这不是文本拷贝，而是引入编译好的二进制模块规范。

2. 它的优势

  • 预编译加速：模块是预先编译好的，引入速度远快于解析数十万行文本代码。
  • 自动链接：使用 @import 后，你不再需要在 Build Phases 的 “Link Binary With Libraries” 中手动添加 Framework，编译器会自动处理链接。

3. 现状

在现代 Xcode 项目中（Build Settings 中 Enable Modules (C and Objective-C) 默认为 YES），即使你写的是老式的 #import <UIKit/UIKit.h>，编译器在底层也会自动将其映射为 @import UIKit;。 因此，虽然你依然可以使用 #import 保持兼容性，但理解 Modules 的机制能帮你更好地理解编译过程。

四、 进阶补充：前向声明 @class

作为资深开发者，除了知道怎么 import，更要知道什么时候不要 import。

在 .h 文件中，如果仅仅是为了声明一个属性是某个类的实例，请务必使用 @class（前向声明）。

错误示范 (MyClass.h)：

1
2
3
4
5

#import "SomeHugeObject.h" // 引入了整个头文件

@interface MyClass : NSObject
@property (nonatomic, strong) SomeHugeObject *obj;
@end

最佳实践 (MyClass.h)：

1
2
3
4
5

@class SomeHugeObject; // 仅告诉编译器这是一个类

@interface MyClass : NSObject
@property (nonatomic, strong) SomeHugeObject *obj;
@end

然后在 MyClass.m 文件中再真正 #import "SomeHugeObject.h"。

使用 @class 的好处：

  1. 减少编译时间：避免了递归式的头文件解析。如果不使用 @class，当 SomeHugeObject.h 发生微小改动时，所有引用 MyClass.h 的文件都需要重新编译。
  2. 解决循环依赖：如果 ClassA 引用 ClassB，ClassB 又引用 ClassA，只有通过 @class 才能打破死循环。

五、 总结

  1. 指令选择：Objective-C 代码一律使用 #import，杜绝 #include。
  2. 符号规范：
    • 引用自己的代码：使用 #import "MyClass.h"。
    • 引用系统库/第三方库：使用 #import <Framework/Header.h>。
  3. 性能优化：在头文件（.h）中尽量使用 @class 前向声明，将实际的 #import 推迟到实现文件（.m）中进行，以缩短增量编译时间。
iOS, Objective-C, import, include, 模块化
iOS Objective-C import include 模块化
This post is licensed under CC BY 4.0 by the author.