swift学习专题

iOS强化 : Xcode多环境配置

2021-03-29  本文已影响0人  欧德尔丶胡

前言

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

Xcode常见名词

其中真正发挥作用的打工人: Target

首先我们来看一个熟悉的东西:


通多上面修改Build Configuration的方式来切换DebugRelease的开发环境,是最基本的操作。但是很多大型的项目,并不能满足我们的开发需求, 比如说在早期一份代码可以上架多套不同UI的app,为了提高开发效率,这个时候就可以进行多渠道,多target的构建方式。 在这里介绍三种多环境的配置方式。

方式一:多个target配置

target: 在编译时就是给编译插入参数。添加配置条件信息。

配置步骤:

1. 制作一个副本

之后发现增加了一个Target和一个Info.plist文件,同时也会多一个Scheme。这里没有产生任何代码,只是多了一个打工人。

2. 修改infoplist和scheme文件名称

3. Target中预定义宏的的设置

使用:

 if(DEV){
        NSLog(@"DEV");
    }else{
        NSLog(@"");
    }

但是切换到原始target下的时候,就会报错



同理我们应该在原始target下也进行配置即可。


我们在上面工程的基础上看下混编要怎么设置(注意,视情况做出调整):
这里要注意,在添加一定要在前面加一个-

这里我们发现其缺点:

方式二:多个Scheme配置

Scheme :就是为了控制环境变量

我们可以看见:


这里有target 和 release两种模式。 我们能否添加第三种模式呢?当然是可以的。

这样我们可以选择不同的 Scheme 去设置编译的环境。比如说debug的Scheme情况下就选择编译debug 模式的。 release的Scheme情况下就选择编译release 模式的等等。
举个例子:

不同的Scheme对应不同的AppIcon:
首先我们要在Assets.xcassets再添加一个AppIcon:

假设我们现在就将字段名定义为BUNDLEDISPLAY_NAME,然后Debug模式下就叫DebugRelease模式下就叫Release
接着我们要在Info.plist文件中替换Bundle name:

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

那么我们能不能通过一个文件来 控制build setting里面的内容呢?这样我们就不需要找来找去,需要改就直接集合在一起改就好了呢?当然是可以的,接下来看第三种方式。

方式三:利用xcconfig文件,结合自定义的Scheme

其实我们在进行cocopods开发的时候,会自动生成xcconfig文件,如下:

其实这个xcconfig文件类似于plist文件,就是一个Key-Value的集合,其对应的就是Target中的设置:

因此我们可以自定义xcconfig文件。步骤如下:

1. 添加文件

⚠️ 注意:xcconfig文件的命名规则是:<文件夹名称-APP名称.对应的configuration>如下:


不使用cocopods 如下:
2. 配置文件

运行即可。

举例:在使用静态库,动态库的时候我们都会需要配置

xcconfig文件冲突

冲突 1:

实际开发中,我们会使用Cocopods来管理我们的第三方库,Cocopods也会给我们生成一些xcconfig文件(这里注意⚠️ :每次podCocopods都会从新生成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:

如果自定义xcconfigpod生成的xcconfig文件,对同一个字段进行了修改,那Xcode会用哪个文件中的配置呢?

答案是:自定义xcconfig,其实大家想一下就明白了,自定义的 引用 pod生成的,然后Xcode再引用自定义的

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

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

OTHER_LDFLAGS = -framework "SDWebImage"

同时我们也podAFNetworking
此时我们会发现,在TargetBuild Settings-Other Link Flags路面只有SDWebImage,如下:

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

OTHER_LDFLAGS = $(inherited) -framework "SDWebImage"


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

五、xcconfig配置技巧

A = /
HOST_URL = ${A}/192.168.1.1

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

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文件

总结:

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

上一篇下一篇

猜你喜欢

热点阅读