iOS强化 : Xcode多环境配置
前言
这里会介绍三种多环境的配置方法，开发需要根究自己的需求进行灵活使用。
1. Xcode常见名词
- Project：包含了项目所有的代码，资源文件，所有信息。
- Target ：对指定代码和资源文件的具体构建方式。
- Scheme ：对指定 Target 的环境配置。
- WorkSpace : 多个 Project 的合集环境
其中真正发挥作用的打工人：Target
首先我们来看一个熟悉的东西：
通多上面修改Build Configuration的方式来切换Debug和Release的开发环境，是最基本的操作。但是很多大型的项目，并不能满足我们的开发需求， 比如说在早期一份代码可以上架多套不同 UI 的 app，为了提高开发效率，这个时候就可以进行多渠道，多target 的构建方式。在这里介绍三种多环境的配置方式。
2. 方式一：多个target配置
target：在编译时就是给编译插入参数。添加配置条件信息。
配置步骤：
▐ 2.1 制作一个副本
之后发现增加了一个Target和一个Info.plist文件，同时也会多一个Scheme。这里没有产生任何代码，只是多了一个打工人。
▐ 2.2 修改infoplist和scheme文件名称
▐ 2.3 Target中预定义宏的的设置
使用：
if(DEV){
NSLog(@"DEV");
}else{
NSLog(@"");
}但是切换到原始 target 下的时候，就会报错
同理我们应该在原始target下也进行配置即可。
- 考虑到 swift 混编的情况下
我们在上面工程的基础上看下混编要怎么设置(注意，视情况做出调整)： 这里要注意，在添加宏一定要在前面加一个-
这里我们发现其缺点：
- 关于 target 的配置很繁琐，不方便
- 还需要配置 infoplist 文件
3. 方式二：多个Scheme配置
Scheme ：就是为了控制环境变量
我们可以看见：
这里有target 和 release两种模式。我们能否添加第三种模式呢？当然是可以的。
这样我们可以选择不同的 Scheme 去设置编译的环境。比如说 debug 的 Scheme 情况下就选择编译 debug 模式的。release 的 Scheme 情况下就选择编译 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 里面的内容呢？这样我们就不需要找来找去，需要改就直接集合在一起改就好了呢？当然是可以的，接下来看第三种方式。
4. 方式三：利用xcconfig文件，结合自定义的Scheme
其实我们在进行cocopods开发的时候，会自动生成xcconfig文件，如下：
其实这个xcconfig文件类似于plist文件，就是一个Key-Value的集合，其对应的就是Target中的设置：
因此我们可以自定义xcconfig文件。步骤如下：
▐ 4.1 添加文件
⚠️ 注意：xcconfig 文件的命名规则是：<文件夹名称 -APP 名称.对应的 configuration> 如下：
不使用cocopods 如下：
▐ 4.2 配置文件
运行即可。
- 实际的开发中，你面对的可能不只是Debug& Release环境，可能有本地、测试服、正式服等等。因此个人建议，用不同的Scheme区分开，是比较高效的处理方式。
- 其实有个更有意思的事情：XConfig文件 又叫Xcode Configurations ，我们在Build Settings里面的很多配置都可以通过这个文件通过Key-Value的方式来控制。
举例：在使用静态库，动态库的时候我们都会需要配置
- 我们在Config文件里写入的时候，如下编译的时候Build Settings 里面会自动生成配置。那么其它的配置信息也可以类似配置。
- 在Config文件里 OTHER_LDFLAGS是什么呢？其实就是一些key的缩写，可以查到Target的各个字段对应的缩写：Xcode Build Settings
▐ 4.3 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里面的设置又有了哪些变化。5. 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的方式最为高效。