iOS-iOS工程结构解析以及多环境配置

知 识 点 / 超 人

目录
1.iOS工程结构解析

  • 1.1 Workspace
  • 1.2 Project
  • 1.3 Target
  • 1.4 Schema
  • 1.5 Configuration & xcconfig

2.多环境配置


iOS工程结构解析

iOS工程一般由:Schema -> Target -> Project -> Workspace ,这四部分核心单元组成一个 完整Xcode 工程

Workspace

Workspace:工作空间,用于管理同一个工作空间的多个project的关联关系。workspace 是纯粹的容器,不参与任何编译链接过程。

例:以cocoapods为例,如果你原本的仅仅是一个project,那么cocoapods会创建一个Podsproject用于进行第三方库源码管理,然后创建一个workspace。workspace让Pods的project与主project产生关联关系,这样就可以在主project中使用Pods的project管理的资源(这里并不是直接使用Pods的资源,而是使用Pods打包生成的.a库)。因此主project如果使用cocoapods的库,就必须使用workspace打开进行编译,否则会因为找不到引用库而报错。

image.png

Project

Project:包含项目代码、资源文件的所有信息的资源管理容器。project本身是无法被编译的,所以每个 project 至少应该有一个可编译的 target,否则就是一个空壳。而 target 编译时能引用的资源只能是它所在的 project 所管理的资源。
例如:cocoapods中,虽然Pods与主project在同一个workspace中,但是主project管理的资源与Pods的project管理的资源是互相独立的。编译时Pods会将管理的源码库编译成一个libPods.a文件,并导入到主project中,让主project对libPods.a进行资源管理。因此才得以正常引用使用
project包含的内容:
1.源文件
1.1 project中自己编写的.h和.m文件
1.2project中导入的静态库和动态库
1.3导入的资源文件(如.db文件、json文本、xml、plist等)
1.4图片资源
1.5界面资源文件(xib、storyboard等)
2.project中使用group去组织文件目录结构信息。 在文件结构的导航中,采用group去组织文件(实际开发中,尽量使用实体文件夹)
3.project的编译级别配置文件如(debug, release)
4.target
5.运行环境scheme


image.png
Target

Target:对指定代码和资源文件的具体构建方式,target 是project中最小的可编译单元,每一个 target 对应一个编译输出,这个输出可以是一个App包、一个链接库、一个可执行文件或者一个资源包。它定义了这个输出是怎样被 build 的所有细节,具体包括:

  • 1.General:可以在里面调整常用的target设置,例如标识、签名和部署选项。
  • 2.Signing & Capabilities:签名和功能,对target编译输出结果的签名和添加Apple提供的 “app 服务”功能。如 CloudKit、Game Center 或 App 内购买项目。要使用某些 app 功能服务,您必须对 app 进行预置,通过 Xcode 的项目编辑器添加功能。
  • 3.Resource Tags:用来浏览和编辑工程中全部的tag和相关资源。 内容和使用详情可以查看这篇文章
  • 4.Info:编辑project或target的属性,包括信息列表值、支持的文档类型和本地化。一个target对应一个info.plist文件。如果有多个target就有多个。
  • 5.Build Settings:编译设置,编译时会根据里面的设置信息进行编译。内容和使用详情可以查看这篇文章
  • 6.Build Phases:构建阶段,编辑和重新排序生成系统执行的任务,例如运行脚本、复制文件或链接到框架。内容和使用详情可以查看这篇文章
  • 7.Build Rules:用来指定不同文件类型分别应该如何被编译。内容和使用详情可以查看这篇文章
image.png

Build SettingsBuild Phases中配置的各种选项,大部分都是需要对应到指定的 target 的。project和target中都有Build Settings,如果设置矛盾会应用谁的?
分为两种情况:
1. project有设置,而taget没有设置,以project为准
2. project有设置,target有设置,以target为准
优先级关系(由高到低)
手动配置Target Build Settings > Target中配置的xcconfig文件 > 手动配置Project Build Settings > Project中配置的xcconfig文件

Scheme

Scheme:对指定target的编译环境配置。
在苹果的生态里,每个App每次启动都是在全新的一个沙盒中,运行的App是一个信息完全独立的个体,App之间是不可以直接进行通信的。但是iOS中可以通过URL Scheme进行App之间的调用和传递信息。可以通过target中的info的URL Types添加 URL Scheme ,在程序中通过的OpenURL来打开注册的URL Scheme 对应的app,并可以传递一些参数。
URL Scheme必须能唯一标识一个APP,如果你设置的URL Scheme与别的APP的URL Scheme冲突时,你的APP不一定会被启动起来。URL Scheme的命名应该是只能纯英文字符,而不能含有下划线或者数字。

