前言
这里会介绍三种多环境的配置方法，开发需要根究自己的需求进行灵活使用。
Xcode常见名词
-
Project：包含了项目所有的代码，资源文件，所有信息。 -
Target：对指定代码和资源文件的具体构建方式。 -
Scheme：对指定Target的环境配置。 -
WorkSpace: 多个Project的合集环境
其中真正发挥作用的打工人： Target
首先我们来看一个熟悉的东西：
通多上面修改Build Configuration的方式来切换Debug和Release的开发环境，是最基本的操作。但是很多大型的项目，并不能满足我们的开发需求， 比如说在早期一份代码可以上架多套不同UI的app，为了提高开发效率，这个时候就可以进行多渠道，多target的构建方式。 在这里介绍三种多环境的配置方式。
方式一：多个target配置
target： 在编译时就是给编译插入参数。添加配置条件信息。
配置步骤：
1. 制作一个副本
之后发现增加了一个Target和一个Info.plist文件，同时也会多一个Scheme。这里没有产生任何代码，只是多了一个打工人。
2. 修改infoplist和scheme文件名称
3. Target中预定义宏的的设置
使用：
if(DEV){
NSLog(@"DEV");
}else{
NSLog(@"");
}
但是切换到原始target下的时候，就会报错
同理我们应该在原始target下也进行配置即可。
- 考虑到swift混编的情况下
我们在上面工程的基础上看下混编要怎么设置(注意，视情况做出调整)：
这里要注意，在添加宏一定要在前面加一个-
这里我们发现其缺点：
- 关于target的配置很繁琐，不方便。
- 还需要配置infoplist文件
方式二：多个Scheme配置
Scheme ：就是为了控制环境变量
我们可以看见：
这里有target 和 release两种模式。 我们能否添加第三种模式呢？当然是可以的。
举个例子：
不同的Scheme对应不同的AppIcon:
首先我们要在Assets.xcassets再添加一个AppIcon：
-
接着我们可以在
target的Build Settings里面设置不同的configuration对应不同的AppIcon： -
我们还可以针对不同
Scheme设置不同的App Name：
在Target的Build Settings里面添加自定义的字段，如下：
假设我们现在就将字段名定义为BUNDLEDISPLAY_NAME，然后Debug模式下就叫Debug，Release模式下就叫Release。
接着我们要在Info.plist文件中替换Bundle name:
缺点：此时同样的，我们还是需要在Target里面修改很多东西，这样的还难免会遗漏一些东西，改起来也不是特别的方便。
那么我们能不能通过一个文件来 控制build setting里面的内容呢？这样我们就不需要找来找去，需要改就直接集合在一起改就好了呢？当然是可以的，接下来看第三种方式。
方式三：利用xcconfig文件，结合自定义的Scheme
其实我们在进行cocopods开发的时候，会自动生成xcconfig文件，如下：
其实这个xcconfig文件类似于plist文件，就是一个Key-Value的集合，其对应的就是Target中的设置：
因此我们可以自定义xcconfig文件。步骤如下：
1. 添加文件
⚠️ 注意：xcconfig文件的命名规则是：<文件夹名称-APP名称.对应的configuration>如下：
2. 配置文件
运行即可。
- 实际的开发中，你面对的可能不只是
Debug&Release环境，可能有本地、测试服、正式服等等。因此个人建议，用不同的Scheme区分开，是比较高效的处理方式。
- 其实有个更有意思的事情：
XConfig文件 又叫XcodeConfigurations，我们在Build Settings里面的很多配置都可以通过这个文件通过Key-Value的方式来控制。
举例：在使用静态库，动态库的时候我们都会需要配置
- 我们在
Config文件里写入的时候，如下编译的时候Build Settings里面会自动生成配置。 那么其它的配置信息也可以类似配置。 - 在
Config文件里OTHER_LDFLAGS是什么呢？其实就是一些key的缩写，可以查到Target的各个字段对应的缩写：Xcode Build Settings
xcconfig文件冲突
冲突 1：
实际开发中，我们会使用Cocopods来管理我们的第三方库，Cocopods也会给我们生成一些xcconfig文件（这里注意⚠️ ：每次pod，Cocopods都会从新生成xcconfig文件，所以不要在Cocopods生成的xcconfig文件中做修改）
那么这个时候，就有一个问题，我们针对configuration到底要选哪一个xcconfig文件呢？当然是我们自定义的xcconfig
这样有衍生出另一问题，那么pod生成的xcconfig我们该怎么处理，如果不添加，则pod install就会出问题，如果是之前pod好的工程，那么pod中针对Target的一些设置又该怎么办？
其实很简单，我们只需要在自定义xcconfig文件中引入pod生成的xcconfig文件就可以了，如下：
#include "Pods/Target Support Files/Pods-test1/Pods-test1.debug.xcconfig"
冲突 2：
如果自定义xcconfig和 pod生成的xcconfig文件，对同一个字段进行了修改，那Xcode会用哪个文件中的配置呢？
答案是：自定义xcconfig，其实大家想一下就明白了，自定义的 引用 pod生成的，然后Xcode再引用自定义的。
那么像这种问题我们该怎么解决呢？
这里我们先给出答案：使用$(inherited)，可以理解为继承。
下面我们看一下具体的使用场景：
首先我们在自定义的xcconfig文件中添加
OTHER_LDFLAGS = -framework "SDWebImage"
同时我们也pod了AFNetworking。
此时我们会发现，在Target的Build Settings-Other Link Flags路面只有SDWebImage，如下：
这也就意味着，我们引入的第三方库的链接是失败的。
这时候，我们就可以在等号加上-framework "SDWebImage"：
OTHER_LDFLAGS = $(inherited) -framework "SDWebImage"
这里跟大家分享一下：问题 2 的解决办法，其实就在pod自己生成的xcconfig里面，如果有兴趣可以先不自定义xcconfig，使用pod引入一个三方库，看看pod自动生成的xcconfig是怎么写的，然后对应的Target里面的设置又有了哪些变化。
五、xcconfig配置技巧
- 1、在
Build Settings里面自定义了URL字段，在xcconfig如何配置//的问题
如果我们直接在xcconfig文件中写上对应的URL会是被识别为注释符号
我们可以先定义一个/的变量：
A = /
HOST_URL = ${A}/192.168.1.1
其中${A} 和 $(A) 是等价的。
- 2、比如说我们现在要配置
OTHER_LDFLAGS，按照上面讲的我们是这样写的：
OTHER_LDFLAGS = -framework "SDWebImage"
其实我们还可以添加附加条件，比如：指定特定的开发环境、机型、架构等等，如下：
OTHER_LDFLAGS[config=Debug][sdk=iphonesimulator*][arch=x86_64] = -framework "SDWebImage"
此时OTHER_LDFLAGS引入SDWebImage只会在Debug模式下，运行模拟器并且对应的执行架构为x86_64的时候，才会执行。
优先级（由高到低）：
- 手动配置
Target Build Settings -
Target中配置的xcconfig文件 - 手动配置
Project Build Settings -
Project中配置的xcconfig文件
总结：
对于多环境、多项目的配置选择xcconfig的方式最为高效。
