Xcode工程中有个编译设置Generate Debug Symbols，翻译为'生成调试符号', 默认设置是为YES的。看到这个设置我们可能会思考🤔：如果设置release环境下为NO，不生成调试符号的话，包体积会不会更小呢？毕竟我们发布到App Store上的版本是不需要调试的。带着这样的出发点，于是去了解了一番。
一、官方文档说明
Boolean value. Specifies whether the binary includes debug symbols.
YES: Binary includes debugging symbols.
NO: Binary does not include debugging symbols.
官文
二、自己的实践总结
1. 在设置里面找到Generate Debug Symbols, 改为NO.
首先，在项目的target下打断点后，运行 ==》程序遇到断点不会停。
然后，这个情况下在项目的pod库子工程打断点会不会停呢？
因为项目中使用Pod进行库管理，并且Podfile中写了generate_multiple_pod_projects: true, 所以Pod库会生成一个子工程。在Pod库中打断点，运行 ==> 程序遇到断点会停住，底部调试台左边的变量也会显示，但是po命令打印时会有两种情况：
// 1.如果pod库是静态库，那么这个时候po打印会报错
(lldb) po self
error: Couldn't realize type of self.
// 2.如果pod库是动态库，那么这个时候po打印是正常的
(lldb) po self
▿ name : Optional<String>
- some : "碧波花园"
最后，我们现在把子工程中的Generate Debug Symbols, 改为NO，断点也是不会停住的！！！
2. 对比主工程中设置为YES和NO的区别
对于上述的结果，我们首先想到的是动态库在生成打包生成ipa时是会独立生成可执行文件的，而静态库是直接打包进主工程二进制文件中的。
所以接下来，我们在release模式下运行一次，对比Generate Debug Symbols设置为YES和NO的区别：
2.1 编译到运行的时间=》设置为YES时更长
本人的demo工程编译到运行的对比：
YES时：42s左右
NO时 ：38s左右
2.2 设置为YES相比NO，产物多了dSYM文件
两种设置下分别打开Product（这个需要 xcode中导入了pod库才会生成，并且换设置时别忘了clean一下），对比发现, 设置为YES会多出dSYM文件:
2.3 编译的过程不同
调试符号是在编译时生成的。在Xcode中查看构建过程，可以发现，当Generate Debug Symbols选项设置为YES时，每个源文件在编译成.o文件时，编译参数多了-g和-gmodules两项。但链接等其他的过程没有变化。
Clang文档对-g的描述是：
Generate complete debug info.
三、了解了这些后在项目中有什么作用？
项目中我们一般是默认要生成调试符号的，即Generate Debug Symbols = YES。因为我我们需要dSYM才能定位Crash，其次是对于APP来说ipa的体积并没有减小！
对于项目中集成了Bugly的同行们应该对于dSYM不陌生.
- dSYM 是保存 16 进制函数地址映射信息的中转文件，存储应用程序的调试 symbols, 在XCode项目编译设置
Generate Debug Symbols=YES；然后Debug Infomation Format=DWARF with dSYM File后会生成，一般我们debug下设置DWARF，release下设置DWARF with dSYM File.
- DSYM文件->显示包内容->...，我们可以找到里面是有
DWARF的文件.
DWARF是一种类似抽象语法树的调试格式文件，里面包含了符号表、调试信息等，可以通过MachOView打开来查看。在Debug时，我们有lldb调试器与DWARF配合，所以不需要dSYM；在Release时，需要生成dSYM，因为DWARF内容是包含在dSYM文件中的，以便于后续Crash信息符号还原。
- 我们上传到Bugly的符号表文件实际上是对dSYM文件提取轻量符号表生成的文件
具体可以参看文章：
iOS dSYM详解和分析crash，ips文件
dwarf格式
DWARF文件初探——提取轻量符号表
