頭文件引用一般都會隨著項目規模變大而可讀性變差。當大部分精力花費在業務上往往容易忽視頭文件的使用和規范。整理下常見的頭文件疑問和知識點，希望能給正在尋找這方面答案的人一些幫助。
一、基本頭文件引用方式
說到OC中的頭文件引用，不得不說三個基本的引用方式(#include、#import、@class) 和 預編譯頭文件(.pch)。
#include:
- 是編譯指令，也是C/C++中的頭文件引用方式，#include是簡單的復制粘貼，將目標.h文件中的內容一字不落地拷貝到當前文件中，并替換掉這句#inclued。（但GCC現在為C/C++做了特殊處理使得#import可以被編譯）
#import:
- 是OC中的頭文件引用方式，本質功能是和#include是一樣的。但是多了一個功能：避免頭文件重復引用帶來的編譯錯誤。(例如：B、C同時通過#include引用A；D又同時引用B、C；相當于D通過B、C重復引用了A)
如果想深究，import的實現是通過#ifndef一個標志進行判斷，然后在引入后#define這個標志，來避免重復引用的。
想象一下它長這樣：
#ifndef MyFile_h
#define MyFile_h
// Some code
#endif
@class:
- 僅僅是聲明一個類名，并不會包含類的完整聲明。
- 能解決循環包含的問題：當兩個類文件有循環依賴關系 ( A 引用 B , B 引用 A ) 時，需要用 @class
.pch預編譯頭文件：
- 一般情況下，在OC中使用#import足矣。不過這樣的拷貝和復制對編譯速度和代碼可讀性真的好嗎？
import的實質還是拷貝粘貼，這樣就帶來兩個問題：
- 當引用關系很復雜 或者 一個頭文件被非常多的實現文件引用時，編譯時引用所占的代碼量就會大幅上升（因為被引用的頭文件在各個地方都被copy了一遍）；
- 公用頭文件遍布代碼之中將導致頭文件很長。
為了解決這些問題，C系語言引入了預編譯頭文件（PreCompiled Header），將公用的頭文件放入預編譯頭文件中預先進行編譯，然后在真正編譯工程時再將預先編譯好的產物加入到所有待編譯的Source中去，來加快編譯速度。比如iOS開發中Supporting Files組內的.pch文件就是一個預編譯頭文件，默認情況下，它引用了UIKit和Foundation兩個頭文件--這是在iOS開發中基本每個實現文件都會用到的東西。
當然預編譯頭文件也不應該亂用誤用，否則將導致工程中隨處可用本不該能訪問的代碼。編譯器無法給出準確的問題報錯，增加了編譯出錯的可能性。
預編譯頭文件的使用標準：
// include file for standard system include files,
// or project specific include files that are used frequently, but
// are changed infrequently
// 包含系統基礎庫文件 或者 項目中經常使用到但不經常修改的特定頭文件
二、OC中的Modules和它的頭文件引用
- 關于Modules的由來，可以追溯到2012年的 LLVM Developers' Meeting。簡單總結下Modules的出現是可以保留預編譯頭文件的一個優勢和解決幾個問題：
保留優勢：預編譯處理，提高編譯速度。
解決問題：引用濫用；難以定位編譯問題；難以維護；
Modules相當于將框架進行了封裝，然后加入在實際編譯之時加入了一個用來存放已編譯添加過的Modules列表。如果在編譯的文件中引用到某個Modules的話，將首先在這個列表內查找，找到的話說明已經被加載過則直接使用已有的，如果沒有找到，則把引用的頭文件編譯后加入到這個表中。這樣被引用到的Modules只會被編譯一次，但是在開發時又不會被意外使用到，從而同時解決了編譯時間和引用泛濫兩方面的問題。
我們看看.moudulemap的定義：
framework module LDPMChart {
umbrella header "LDPMChart-umbrella.h"
export *
module * { export * }
}
這個Module定義了首要頭文件（LDPMChart-umbrella.h），需要導出的子modules（所有），以及需要link的框架名稱（LDPMChart）。需要指出的是，現在Module還不支持第三方的框架，所以只有SDK內置的框架能夠從這個特性中受益。另外，在C++的源代碼中，Modules也是被禁用的。
@import：
-
說了這么多，module 到底怎么用呢？
答：Apple在LLVM5.0（也就是Xcode5帶的最新的編譯器前端中）引入了一個新的編譯符號@import，使用@符號將告訴編譯器去使用Modules的引用形式，從而獲取好處。@import LDPMChart;
大部分情況下等價于
#import <LDPMChart/LDPMChart.h>。
但后者需要增加一條使用限制：在Build Settings中將Enable Modules(C and Objective-C)打開。
這樣就可以保持舊的寫法，避免把項目中的所有引用都進行手動修改。不過，后者的引用方式在語法檢查時并不嚴格，在缺少modulemap頭文件暴露支持時，可以編譯通過但會有missing submodule的warning。如果方便還是建議使用新的引用方式@import 規范化引用。
- @import 小特性
- 使用@import之后，你不用在project settings那里添加framework，系統會自動幫你加載上了
三、小問題附錄
#import "" vs #import <>
- <>: 引用系統文件，它用于對系統自帶的頭文件的引用，編譯器會在系統文件目錄下去查找該文件。
- "": 用戶自定義的文件用雙引號引用，編譯器首先會在用戶目錄下查找，然后到安裝目錄中查。
- 上面兩種方式的引用實質是搜索路徑的不同。但無論哪種方式，編譯器會將相對路徑與引用內容組合成頭文件的絕對路徑：搜索路徑+相對路徑
Header Search Path
-
(User) Header Search Path
- Header Search Path指的是頭文件的搜索路徑。
- User Header Search Paths指的是用戶自定義的頭文件的搜索路徑
-
Always Search User Paths
- 如果設置了Always Search User Paths為YES,編譯器會優先搜索User Header Search Paths配置的路徑，在這種情況下#include <string.h>,User Header Search Paths搜索目錄下面的文件會覆蓋系統的頭文件。
