原文链接：链接
就是那个界面。你懂得。一张文字的列表。那个有着像Mach-O Type和Rez Search Paths一样吓人的专业术语的列表。那张也许你现在正在回避的列表。那张你生怕更改了其中某一个魔咒般神奇的设定之后，app会呈现给你一个让你满带悲伤和遗憾的结果的列表。其实，那里面别有洞天，有很多你也许并不知道的超有用的东西。在这片文章里，我们将看一下其中几项，如果你弄明白了，会是一次很有趣的体验
免责声明
我是认真的，读一下
我知道我说过这并不可怕，而且我坚持这一点。但是有一点要注意。你不能撤销任何操作（如果你用了GIT，是可以的）。为了避免些许的悔恨，万分请求你在一份全新的仓库下学习这些Settings。这样你可以轻松地重置这些更改。
现在也没什么顾虑了，让我们开始吧
编译器标志（Compiler flags）
首先，我们先来看一下比较简单的一个内容。编译器标志经常被用做在编译期间定义常量，这样你可以对代码做取巧简化，比如根据编译设置运行不同的代码。
有三处地方可以设置编译器标志：
1.OTEHR_CFLAGS(Other C Flags)
2.GCC_PREPROCESSOR_DEFINITIONS(Preprocessor Macros)
3.INFOPLIST_PREPROCESSOR_DEFINITIONS(Info.plist Preprocessor Definitions)
Other C Flags和另外两个Preprocessor设置的区别在于，任何传给Other C Flags的标志，，将被直接传给编译器。这意味着，如果你想设置一个名为 FOO 的常量，你只能将这个 C Flag 的格式固定为 -DFOO。这样，编译器可以通过，而且定义了 FOO 这个常量。然而，这也意味着任何随意命名的 C FLAG 会潜在的破坏你的设置。
相反的，通过Preprocessor传给编译器的标志会被自动带上 -D 标志。 所以，像上面一样的变量 FOO，在这里可以简单的设置为 FOO。这意味着，及时你随便写了个变量名，最坏的结果就是你得到了一个没有啥子意义的变量名。
因为这一点，我建议，像定义编译器标志这种操作还是放在Preprocessor Setting里比较好。当你刻意想让变量名不经过任何处理就传给编译器时再用 Other C Flags。
编译器标志可以是一个值类型的宏（FOO=1），也可以是一个常量类型的宏（FOO）。常量类型的宏本质上是布尔类型的。他们可以被设置，也可以不用设置。值类型的宏可以有值，但是你并不希望编译器通过很复杂的运算后再去生成你的代码。如果你想使用值类型宏，坚持一个原则，那就是将flag设为1，用的时候简单的判断一下它是否存在。
那我们该怎么用呢？最简单的方法就是将代码根据编译设置分块。一旦你对你的标志完成了配置，你可以在编译期间做一些有意思的事情。举个栗子，你可以根据不同设置设置不同的baseURL：
#if RELEASEstatic NSString *const MY_API_URI = @"https://api.example.com/";#elsestatic NSString *const MY_API_URI = @"https://api.staging-example.com/";#endif
关于Info.plist文件中的 Preprocessor Flag暂且就不翻译了，要是有兴趣，请看原文
奖励关卡
其实，你可以用一些内置的标志来帮助你动态的编译代码。就我们的目的而言，比较有趣的有两个: TARGET_IPHONE_SIMULATOR 和 TARGET_OS_IPHONE。这是两个值类型的宏定义，所以在使用的时候，应该用 #if 来判断条件，而不是用 #ifdef。它们可以被用在很多有趣的地方。我最喜欢的用途就是根据不同的flag设置不同的baseURL。
#if TARGET_IPHONE_SIMULATORstatic NSString *const MY_API_URI = @":3000/";#elif RELEASEstatic NSString *const MY_API_URI = @"https://api.example.com/";#elsestatic NSString *const MY_API_URI = @"https://api.staging-example.com/";#endif现在，当运行模拟器，使用的会是local rails server。当为release模式时，会指向真实API。其他的所有情况都会指向Staging API。这样节省了好多时间！
另外，还有很多可供使用的变量可被用在动态创建编译器标志上。尤其用的多的，CONFIGURATION 变量会代表配置名称。这意味着，当你为设置了一个名为 CONFIGURATION_$(CONFIGURATION) 的预处理宏，那在debug模式下该宏就为：CONFIGURATION_DEBUG,而在release模式下则为：CONFIGURATION_RELEASE。
这么NB
一定要有节制的使用这个技术！如果没有强调这一点，我一定是懈怠极了。今天的几个例子，主要是展示了如何使用源代码的预处理，当然你可以轻松地研究的跟深入些。当你正确的使用预处理，它会成为你工作流程中的一个重要补充。你所需要做的就是知道在哪里能找到它们。
旅行，重复一个承诺和梦想，听他第二十八次提起童年往事，
