iOS开发之.pch文件初识

pch全称是“precompiled header”，即预编译头文件，自Xcode6诞生之日起，便在Supporting Files文件下消失多年。说起苹果对pch的爱恨情仇，其分析pch的作用便不言而喻。

pch文件里存放的是工程中一些不常被修改的代码，比如常用的框架头文件，宏定义，这样做的目的提高编译器编译速度，而同时Prefix Header大大的增加了Build的时间。所以缺失了头文件后，需要在引用的类中申明@import的.h文件，编程便利性的同时也降低了Build的时间，其优劣自我斟酌可罢。

若需要add头文件，还需要修改project的配置文件才可被引入，pch文件的路径添加到Building Settings中的Apple LLVM 6.1 - Language选项的属性列表中，将Prefix header添加其路径“$(SRCROOT)/project名称/pch头文件名”，即其Debug跟Release路径也同步被添加成。

另：如果Precompile Prefix Header为YES，那么pch会被预编译，预编译后的pch文件会被缓存起来，从而提高编译速度。如果Precompile Prefix Header为NO，那么pch不会被预编译，而是在每一个用到它导入的框架类库的.m文件中编译一次，降低了编译速度。

对于怎样使用pch，可参考stack overfolw的answers：http://stackoverflow.com/questions/24158648/why-isnt-projectname-prefix-pch-created-automatically-in-xcode-6

As to where to put code that you would put in a prefix header, there is no code you should put in a prefix header. Put your imports into the files that need them. Put your definitions into their own files. Put your macros...nowhere. Stop writing macros unless there is no other way (such as when you need __FILE__). If you do need macros, put them in a header and include it.

The prefix header was necessary for things that are huge and used by nearly everything in the whole system (like Foundation.h). If you have something that huge and ubiquitous, you should rethink your architecture. Prefix headers make code reuse hard, and introduce subtle build problems if any of the files listed can change. Avoid them until you have a serious build time problem that you can demonstrate is dramatically improved with a prefix header.

In that case you can create one and pass it into clang, but it's incredibly rare that it's a good idea.