頭文件引用一般都會隨著項目規(guī)模變大而可讀性變差树酪。當(dāng)大部分精力花費(fèi)在業(yè)務(wù)上往往容易忽視頭文件的使用和規(guī)范坛芽。整理下常見的頭文件疑問和知識點，希望能給正在尋找這方面答案的人一些幫助。
一、基本頭文件引用方式
說到OC中的頭文件引用茵休，不得不說三個基本的引用方式(#include、#import手蝎、@class) 和 預(yù)編譯頭文件(.pch)榕莺。
#include:
- 是編譯指令，也是C/C++中的頭文件引用方式棵介，#include是簡單的復(fù)制粘貼钉鸯，將目標(biāo).h文件中的內(nèi)容一字不落地拷貝到當(dāng)前文件中，并替換掉這句#inclued邮辽。（但GCC現(xiàn)在為C/C++做了特殊處理使得#import可以被編譯）
#import:
- 是OC中的頭文件引用方式亏拉，本質(zhì)功能是和#include是一樣的。但是多了一個功能：避免頭文件重復(fù)引用帶來的編譯錯誤逆巍。(例如：B、C同時通過#include引用A莽使；D又同時引用B锐极、C；相當(dāng)于D通過B芳肌、C重復(fù)引用了A)
如果想深究灵再，import的實現(xiàn)是通過#ifndef一個標(biāo)志進(jìn)行判斷肋层，然后在引入后#define這個標(biāo)志，來避免重復(fù)引用的翎迁。
想象一下它長這樣：
#ifndef MyFile_h
#define MyFile_h
// Some code
#endif
@class:
- 僅僅是聲明一個類名栋猖，并不會包含類的完整聲明。
- 能解決循環(huán)包含的問題：當(dāng)兩個類文件有循環(huán)依賴關(guān)系 ( A 引用 B , B 引用 A ) 時汪榔，需要用 @class
.pch預(yù)編譯頭文件：
- 一般情況下蒲拉，在OC中使用#import足矣。不過這樣的拷貝和復(fù)制對編譯速度和代碼可讀性真的好嗎痴腌？
import的實質(zhì)還是拷貝粘貼雌团，這樣就帶來兩個問題：
- 當(dāng)引用關(guān)系很復(fù)雜 或者 一個頭文件被非常多的實現(xiàn)文件引用時，編譯時引用所占的代碼量就會大幅上升（因為被引用的頭文件在各個地方都被copy了一遍）士聪；
- 公用頭文件遍布代碼之中將導(dǎo)致頭文件很長锦援。
為了解決這些問題，C系語言引入了預(yù)編譯頭文件（PreCompiled Header）剥悟，將公用的頭文件放入預(yù)編譯頭文件中預(yù)先進(jìn)行編譯灵寺，然后在真正編譯工程時再將預(yù)先編譯好的產(chǎn)物加入到所有待編譯的Source中去，來加快編譯速度区岗。比如iOS開發(fā)中Supporting Files組內(nèi)的.pch文件就是一個預(yù)編譯頭文件略板，默認(rèn)情況下，它引用了UIKit和Foundation兩個頭文件--這是在iOS開發(fā)中基本每個實現(xiàn)文件都會用到的東西躏尉。
當(dāng)然預(yù)編譯頭文件也不應(yīng)該亂用誤用蚯根，否則將導(dǎo)致工程中隨處可用本不該能訪問的代碼。編譯器無法給出準(zhǔn)確的問題報錯胀糜，增加了編譯出錯的可能性颅拦。
預(yù)編譯頭文件的使用標(biāo)準(zhǔn)：
// include file for standard system include files,
// or project specific include files that are used frequently, but
// are changed infrequently
// 包含系統(tǒng)基礎(chǔ)庫文件 或者 項目中經(jīng)常使用到但不經(jīng)常修改的特定頭文件
二、OC中的Modules和它的頭文件引用
- 關(guān)于Modules的由來教藻，可以追溯到2012年的 LLVM Developers' Meeting距帅。簡單總結(jié)下Modules的出現(xiàn)是可以保留預(yù)編譯頭文件的一個優(yōu)勢和解決幾個問題：
保留優(yōu)勢：預(yù)編譯處理，提高編譯速度括堤。
解決問題：引用濫用碌秸；難以定位編譯問題；難以維護(hù)悄窃；
Modules相當(dāng)于將框架進(jìn)行了封裝讥电，然后加入在實際編譯之時加入了一個用來存放已編譯添加過的Modules列表。如果在編譯的文件中引用到某個Modules的話轧抗，將首先在這個列表內(nèi)查找恩敌，找到的話說明已經(jīng)被加載過則直接使用已有的，如果沒有找到横媚，則把引用的頭文件編譯后加入到這個表中纠炮。這樣被引用到的Modules只會被編譯一次月趟，但是在開發(fā)時又不會被意外使用到，從而同時解決了編譯時間和引用泛濫兩方面的問題恢口。
我們看看.moudulemap的定義：
framework module LDPMChart {
umbrella header "LDPMChart-umbrella.h"
export *
module * { export * }
}
這個Module定義了首要頭文件（LDPMChart-umbrella.h）孝宗，需要導(dǎo)出的子modules（所有），以及需要link的框架名稱（LDPMChart）耕肩。需要指出的是因妇，現(xiàn)在Module還不支持第三方的框架，所以只有SDK內(nèi)置的框架能夠從這個特性中受益看疗。另外沙峻，在C++的源代碼中，Modules也是被禁用的两芳。
@import：
-
說了這么多摔寨，module 到底怎么用呢？
答：Apple在LLVM5.0（也就是Xcode5帶的最新的編譯器前端中）引入了一個新的編譯符號@import怖辆，使用@符號將告訴編譯器去使用Modules的引用形式是复，從而獲取好處。@import LDPMChart;
大部分情況下等價于
#import <LDPMChart/LDPMChart.h>竖螃。
但后者需要增加一條使用限制：在Build Settings中將Enable Modules(C and Objective-C)打開淑廊。
這樣就可以保持舊的寫法，避免把項目中的所有引用都進(jìn)行手動修改特咆。不過季惩，后者的引用方式在語法檢查時并不嚴(yán)格，在缺少modulemap頭文件暴露支持時腻格，可以編譯通過但會有missing submodule的warning画拾。如果方便還是建議使用新的引用方式@import 規(guī)范化引用。
- @import 小特性
- 使用@import之后菜职，你不用在project settings那里添加framework青抛，系統(tǒng)會自動幫你加載上了
三、小問題附錄
#import "" vs #import <>
- <>: 引用系統(tǒng)文件酬核，它用于對系統(tǒng)自帶的頭文件的引用蜜另，編譯器會在系統(tǒng)文件目錄下去查找該文件。
- "": 用戶自定義的文件用雙引號引用嫡意，編譯器首先會在用戶目錄下查找举瑰，然后到安裝目錄中查。
- 上面兩種方式的引用實質(zhì)是搜索路徑的不同蔬螟。但無論哪種方式嘶居，編譯器會將相對路徑與引用內(nèi)容組合成頭文件的絕對路徑：搜索路徑+相對路徑
Header Search Path
-
(User) Header Search Path
- Header Search Path指的是頭文件的搜索路徑。
- User Header Search Paths指的是用戶自定義的頭文件的搜索路徑
-
Always Search User Paths
- 如果設(shè)置了Always Search User Paths為YES,編譯器會優(yōu)先搜索User Header Search Paths配置的路徑，在這種情況下#include <string.h>,User Header Search Paths搜索目錄下面的文件會覆蓋系統(tǒng)的頭文件邮屁。
