iOS强化 : Xcode多环境配置

2021-04-26 11:21:29 浏览数 (1)

前言


这里会介绍三种多环境的配置方法,开发需要根究自己的需求进行灵活使用。

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会是被识别为注释符号 我们可以先定义一个/的变量:
代码语言:javascript复制
A = /
HOST_URL = ${A}/192.168.1.1

其中${A}和 $(A)是等价的。

  • 2. 比如说我们现在要配置OTHER_LDFLAGS,按照上面讲的我们是这样写的:
代码语言:javascript复制
OTHER_LDFLAGS =  -framework "SDWebImage"
代码语言:javascript复制

其实我们还可以添加附加条件,比如:指定特定的开发环境、机型、架构等等,如下:

代码语言:javascript复制
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文件

总结


对于多环境、多项目的配置选择xcconfig的方式最为高效。

0 人点赞