Xcode Precompile Prefix Header浅析

末蓝、 2023-10-17 09:35 102阅读 0赞

在Xcode 4, 5的模板工程中可以看到Precompile Prefix Header，但是在Xcode 6被阉割掉了，原因可以参考下面两个链接：

[http://stackoverflow.com/questions/24158648/why-isnt-projectname-prefix-pch-created-automatically-in-xcode-6][http_stackoverflow.com_questions_24158648_why-isnt-projectname-prefix-pch-created-automatically-in-xcode-6]

[http://blog.csdn.net/lihuiqwertyuiop/article/details/39268101\#comments][http_blog.csdn.net_lihuiqwertyuiop_article_details_39268101_comments]

个人理解，Xcode 6去掉Precompile Prefix Header的主要原因在于：

（1）去掉自动导入的系统框架类库的头文件，可以提高原文件的复用性，便于迁移。

（2）一个肥胖无比的Prefix Header会大大增加Build Time。

为了取代在Prefix Header中自动导入的框架，可以在每一个需要导入系统框架的文件中通过@import来手动导入，当然要确保Build Settings中的Enable Modules是打开的。

如果在Prefix Header中导入了，那么我们在工程的每一个文件中可以免费获得使用的权利，而无需手动在每一个.h/.m文件中导入。该文件确有其方便之处。

因此，如果一定要用到Precompile Prefix Header，可以参考Xcode 5的配置来手动设置。

（1）在工程中增加一个pch文件，命名还是按照Xcode 5的模板比较好：工程名-Prefix.pch，例如a-Prefx.pch

（2）设置Build Settings

其中Prefix Header指定pch文件的位置。

![20140916105059683][]

注意：开关Precompile Prefix Header时，pch的编译和导入机制是有很大不同的。

如果Precompile Prefix Header为YES，那么pch会被预编译，预编译后的pch文件会被缓存起来，从而提高编译速度。可以从下面的Build Log中看出：

![20140916110139565][]

如果Precompile Prefix Header为NO，那么pch不会被预编译，而是在每一个用到它导入的框架类库的.m文件中编译一次。例如a-Prefix.pch导入了，ViewController.m和AppDelegate.m中都使用了objc\_property\_t这个类型（注意ViewController.h/m和AppDelegate.h/m都没有另外导入），那么在Build的过程中，在编译ViewController.m和AppDelegate.m时，a-Prefix.pch会被编译2次，每个.m文件编译一次。如下图：

![20140916110436875][]

由图可知，如果Precompile Prefix Header为NO，那么每个引用了pch内容的.m文件都要编译一次pch，可能Apple会另外做缓存机制，但是这样还是降低了编译的速度。

既然Apple标准都建议我们不用pch了，那么还是尽量少用吧。当然，如果一定要用，还是尽量减少pch文件中的内容，降低工程对pch文件的依赖性，便于日后的迁移和解耦。

[http_stackoverflow.com_questions_24158648_why-isnt-projectname-prefix-pch-created-automatically-in-xcode-6]: http://stackoverflow.com/questions/24158648/why-isnt-projectname-prefix-pch-created-automatically-in-xcode-6
[http_blog.csdn.net_lihuiqwertyuiop_article_details_39268101_comments]: http://blog.csdn.net/lihuiqwertyuiop/article/details/39268101#comments
[20140916105059683]: https://img-blog.csdn.net/20140916105059683
[20140916110139565]: https://img-blog.csdn.net/20140916110139565
[20140916110436875]: https://img-blog.csdn.net/20140916110436875