pch讓編譯更快

在日常的開發(fā)中，有很多地方會(huì)用到Foundation和UIKit，使用之前需要先將頭文件#import進(jìn)來。與C語言中的#include相似，import會(huì)把頭文件里的代碼copy過來，只不過#import可以避免重復(fù)引用。比如， #import "Test.h" 等同于：

#ifndef Test_h#

define Test_h

#include "Test.h"

#endif

如果你的每個(gè)文件都需要引用同一個(gè)頭文件，如UIKit.h，那么這個(gè)文件會(huì)被拷貝和編譯多次，這會(huì)增加build的時(shí)間。 節(jié)約生命，從減少build時(shí)間開始。

預(yù)編譯頭文件，顧名思義，是將頭文件事先編譯成一種二進(jìn)制的中間格式。在整個(gè)編譯過程中，只編譯一次，并且會(huì)有緩存，如預(yù)編譯頭所涉及的部分不發(fā)生改變的話，在隨后的編譯過程中此部分不會(huì)重新進(jìn)行編譯，從而大大提高編譯速度。在iOS開發(fā)中，我們可以在xxx.pch中定義需要預(yù)編譯的頭文件，在Xcode 6 之前，自動(dòng)生成的pch如下：

    #ifdef __OBJC__

    #import <Foundation/Foundation.h>

    #import <UIKit/UIKit.h>

    #endif

pch的副作用

加入pch中的頭文件，在項(xiàng)目其他地方要使用時(shí)，就不需要再import了。這可以算是一種便利，但它也是副作用的源頭。切記： pch的目的是提高編譯速度，而不是讓你少打幾行import代碼。

1. 不利于代碼移植 

   
   如果同一份代碼需要在多個(gè)項(xiàng)目中使用，過度使用pch會(huì)帶來麻煩。假設(shè)項(xiàng)目A的pch中加了這樣一行代碼： #import <Security/Security.h> ，而你的某個(gè)組件使用了Security，將組件代碼copy到項(xiàng)目B去可能編譯不了，因?yàn)轫?xiàng)目B的pch并沒有添加Security.h

   
   

2. 隱式依賴關(guān)系 

   
   本來我們可以通過掃描xxx.h和xxx.m文件，找到xxx所依賴的模塊。但是濫用pch會(huì)讓這些依賴關(guān)系被掩蓋，因?yàn)槟愕奈募赡茈[式地依賴了pch中定義的某些頭文件。我在另外一篇文章架構(gòu)設(shè)計(jì)中的循環(huán)引用中提到文件之間不應(yīng)該循環(huán)引用，否則系統(tǒng)將越來越復(fù)雜和不可維護(hù)。

   
   

有節(jié)制地使用pch

在Xcode 6之后，新建項(xiàng)目已經(jīng)不會(huì)自動(dòng)生成pch文件了。個(gè)人認(rèn)為原因有兩個(gè):

• 因?yàn)樗母弊饔?/p>

• Modules的引入可以更好地替代預(yù)編譯頭

• 
  

iOS 7之后，系統(tǒng)的Module都可以被"semantic import"。使用起來很簡(jiǎn)單，把原來的#import換成@import即可。比如：

#import <Foundation/Foundation.h> 換成 @import Foundation; 即可。

編譯器遇到 @import 時(shí)，會(huì)將預(yù)編譯好的framework載入，同時(shí)也不需要到project settings里添加framework，系統(tǒng)會(huì)幫你做這些事情。 所有重復(fù)性的勞動(dòng)都應(yīng)該被自動(dòng)化。 這些Module只會(huì)編譯一次，因此已經(jīng)可以不用pch了。

不過，pch也并沒有完全退出歷史舞臺(tái)。有一些場(chǎng)景還是會(huì)使用到，比如你的每個(gè)文件都需要用到你定義的一些方法。加入pch的文件應(yīng)該滿足：

• 基本大多數(shù)文件都會(huì)用到

  
  

• 
  

• 不應(yīng)該經(jīng)常改動(dòng)，宏定義，常量定義等不應(yīng)該放在pch里，pch應(yīng)該只有#import 或者 #include 。

• 
  

有節(jié)制地用，寧可多敲幾行代碼，不要偷懶把很多東西都放pch里。