前言
这里会介绍三种多环境的配置方法,开发需要根究自己的需求进行灵活使用。
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中预定义宏的的设置
使用:
代码语言:javascript复制 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文件就可以了,如下:
代码语言:javascript复制#include "Pods/Target Support Files/Pods-test1/Pods-test1.debug.xcconfig"
代码语言:javascript复制
冲突 2:
如果自定义xcconfig和 pod生成的xcconfig文件,对同一个字段进行了修改,那Xcode会用哪个文件中的配置呢?
答案是:自定义xcconfig,其实大家想一下就明白了,自定义的 引用pod生成的,然后Xcode再引用自定义的。
那么像这种问题我们该怎么解决呢?
这里我们先给出答案:使用$(inherited),可以理解为继承。
下面我们看一下具体的使用场景: 首先我们在自定义的xcconfig文件中添加
代码语言:javascript复制OTHER_LDFLAGS = -framework "SDWebImage"
代码语言:javascript复制
同时我们也pod了AFNetworking。 此时我们会发现,在Target的Build Settings-Other Link Flags路面只有SDWebImage,如下:
这也就意味着,我们引入的第三方库的链接是失败的。
这时候,我们就可以在等号加上-framework "SDWebImage":
代码语言:javascript复制
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"
代码语言:javascript复制
其实我们还可以添加附加条件,比如:指定特定的开发环境、机型、架构等等,如下:
代码语言:javascript复制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的方式最为高效。