URL Scheme
//iOS10以后打开URL Scheme的方式
UIApplication *application = [UIApplication sharedApplication];
[application openURL:[NSURL URLWithString:@"wx"] options:@{} completionHandler:nil];

日常开发中我们常常点击 Xcode 左上角的 Run 按钮运行代码,本质上就是编译该target时执行Scheme 定义的一个任务。
scheme 定义了 build 这个 target 时使用的配置选项,执行的任务,环境参数等等。Scheme 可以理解为一个编译构建的工作流,当我们点击时,Xcode 会按照 scheme 中的定义,去执行对应的构建过程。
Scheme 中预设了六个主要的构建过程: Build, Run, Test, Profile, Analyze, Archive。Scheme 中包括了我们对某个 target 的所有操作,每一个构建过程都可以单独配置。我们可以去编辑修改每个target的scheme,也可以在Manager Schemes中添加Scheme


image.png

每一个 project中,会有两个默认的 build configuration:debug 和 release。scheme中必须选择对应的configuration类型。一个configuration对应一个.xcconfig文件。可以在project的info中的Configuration中添加新的configuration,然后在Configuration中指定configuration使用哪一种xxconfig文件。

Build:只编译不运行,将对应target编译成对应的结果对象
Run:编译运行调试,执行完Build过程后,将编译结果转换为运行结果对象进行运行调试。
Analyze: 用于进行静态代码分析,可检测潜在的内存泄露(不对称 retain/release 导致的 Potential Leak)或野指针(Use of memory after it is freed)问题。编译时可选择 Build Configuration 为 Debug 沿用证书配置;
Profile: 将调起 Instruments 工具进行动态代码分析,例如 使用 Allocations/Leaks 动态跟踪分析内存泄露。编译时可选择 Build Configuration 为 Debug沿用证书配置;
Test: 用于运行测试,模拟器会启动并执行测试套件;
Archive: 可以Export as Xcode Archive,然后将 .archive 中的 .app 拖入 itunes 可 打包生成 ipa 包。

可以在Product中选择执行的构建工作流

scheme 还可以配置:
运行时的环境变量(Environment Variables)
启动时设置给 UserDefaults 的参数(Arguments Passed on Launch)
App 执行时的系统语言、模拟的定位坐标、国家等环境参数
runtime,内存管理,日志,帧率检测等调试选项

Configuration & xcconfig

Configuration:是project对target的编译环境的配置。一般工程默认会创建Debug和Release两种编译环境的配置。我们可以在project的info里面增加或删除配置的编译环境,对于不同编译环境下的参数可以直接在target中的General、Signing & Capabilities、Resource Tags、Info、Build Settings、Build Phases、Build Rules设置。也可以通过xcconfig进行设置。

image.png

xcconfig:本质是一个键值对的纯文本文件,Configuration中选择对应的xcconfig文件后,编译时会根据xcconfig的内容进行相关的配置。xcconfig中可以自定义变量,也可以去修改系统的变量,从而修改工程编译的配置信息。xcconfig文件的语法比较简单,每个配置文件都由一系列键值分配组成,

key = value

例如:修改Build Settings 里的 Other Linker Flags

//OTHER_LDFLAGS 是 Build Settings 里的 Other Linker Flags的简称变量名
//在xcconfig中加入以下代码,用于修改修改Build Settings 里的 Other Linker Flags值
OTHER_LDFLAGS = $(inherited) -ObjC -l"HYJADCrash"

编译后,会发现Build Settings 里的 Other Linker Flags变为了


image.png

如果要查找OTHER_LDFLAGS这样的系统变量,可以在官网里查找。当然也可以直接在Build Settings里选择对应系统key使用'Command+C',然后'Command+V'复制到xcconfig,就能看见对应key的系统变量的简称了。

如果配置了xcconfig,那么就算修改了Build Settings的内容,最终编译也会根据xcconfig里的内容进行覆盖。基本上Build Settings中的内容,都可以在xcconfig中进行配置。

xcconfig补充:
注释:
xcconfig中只有 // 一种注释方式,如果要在xcconfig中定义一些网址,就不能直接用https://www.baidu.com。因为//会被认为是注释。为了避免这种情况,可以单独定义一个变量表示/。用变量代替//。就不会被编译器认为是注释了

