xcode 配置文件*.xcconfig
Configuration Settings File文件，后缀名为*.xcconfig
可以设定多个环境自匹配debug模式和release模式，eg： debug.xcconfig release.xcconofig
如何新增变量：
在*.xxconfig文件中添加：GCC_PREPROCESSOR_DEFINITIONS = $(inherited) DEBUG=1 COCOAPODS=1 PRODUCT_WALLET=1 MARK_POINT_INFO=@\"46000221\"
指令集Architectures 配置
处理器：中央处理器
程序编译后，要调用处理器能识别的指令来完成我们设定程序要做的任务。这些指令必须是处理器能够识别并能够执行的。这就引出了两个元素，处理器和处理器对应的指令集合。比如 ARM 处理器 ，指令集合比如 arm7 , arm7s, arm64等等。
真机指令集：
模拟器指令集
Architectures:
包含的指令集
Excluded Architectures
xcode 12 新增功能，要排除掉的指令集，一般模拟器中去掉 arm指令集 可以在*.xcconfig中设定：EXCLUDED_ARCHS[sdk=iphonesimulator*] = arm64
Other Linker Flags
ios工程的编译过程：源代码 > 预处理器 > 编译器 > 汇编器 > 机器码 > 链接器 > 可执行文件
问题：Objective-C的链接器并不会为每个方法建立符号表，而是仅仅为类建立了符号表。这样的话，如果静态库中定义了已存在的一个类的分类，链接器就会以为这个类已经存在，不会把分类和核心类的代码合起来。这样的话，在最后的可执行文件中，就会缺少分类里的代码，这样函数调用就失败了。
解决方法：other linker flags添加
-ObjC 链接器就会把静态库中所有的Objective-C类和分类都加载到最后的可执行文件中
-all_load或者-force_load ：如果文件只有分类，没有类，-ObjC不起作用，此时使用-all_load（不常用，如果有两个类同名可能会有duplicate symbol错误）
Debug Information Format
xcode 配置文件 Build Settings -> Build Options -> Debug Information Format 中设置
DWARF：不会产生dSYM符号表文件
DWARF with dSYM File会产生dSYM符号表文件
$(inherited)
一般用于配置Frameworker Search Paths，Header Search Paths等，$(inherited) 代表Target中的配置继承上面project默认的配置
Podfile文件配置
ios中 .h文件即头文件，无论是framework(动态库)方式还是.a(静态库)方式，都会有头文件
使用use_frameworks!
使用cocoapods管理项目时，Podfile文件中声明use_frameworks! 表示使用第三方库导入工程会使用framework方式，一般swift工程或者混合工程使用
工程中导入类方式： #import "<XXX/XXX.h>"
不使用use_frameworks!
工程中导入第三方库会使用xxxlib.a方式
工程中导入类方式： #import "XXX.h"
原因分析：
xcode制作动态库和静态库
xcode早期常用.a静态库方式，必须要配置 Header Search Path头文件，头文件配合,a文件使用，而且在链接时会copy .a静态库代码到app的可执行文件中，而且随着.a文件被使用次数的增加，整个app提交也会增加，制作静态库时，Mach-O Type选择 Static Library
后面xcode推出了framework方式，framework可以制作动态库，也可以制作静态库，区别在于Mach-O Type的设置，经过实验发现，无论是静态库还是动态库，xcode相当于进行了简化：
1）使用framework方式的库包，可以不用设置Header Search Path头文件，但是必须指定framework search path
2）使用framework打的静态包（Mach-O Type配置成 Static Library）可以指定Embed 也可以指定 do not Embed（代表framwork嵌入到app可执行代码中）
3）使用framework打的动态包，必须是 embed（代表framwork嵌入到app资源包中，app运行使用的时候，动态链接）
4）和.a文件不同的是，由于没有配置头文件，在使用的时候需要指定framwork 例如 #import "<XXX/XXX.h>"
cocoapods 和carthage区别：
carthage导入framework，swift项目的包管理，只编译一次
cocoapods每次都会编译
http://www.cloudchou.com/ios/post-990.html
xcode多工程联编
1）使用xxx.xcworkspace只是多个xxx.xcodeproj的捆绑，并没有其他设置
2）xcode有个很有趣的特性，至今未搞懂：（多个子工程联编的时，主工程会自动编译子工程）
test1为主工程，test2为子工程，test2一般是我们创建的 framwork sdk，在test1的xcode配置中引入test2.framwork后，如果test.framwork对应的工程源码和test1在同一个xcworkspace下，编译主工程时，会自动联编译test2子工程，也就是test2可以断点调试，这也是为什么pods的工程每次都是重新编译三方库，而carthage不会，carthage没有中央管理的概念，引入每个三方库都只是是引入三方库自己的framwork而且没有引入源码