2、iOS强化 --- Xcode 多环境的配置

这里我们会介绍三种，在充分了解前两种的基础上，建议大家在开发中灵活使用第三种方法。当然，大家在熟练的情况也可以根据实际情况自己组合使用

在讲解多环境配置之前我们先来认识一下，我们在Xcode常见的一些名词，都代表什么意思？

• Project：包含了项目所有的代码，资源文件，所有信息。
• Target：对指定代码和资源文件的具体构建方式。
• Scheme：对指定Target的环境配置。
  首先我们来看一个熟悉的东西：
  image.png
  相信大家都会通多上面修改Configuration的方式来切换Debug和Release的开发环境。但是仅仅是这样并不能满足我们日常的开发需求，下面我们来介绍三种Xcode的多环境配置，希望可以在日常的开发中给大家带来方便，增加效率。

方法一：通过增加Target

我们知道，Target是对指定代码和资源文件的具体构建方式。那么理论上我们知道复制一份Target出来，然后在不同的Target下，设置不同的参数配置不就可以了吗！
下面我们来配置一下：
1、首先我们针对对应的Target，制作一个副本

image.png
2、制作完成之后，我们会发现工程里面多了一个Target和一个Info.plist文件，同时也会多一个Scheme。
image.png
image.png

3、我们可以通过修改Bundle Indentifier、Info.plist和Scheme名称来进行区分

image.png
image.png

⚠️ 注意，修改外Info.plist文件名之后，一定要在对应的Build Settings里面修改Info.plist路径

image.png

• 我们接着讲一下，Target中预定义宏的的设置
  我们再testDebug中设置自定义的宏：
  image.png
  使用如下:

if (TEST_DEBUG) {
        NSLog(@"Debug");
    } else {
        NSLog(@"Release");
    }

注意 ⚠️ ：此时TEST_DEBUG我们并不能在test中使用，因为我们只在testDebug设置了；那么当我们切换到test环境中的时候，就会报错：(这里要注意，对个Target操作的只有一套代码)

image.png
这时候我们只需要在test环境下也设置同样名字的宏就可以了，宏对应的值设置成不同的，就可以在代码里面区分不同的环境，执行不同的指令了。

• Swift环境中设置Other Swift Flags，混编情况下也是一样。
  我们在上面工程的基础上看下混编要怎么设置(注意，视情况做出调整)：
  这里要注意，在添加宏一定要在前面加一个-D
  image.png

方法二：添加Scheme

image.png
然后我们可以对不同的Scheme配置不同的configuration来进行环境区分。如下：
image-debug.png image-release.png
这样我们就可以通过切换不同的Scheme来切换不同的开发环境。

• 举个例子，不同的Scheme对应不同的AppIcon:
  首先我们要在Assets.xcassets再添加一个AppIcon：
  

  image.png
  接着我们可以在target 的 Build Settings里面设置不同的configuration对应不同的AppIcon：
  image.png

• 我们还可以针对不同Scheme设置不同的App Name：
  在Target的Build Settings里面添加自定义的字段，如下：
  

  image.png
  假设我们现在就将字段名定义为BUNDLEDISPLAY_NAME，然后Debug模式下就叫Debug，Release模式下就叫Release。
  接着我们要在Info.plist文件中替换Bundle name:
  image.png
  效果如下：
  debug.png

release.png
缺点：此时同样的，我们还是需要在Target里面修改很多东西，这样的还难免会遗漏一些东西，改起来也不是特别的方便。

方法三：利用xcconfig文件，结合自定义的Scheme来配置多环境开发

• 首先我们来了解一下什么是xcconfig文件，我们在使用cocopod的时候，会自动什么pod的xcconfig文件，如下：
  image.png
  其实这个xcconfig文件类似于plist文件，就是一个Key-Value的集合，其对应的就是Target中的设置：
  image.png
• 既然cocopod可以定义自己的xcconfig文件，那么我们也可以定义自己的xcconfig文件，这样做的好处是，将需要修改的环境变量集中到一个文件里面，这样便于管理。
  下面我们自定义自己的xcconfig文件：
  image.png
• ⚠️ 注意：xcconfig文件的命名规则是：<文件夹名称-APP名称.对应的configuration>如下：
  image.png
• 然后我们在PROJECT-Info-Configurations里面，将不同的configuration设置对应的xcconfig文件：
  image.png
• xcconfig文件其实就是一个Key-Value文件，对应的就是Target的设置。下面我们来测试一下：
  1、首先我们在Target的Build Settings里面设置自己的字段：
  image.png
  2、接着我们给工程加一个test1_Debug的Scheme，对应的就是Debug模式；原来的test1对应Release模式：
  image.png
  3、根据上面讲的，将不同的configuration设置对应的xcconfig文件，在xcconfig文件中我们这样写：
  Debug文件：APP_CONFIG = APP_Debug_Replace
Release文件：APP_CONFIG = APP_Release_Replace
  4、我们在Info.plist文件中添加一个刚刚设置的字段：
  image.png
  5、打印我们自定义的字段：

NSString *path = [NSBundle.mainBundle pathForResource:@"Info" ofType:@"plist"];
NSDictionary *infoDic = [[NSDictionary alloc] initWithContentsOfFile:path];
NSLog(@"%@",infoDic[@"APP_CONFIG"]);

/*运行test1*/
输出结果：APP_Release_Replace
/*运行test1_Debug*/
输出结果：APP_Debug_Replace

讲到这里，大家可能会觉得第三种方法中，单独添加一个test1_Debug完全就是多余，可以通过运行的时候切换test1的configuration也能实现上面的效果。
这里请大家考虑一下，实际的开发中，你面对的可能不只是Debug & Release环境，可能有本地、测试服、正式服等等。因此个人建议，用不同的Scheme区分开，是比较高效的处理方式。

这里给大家推荐一个网站，可以查到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：

解决了上面的问题，我们来看另一问题，严格将问题2也是一个衍生问题。

如果自定义xcconfig 和 pod生成的xcconfig文件，对同一个字段进行了修改，那Xcode会用哪个文件中的配置呢？
答案是：自定义xcconfig，其实大家想一下就明白了，自定义的 引用 pod生成的，然后Xcode再引用自定义的。

那么像这种问题我们该怎么解决呢？
这里我们先给出答案：使用$(inherited)，可以理解为继承。

下面我们看一下具体的使用场景：
首先我们在自定义的xcconfig文件中添加

OTHER_LDFLAGS = -framework "SDWebImage"

同时我们也pod了AFNetworking。
此时我们会发现，在Target的Build Settings-Other Link Flags路面只有SDWebImage，如下：

image.png
这也就意味着，我们引入的第三方库的链接是失败的。
这时候，我们就可以在等号加上-framework "SDWebImage"：

OTHER_LDFLAGS = $(inherited) -framework "SDWebImage"

---

这里跟大家分享一下：问题 2 的解决办法，其实就在pod自己生成的xcconfig里面，如果有兴趣可以先不自定义xcconfig，使用pod引入一个三方库，看看pod自动生成的xcconfig是怎么写的，然后对应的Target里面的设置又有了哪些变化。

Tips：
大家在配置自己的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的时候，才会执行。

优先级（由高到低）：

1. 手动配置Target Build Settings
2. Target中配置的xcconfig文件
3. 手动配置Project Build Settings
4. Project中配置的xcconfig文件