Test_SLASH = /
//隐私政策地址
Test_PRIVACY_URL = https:${XKL_SLASH}${XKL_SLASH}www.baidu.com

include导入其他xcconfig
在创建xcconfig文件的时候,可以根据需求,创建多个。也就意味着,可以通过include关键字导入其他xcconfig内的配置。通过 include关键字后接上双引号:

#include "Debug.xcconfig"

在搜索引入的文件时,如果是以/开头,代表绝对路径,例如:

//表示确切的文件位置
#include "/Users/xieyujia/Desktop/heyujia的gitHub/HYJADCrash/Pods/Target Support Files /Pods-LoginApp/Pods-HYJADCrash.debug.xcconfig"

或者通过相对路径,以${SRCROOT}路径为开始:

#include "Pods/Target Support Files/Pods-LoginApp/Pods-LoginApp.debug.xcconfig"

变量
变量定义,按照0C命名规则,仅由大写字母,数字和下划线(__)组,原则上尽量大写。字符串可以是-也可以是'号。 变量有三种特殊情况:
在xcconfig中定义的变量与Build Settings的一致,那么会发生覆盖。可以通过$(inherited),让当前变量继承变量原有值。例 如:

OTHER_LDFLAGS = -framework SDWebImage
OTHER_LDFLAGS = $(inherited) -framework AFNetworking
// OTHER_LDFLAGS = -framework SDWebImage -framework AFNetworking

注意:有部分变量不能通过xcconfig配置到Build Settings中,例如:配置PRODUCT_BUNDLE_IDENTIFIER不起作用。
引用变量,$()${}两种写法都可以:

TEACHER=$(VALUE)-${VALUE}

条件变量,根据SDK 、 Arch和Configration对设置进行条件化,例如:

// 指定 'Configration' 是'Debug
//指定'SDK'是模拟器,还有iphoneos*、macosx*等
//指定生效架构为'x86_64
OTHER_LDFLAGS[config=Debug][sdk=iphonesimulator*[arch=x86_64]= $(inherited) -framework "HYJADCrash"

注意!:在Xcode 11.4及以后版本,可以使用default ,来指定变量为空时的默认值:
1 I $(BUILD_SETTING_NAME:default=value)

总结:整个iOS工程,由workspace决定project的工作环境和关联关系,由project去管理资源,决定target的Configuration环境,由target根据Scheme和Configuration环境进行编译输出。由Scheme决定构建过程的配置环境与执行的任务,由Configuration对应的xcconfig决定编译过程的相关配置参数。


多环境配置

多环境是指,同一个project中,不同的target,不同的scheme,不同的xcconfig下,相同的代码执行不同的编译运行环境。
多环境配置的方式有多种,一般有以下两种。
1.多target的方式来配置多环境
2.配置xccongfig文件配置

日常项目中为了方便使用,都是采用的第二种xcconfig方式。cocoapods也是使用该方式。
例如:一般的项目开发,我们会分为,debug、bate、release版本。对于同一个project的代码,需要有3种编译运行环境,3种编译环境中,功能上会有所不同,连接的服务器接口不同,参数不同等。此时我们需要进行以下步骤

Release:最终上线发行的版本
Bate:上线公测或灰度测试的版本
Debug:内测版本

1.创建debug、bate、release 三个版本的.xcconfig


image.png

image.png

image.png

2.分别在三个xcconfig文件中设置对应的参数变量


image.png

image.png

3.因为在xcconfig中配置了一些非系统变量,则需要在对应的地方使用对应的变量。例如我设置了每个版本的App名称和不同的bundle id。则需要在info.plist文件里引用对应的变量。


image.png

image.png

4.创建bate版本的Configuration(系统会默认创建Debug和Release)


image.png

5.在三个版本的configuration中,选择对应的xcconfig文件


image.png

6.创建Bate、Debug、Release三个Scheme


image.png

image.png

image.png

image.png

7.在三个scheme中选择对应的configuration


image.png

8.选择对应的Scheme进行编译运行


image.png

总结:多环境配置的主要目的是,在同一套代码中,一些不同开发环境的数据、变量、基本信息和编译内容等都可以单独进行控制。而不是对代码进行侵入式的修改。这样既保证了环境的独立性又保证了编译或打包的直观性。

你可能感兴趣的:(iOS-iOS工程结构解析以及多环境配置)