浏览本文你将播种：
- iOS 编译流程
- 明确 __text、__data 的含意
- iOS dSYM 的作用和生成形式
- 明确 iOS crash 堆栈符号化解析流程
source：
iOS 编译过程的原理和利用
iOS 如何调试第三方统计到的解体报告
iOS Link Map File 文件阐明
前言
个别能够将编程语言分为两种，编译语言和直译式语言。
像 C ++,Objective C 都是编译语言。编译语言在执行的时候，必须先通过编译器生成机器码，机器码能够间接在 CPU 上执行，所以执行效率较高。
像 JavaScript,Python 都是直译式语言。直译式语言不须要通过编译的过程，而是在执行的时候通过一个两头的解释器将代码解释为 CPU 能够执行的代码。所以，较编译语言来说，直译式语言效率低一些，然而编写的更灵便，也就是为啥 JS 大法好。
iOS 开发目前的罕用语言是：Objective 和 Swift。二者都是编译语言，换句话说都是须要编译能力执行的。二者的编译都是依赖于 Clang + LLVM. 篇幅限度，本文只关注 Objective C，因为原理上大同小异。
可能会有同学想问，我不懂编译的过程，写代码也没问题啊？这点我是不否定的。然而，充沛了解了编译的过程，会对你的开发大有帮忙。本文的最初，会以以下几个例子，来解说如何正当利用 XCode 和编译
__attribute__- Clang 正告解决
- 预处理
- 插入编译期脚本
- 进步我的项目编译速度
对于不想看我啰里八嗦讲一大堆原理的同学，能够间接跳到本文的最初一个章节。
一、iOS 编译
Objective C 采纳 Clang(swift 采纳 swiftc)作为编译器前端，LLVM 作为编译器后端。
简略的编译过程如图
（一）编译器前端
编译器前端的工作是进行：词法剖析，语法分析，语义剖析，生成中间代码(intermediate representation)。在这个过程中，会进行类型查看，如果发现错误或者正告会标注进去在哪一行。
（二）编译器后端
编译器后端会进行机器无关的代码优化，生成机器语言，并且进行机器相干的代码优化。iOS 的编译过程，后端的解决如下
- LVVM 优化器会进行 BitCode 的生成，链接期优化等等。
- LLVM 机器码生成器会针对不同的架构，比方 arm64 等生成不同的机器码。
二、执行一次 XCode build 的流程
当你在 XCode 中，抉择 build 的时候（快捷键 command+B），会执行如下过程
- 编译信息写入辅助文件，创立编译后的文件架构(name.app)
-
解决文件打包信息，例如在 debug 环境下
Entitlements: { "application-identifier" = "app 的 bundleid"; "aps-environment" = development; } -
执行 CocoaPod 编译前脚本
- 例如对于应用 CocoaPod 的工程会执行
CheckPods Manifest.lock
- 例如对于应用 CocoaPod 的工程会执行
-
编译各个.m 文件，应用
CompileC和clang命令。CompileC ClassName.o ClassName.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler export LANG=en_US.US-ASCII export PATH="..." clang -x objective-c -arch x86_64 -fmessage-length=0 -fobjc-arc... -Wno-missing-field-initializers ... -DDEBUG=1 ... -isysroot iPhoneSimulator10.1.sdk -fasm-blocks ... -I 上文提到的文件 -F 所须要的 Framework -iquote 所须要的 Framework ... -c ClassName.c -o ClassName.o通过这个编译的命令，咱们能够看到
clang 是理论的编译命令
-x objective-c 指定了编译的语言
-arch x86_64 制订了编译的架构，相似还有 arm7 等
-fobjc-arc 一些列 - f 结尾的，指定了采纳 arc 等信息。这个也就是为什么你能够对独自的一个.m 文件采纳非 ARC 编程。-Wno-missing-field-initializers 一系列以 - W 结尾的，指的是编译的正告选项，通过这些你能够定制化编译选项
-DDEBUG=1 一些列 - D 结尾的，指的是预编译宏，通过这些宏能够实现条件编译
-iPhoneSimulator10.1.sdk 制订了编译采纳的 iOS SDK 版本
-I 把编译信息写入指定的辅助文件
-F 链接所须要的 Framework
-c ClassName.c 编译文件
-o ClassName.o 编译产物- 链接须要的 Framework，例如
Foundation.framework,AFNetworking.framework,ALiPay.fframework - 编译 xib 文件
- 拷贝 xib，图片等资源文件到后果目录
- 编译 ImageAssets
- 解决 info.plist
- 执行 CocoaPod 脚本
- 拷贝 Swift 规范库
- 创立.app 文件和对其签名
三、IPA 包的内容
例如，咱们通过 iTunes Store 下载微信，而后取得 ipa 安装包，而后理论看看其安装包的内容。
- 右键 ipa，重命名为
.zip - 双击 zip 文件，解压缩后会失去一个文件夹。所以，ipa 包就是一个一般的压缩包。
- 右键图中的
WeChat，抉择显示包内容，而后就可能看到理论的 ipa 包内容了。
四、二进制文件的内容
通过 XCode 的 Link Map File，咱们能够窥探二进制文件中布局。
在 XCode -> Build Settings -> 搜寻 map -> 开启 Write Link Map File
开启后，在编译，咱们能够在对应的 Debug/Release 目录下看到对应的 link map 的 text 文件。
默认的目录在
~/Library/Developer/Xcode/DerivedData/<TARGET-NAME>- 对应 ID/Build/Intermediates/<TARGET-NAME>.build/Debug-iphoneos/<TARGET-NAME>.build/例如，我的 TargetName 是EPlusPan4Phone，目录如下
/Users/huangwenchen/Library/Developer/Xcode/DerivedData/EPlusPan4Phone-eznmxzawtlhpmadnbyhafnpqpizo/Build/Intermediates/EPlusPan4Phone.build/Debug-iphonesimulator/EPlusPan4Phone.buildTips：
Derived Data 是一个文件夹，它默认状况下位于：~/Library/Developer/Xcode/DerivedData。它是 Xcode 存储各种两头构建后果、生成索引等的地位。
（一）iOS Link Map File 文件阐明
1. Link Map File 是什么
Link Map File 直译为 链接映射文件，是 Xcode 生成可执行文件时一起生成的文本，用于记录链接相干信息。
- 可执行文件的门路
- CPU 架构
- .o 指标门路
- 办法符号
2. Link Map File 有什么用
- 查看代码加载程序
- 了解内存分段分区
- Crash 时通过 Symbols 定位源码的机制
- 剖析可执行文件中类或库体积，优化包体积
3. 生成 Link Map File
Xcode 在生成可执行文件的时候默认状况下不生成该文件。
在 Xcode 的配置中 Target -> Build Setting -> Linking
将 Write Link Map File 设置为 YES 来生成 Link Map File，运行代码即可生成 Link Map File
Linking 下还能够看到生成文件的门路
通过这个门路能够拜访到
~/Developer/Xcode/DerivedData/ 我的项目 /Build/Intermediates.noindex/ 我的项目.build/Debug-iphonesimulator/ 我的项目.build/ 我的项目 -LinkMap-normal-x86_64.txt
还有一个简便办法，在 Products 下找到.app 文件，返回下层后依据门路找到 Link Map
4. 查看 Link Map File
Link Map File 次要分为 3 个局部
- 门路局部，展现生成的相干文件门路
- Section 局部，展现相干地址段
- Symbols 局部，办法符号段
（1）门路局部
- Path 是.app 文件门路
- Object files 是.o 文件门路
（2）计算机系统常识
a. text 段
这部分区域的大小在程序运行前就曾经确定，并且内存区域通常属于只读(某些架构也容许代码段为可写，即容许批改程序)。
代码段（code segment/text segment）通常是指用来存放程序执行代码的一块内存区域。
在代码段中，也有可能蕴含一些只读的常数变量，例如字符串常量等。
b. data 段
数据段（data segment）通常是指用来存放程序中已初始化的全局变量的一块内存区域。
c. bss 段
bss 段（bss segment）通常是指用来存放程序中未初始化的全局变量的一块内存区域。
bss 是英文 Block Started by Symbol 的简称。
d. 堆（heap）
堆是用于寄存过程运行中被动态分配的内存段，它的大小并不固定，可动静扩张或缩减。
当过程调用 malloc 等函数分配内存时，新调配的内存就被动静增加到堆上（堆被扩张）；
当利用 free 等函数开释内存时，被开释的内存从堆中被剔除（堆被缩减）。
e. 栈(stack)
栈又称堆栈，是用户存放程序长期创立的局部变量，
也就是说咱们函数括弧“{}”中定义的变量（但不包含 static 申明的变量，static 意味着在数据段中寄存变量）。
除此以外，在函数被调用时，其参数也会被压入发动调用的过程栈中，并且待到调用完结后，函数的返回值也会被寄存回栈中。
因为栈的先进先出 (FIFO) 特点，所以栈特地不便用来保留 / 复原调用现场。
从这个意义上讲，咱们能够把堆栈看成一个存放、替换长期数据的内存区。
（3）Section 局部
Mach-O 文件中的虚拟地址最终会映射到物理地址上。这些地址被分成不同的 Segement：__TEXT 段、__DATA 段、__LINKEDIT 段。
- __TEXT 蕴含 Mach header，被执行的代码和只读常量（如 C 字符串），只读可执行（r-x）。
- __DATA 蕴含全局变量，动态变量等，可读写（rw-）。
- __LINKEDIT 蕴含了加载程序的元数据，比方函数的名称和地址，只读（r–）。
Segement 划分成了不同的 Section，不同的 Section 存储着不同的信息，上面是一些罕用的 Section 的介绍。
a. __TEXT 段中的 Section
b. __DATA 段中的 Section
（4）Symbols 局部
- Address：办法代码的地址
- Size：办法占用的空间
- File：文件的编号
- Name：.o 文件外面的办法符号
（5）二进制重排
二进制重排 就是要重新排列这些 办法符号的程序，中心思想就是把启动用到的代码挪到后面的地位加载！
（二）解读 Link Map File 的内容
这个映射文件的次要蕴含以下局部：
1. Object files
这个局部包含的内容
- .o 文文件，也就是上文提到的.m 文件编译后的后果。
- .a 文件
-
须要 link 的 framework
#！Arch: x86_64
#Object files:
[0] linker synthesized
[1] /EPlusPan4Phone.build/EPlusPan4Phone.app.xcent
[2]/EPlusPan4Phone.build/Objects-normal/x86_64/ULWBigResponseButton.o
…
[1175]/UMSocial_Sdk_4.4/libUMSocial_Sdk_4.4.a(UMSocialJob.o)
[1188]/iPhoneSimulator10.1.sdk/System/Library/Frameworks//Foundation.framework/Foundation
这个区域的存储内容比较简单：后面是文件的编号，前面是文件的门路。<font color=”red”> 文件的编号在后续会用到 </font>
2. Sections
这个区域提供了各个段（Segment）和节（Section）在可执行文件中的地位和大小。这个区域残缺的形容克可执行文件中的全部内容。
其中，段分为两种
- __TEXT 代码段
- __DATA 数据段
例如，之前写的一个 App，Sections 区域如下，能够看到，代码段的
__text 节的地址是 0x1000021B0，大小是 0x0077EBC3，而二者相加的下一个地位正好是__stubs 的地位 0x100780D74。
# Sections:
# 地位 大小 段 节
# Address Size Segment Section
0x1000021B0 0x0077EBC3 __TEXT __text // 代码
0x100780D74 0x00000FD8 __TEXT __stubs
0x100781D4C 0x00001A50 __TEXT __stub_helper
0x1007837A0 0x0001AD78 __TEXT __const // 常量
0x10079E518 0x00041EF7 __TEXT __objc_methname //OC 办法名
0x1007E040F 0x00006E34 __TEXT __objc_classname //OC 类名
0x1007E7243 0x00010498 __TEXT __objc_methtype //OC 办法类型
0x1007F76DC 0x0000E760 __TEXT __gcc_except_tab
0x100805E40 0x00071693 __TEXT __cstring // 字符串
0x1008774D4 0x00004A9A __TEXT __ustring
0x10087BF6E 0x00000149 __TEXT __entitlements
0x10087C0B8 0x0000D56C __TEXT __unwind_info
0x100889628 0x000129C0 __TEXT __eh_frame
0x10089C000 0x00000010 __DATA __nl_symbol_ptr
0x10089C010 0x000012C8 __DATA __got
0x10089D2D8 0x00001520 __DATA __la_symbol_ptr
0x10089E7F8 0x00000038 __DATA __mod_init_func
0x10089E840 0x0003E140 __DATA __const // 常量
0x1008DC980 0x0002D840 __DATA __cfstring
0x10090A1C0 0x000022D8 __DATA __objc_classlist // OC 办法列表
0x10090C498 0x00000010 __DATA __objc_nlclslist
0x10090C4A8 0x00000218 __DATA __objc_catlist
0x10090C6C0 0x00000008 __DATA __objc_nlcatlist
0x10090C6C8 0x00000510 __DATA __objc_protolist // OC 协定列表
0x10090CBD8 0x00000008 __DATA __objc_imageinfo
0x10090CBE0 0x00129280 __DATA __objc_const // OC 常量
0x100A35E60 0x00010908 __DATA __objc_selrefs
0x100A46768 0x00000038 __DATA __objc_protorefs
0x100A467A0 0x000020E8 __DATA __objc_classrefs
0x100A48888 0x000019C0 __DATA __objc_superrefs // OC 父类援用
0x100A4A248 0x0000A500 __DATA __objc_ivar // OC ivar
0x100A54748 0x00015CC0 __DATA __objc_data
0x100A6A420 0x00007A30 __DATA __data
0x100A71E60 0x0005AF70 __DATA __bss
0x100ACCDE0 0x00053A4C __DATA __common3. Symbols
Section 局部将二进制文件进行了一级划分。而，Symbols 对 Section 中的各个段进行了二级划分，
例如，对于__TEXT __text, 示意代码段中的代码内容。
0x1000021B0 0x0077EBC3 __TEXT __text // 代码而对应的Symbols，起始地址也是0x1000021B0 。其中，文件编号和上文的编号对应
[2]/EPlusPan4Phone.build/Objects-normal/x86_64/ULWBigResponseButton.o具体内容如下
# Symbols:
地址 大小 文件编号 办法名
# Address Size File Name
0x1000021B0 0x00000109 [2] -[ULWBigResponseButton pointInside:withEvent:]
0x1000022C0 0x00000080 [3] -[ULWCategoryController liveAPI]
0x100002340 0x00000080 [3] -[ULWCategoryController categories]
....
到这里，咱们晓得 OC 的办法是如何存储的，咱们再来看看 ivar 是如何存储的。
首先找到数据栈中__DATA __objc_ivar
0x100A4A248 0x0000A500 __DATA __objc_ivar而后，搜寻这个地址0x100A4A248，就能找到 ivar 的存储区域。
0x100A4A248 0x00000008 [3] _OBJC_IVAR_$_ULWCategoryController._liveAPI值得一提的是，对于 String，会显式的存储到数据段中，例如,
0x1008065C2 0x00000029 [11] literal string: http://sns.whalecloud.com/sina2/callback
所以，若果你的加密 Key 以明文的模式写在文件里，是一件很危险的事件。
Tips: 为什么危险了？难道通过 ipa 文件也能获取到 __text、__data 这些数据？
五、dSYM 文件
全称：debug symbol
.dSYM 文件是一个符号表文件, 这外面蕴含了一个 16 进制的保留函数地址映射信息的直达文件, 所有 Debug 的 symbols 都在这个文件中(包含文件名、函数名、行号等). 个别 Xcode 我的项目每次编译后, 都会产生一个新的.dSYM 文件和.app 文件, 这两者有一个独特的 UUID.
咱们在每次编译过后，都会生成一个 dsym 文件。dsym 文件中，<font color=”orange”> 存储了 16 进制的函数地址映射。</font>
在 App 理论执行的二进制文件中，是通过地址来调用办法的。在 App crash 的时候，第三方工具（Fabric, 友盟等）会帮咱们抓到解体的调用栈，调用栈里会蕴含 crash 地址的调用信息。而后，通过 dSYM 文件，咱们就能够由地址映射到具体的函数地位。
XCode 中，抉择 Window -> Organizer 能够看到咱们生成的 archier 文件
而后，
- 右键 -> 在 finder 中显示。
- 右键 -> 查看包内容。
对于如何用 dsym 文件来剖析解体地位，能够查看我之前的一篇博客。
- iOS 如何调试第三方统计到的解体报告
Tips：我明确客户端 crash 堆栈解析的流程了：
上传 app store 前会编 archier 文件，这个文件存储了函数地址映射关系
等上传完 crash 堆栈后，依据 archier 文件 就能够反解出符号表。
其实在 应用 Time Profile 定位可复现掉帧 bug 这个章节中我就曾经接触到 dSYM 了，通过 dSYM 能够把卡顿的中央符号化解决。
六、那些你想到和想不到的利用场景
（一）iOS 如何调试第三方统计到的解体报告
原文：iOS 如何调试第三方统计到的解体报告
前言：App 上线四个月了，陆陆续续也在友盟上收到一些解体报告。这里就写一篇博客，简略介绍下如何 debug。
有一点要记住，不要指望着复现 bug 靠断点调试，有些 bug，例如多线程引起的，很难复现
1. 外围命令
dwarfdump --lookup 0x0007434d -arch arm7 uau1.3.0.app.dSYM
2. dSYM 文件
XCode 中
Window->Organizer-> 抉择提交到 App Store 的 Archies-> 右键，showin finder
右键-> 显示包内容，在 dsym 文件件里的就是符号表文件。这里蕴含着 debug 信息
或者 window->Orgainzer，间接 download dsym
3. 解体报告
以我收到的这个为例
-[NSNull length]: unrecognized selector sent to instance 0x198705e70
(null)
(
0 CoreFoundation 0x00000001862442f4 <redacted> + 160
1 libobjc.A.dylib 0x0000000197a680e4 objc_exception_throw + 60
2 CoreFoundation 0x000000018624b3a4 <redacted> + 0
3 CoreFoundation 0x0000000186248154 <redacted> + 928
4 CoreFoundation 0x000000018614accc _CF_forwarding_prep_0 + 92
5 Foundation 0x00000001871b2d98 <redacted> + 212
6 Foundation 0x00000001871b2c88 <redacted> + 200
7 Foundation 0x00000001871b3014 <redacted> + 52
8 ????????? 0x00000001000bf900 ????????? + 358656
9 ????????? 0x00000001000bf748 ????????? + 358216
10 libdispatch.dylib 0x00000001980b9994 <redacted> + 24
11 libdispatch.dylib 0x00000001980b9954 <redacted> + 16
12 libdispatch.dylib 0x00000001980be20c _dispatch_main_queue_callback_4CF + 1608
13 CoreFoundation 0x00000001861fb7f8 <redacted> + 12
14 CoreFoundation 0x00000001861f98a0 <redacted> + 1492
15 CoreFoundation 0x00000001861252d4 CFRunLoopRunSpecific + 396
16 GraphicsServices 0x000000018f93b6fc GSEventRunModal + 168
17 UIKit 0x000000018aceafac UIApplicationMain + 1488
18 ????????? 0x000000010007528c ????????? + 53900
19 libdyld.dylib 0x00000001980e6a08 <redacted> + 4
)
dSYM UUID: 916F22F5-F3B1-3709-BB7E-5B11267B5D1F
CPU Type: arm64
Slide Address: 0x0000000100000000
Binary Image: ???
Base Address: 0x0000000100068000第一局部，看看 UUID
916F22F5-F3B1-3709-BB7E-5B11267B5D1F
应用命令查看 dsym 文件的 uuid
huangwenchendeMacBook-Pro:Dsym 调试 huangwenchen$ dwarfdump --uuid uau1.3.0.app.dSYM/
UUID: EC087835-FA55-36F2-B4D9-430BF6C2BA69 (armv7) uau1.3.0.app.dSYM/Contents/Resources/DWARF/Name
UUID: 916F22F5-F3B1-3709-BB7E-5B11267B5D1F (arm64) uau1.3.0.app.dSYM/Contents/Resources/DWARF/Name对照能够看到，uuid 是统一的，那么这个 dsym 文件可用
4. 对于 uuid 的了解
每个人手机的 uuid 都是不一样的吗？每个 app 的 uuid 是雷同的吗？
UUID 是指在一台机器上生成的数字，它保障对在同一时地面的所有机器都是惟一的。
第 3 局部的背景是说每一个 app 的 ipa 包有一个惟一的 uuid，不便咱们定位是哪个包。
5. 找到????? 局部
之所以要找到这部分，是因为 crash log 中 call tree 没方法辨认的局部，往往就是本人代码的局部。
我的 Crash Log 中，别离是这三行
8 ????????? 0x00000001000bf900 ????????? + 358656
9 ????????? 0x00000001000bf748 ????????? + 358216
18 ????????? 0x000000010007528c ????????? + 53900而后，用命令定位到代码 crash 处
dwarfdump --lookup 0x000000010007528c -arch arm64 uau1.3.0.app.dSYM
看到 Log
Looking up address: 0x000000010007528c in .debug_info... found!
0x000ada5c: Compile Unit: length = 0x00001139 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x000aeb99)
0x000ada67: TAG_compile_unit [99] *
AT_producer("Apple LLVM version 7.0.0 (clang-700.1.76)" )
AT_language(DW_LANG_ObjC)
AT_name("/Users/huangwenchen/Desktop/nativeios/StampApp/StampApp/UAUOneStampMarketInfo.m")
AT_stmt_list(0x0003647f)
AT_comp_dir("/Users/huangwenchen/Desktop/nativeios/StampApp")
AT_APPLE_optimized(0x01)
AT_APPLE_major_runtime_vers(0x02)
AT_low_pc(0x0000000100074674)
AT_high_pc(0x000000010007597c)
0x000adf2d: TAG_subprogram [106] *
AT_low_pc(0x0000000100075278)
AT_high_pc(0x0000000100075298)
AT_frame_base(reg31)
AT_object_pointer({0x000adf50} )
AT_name("-[UAUOneStampMarketInfo insitutionName]" )
AT_decl_file("/Users/huangwenchen/Desktop/nativeios/StampApp/StampApp/UAUOneStampMarketInfo.m")
AT_decl_line(122)
AT_prototyped(0x01)
AT_type({0x000adcd1} (NSString*) )
AT_APPLE_optimized(0x01)
Line table dir : '/Users/huangwenchen/Desktop/nativeios/StampApp/StampApp'
Line table file: 'UAUOneStampMarketInfo.m' line 123, column 12 with start address 0x0000000100075288
Looking up address: 0x000000010007528c in .debug_frame... not found.
1其中，这两行
AT_name("-[UAUOneStampMarketInfo insitutionName]" )
AT_decl_file("/Users/huangwenchen/Desktop/nativeios/StampApp/StampApp/UAUOneStampMarketInfo.m")基本上定定位到了 UAUOneStampMarketInfo.m，中的 insitutionName 办法。
再联合
[NSNull length]:
这个谬误，也就定位到了是因为后盾返回了 NSNull 对象，本人没做查看（二） __attribute__
或多或少，你都会在第三方库或者 iOS 的头文件中，见到过__attribute__。
比方
__attribute__ ((warn_unused_result)) // 如果没有应用返回值，编译的时候给出正告
__attribtue__是一个高级的的编译器指令，它容许开发者指定更更多的编译检查和一些高级的编译期优化。
分为三种：
- 函数属性（Function Attribute）
- 类型属性 (Variable Attribute)
- 变量属性 (Type Attribute)
语法结构
__attribute__ 语法格局为：__attribute__ ((attribute-list))
放在申明分号“;”后面。
比方，在三方库中最常见的，申明一个属性或者办法在以后版本弃用了
@property (strong,nonatomic)CLASSNAME * property __deprecated;这样的益处是：给开发者一个过渡的版本，让开发者晓得这个属性被弃用了，该当应用最新的 API，然而被__deprecated 的属性依然能够失常应用。如果间接弃用，会导致开发者在更新 Pod 的时候，代码无奈运行了。
__attribtue__的应用场景很多，本文只列举 iOS 开发中罕用的几个：
// 弃用 API，用作 API 更新
#define __deprecated __attribute__((deprecated))
// 带形容信息的弃用
#define __deprecated_msg(_msg) __attribute__((deprecated(_msg)))
// 遇到__unavailable 的变量 / 办法，编译器间接抛出 Error
#define __unavailable __attribute__((unavailable))
// 通知编译器，即便这个变量 / 办法 没被应用，也不要抛出正告
#define __unused __attribute__((unused))
// 和__unused 相同
#define __used __attribute__((used))
// 如果不应用办法的返回值，进行正告
#define __result_use_check __attribute__((__warn_unused_result__))
//OC 办法在 Swift 中不可用
#define __swift_unavailable(_msg) __attribute__((__availability__(swift, unavailable, message=_msg)))
（三）Clang 正告解决
你肯定还见过如下代码：
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wundeclared-selector"
/// 代码
#pragma clang diagnostic pop这段代码的作用是
- 对以后编译环境进行压栈
- 疏忽
-Wundeclared-selector（未声明的）Selector 正告 - 编译代码
- 对编译环境进行出栈
通过 clang diagnostic push/pop, 你能够灵便的控制代码块的编译选项。
我在之前的一篇文章里，具体的介绍了 XCode 的正告相干内容。本文篇幅限度，就不具体解说了。
- iOS 正当利用 Clang 正告来进步代码品质
在这个链接，你能够找到所有的 Clang warnings 正告
- fuckingclangwarnings
（四）预处理
所谓预处理，就是在编译之前的解决。预处理可能让你定义编译器变量，实现条件编译。
比方，这样的代码很常见
#ifdef DEBUG
//...
#else
//...
#endif同样，咱们同样也能够定义其余预处理变量, 在 XCode- 选中 Target-build settings 中，搜寻 preprocess。而后点击图中蓝色的加号，能够别离为 debug 和 release 两种模式设置预处理宏。
比方咱们加上：TestServer，示意在这个宏中的代码运行在测试服务器
而后，配合多个 Target（右键 Target，抉择 Duplicate），独自一个 Target 负责测试服务器。这样咱们就不必每次切换测试服务器都要批改代码了。
#ifdef TESTMODE
// 测试服务器相干的代码
#else
// 生产服务器相干代码
#endif（五）插入脚本
通常，如果你应用 CocoaPod 来治理三方库，那么你的 Build Phase 是这样子的：
其中：[CP]结尾的，就是 CocoaPod 插入的脚本。
- Check Pods Manifest.lock，用来查看 cocoapod 治理的三方库是否须要更新
- Embed Pods Framework，运行脚本来链接三方库的动态 / 动静库
- Copy Pods Resources，运行脚本来拷贝三方库的资源文件
而这些配置信息都存储在这个文件 (.xcodeproj) 里
到这里，CocoaPod 的原理也就大抵搞清楚了，通过批改 xcodeproject，而后配置编译期脚本，来保障三方库可能正确的编译连贯。
同样，咱们也能够插入本人的脚本，来做一些额定的事件。比方，每次进行 archive 的时候，咱们都必须手动调整 target 的 build 版本，如果一不小心，就会遗记。这个过程，咱们能够通过插入脚本自动化。
buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "${PROJECT_DIR}/${INFOPLIST_FILE}")
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${PROJECT_DIR}/${INFOPLIST_FILE}"这段脚本其实很简略，读取以后 pist 的 build 版本号, 而后对其加一，从新写入。
应用起来也很简略：
- Xcode – 选中 Target – 选中 build phase
- 抉择增加 Run Script Phase
- 而后把这段脚本拷贝进去，并且勾选 Run Script Only When installing，保障只有咱们在装置到设施上的时候，才会执行这段脚本。重命名脚本的名字为 Auto Increase build number
- 而后，拖动这个脚本的到 Link Binary With Libraries 上面
（六）脚本编译打包
脚本化编译打包对于 CI（继续集成）来说，非常有用。iOS 开发中，编译打包必备的两个命令是：
// 编译成.app
xcodebuild -workspace $projectName.xcworkspace -scheme $projectName -configuration $buildConfig clean build SYMROOT=$buildAppToDir
// 打包
xcrun -sdk iphoneos PackageApplication -v $appDir/$projectName.app -o $appDir/$ipaName.ipa
通过 info 命令，能够查看到具体的文档
info xcodebuild- 残缺的脚本，应用的时候，须要拷贝到工程的根目录
（七）进步我的项目编译速度
通常，当我的项目很大，源代码和三方库引入很多的时候，咱们会发现编译的速度很慢。在理解了 XCode 的编译过程后，咱们能够从以下角度来优化编译速度：
1. 查看编译工夫
咱们须要一个路径，可能看到编译的工夫，这样能力有个比照，晓得咱们的优化到底有没有成果。
对于 XCode 8，敞开 XCode，终端输出以下指令
$ defaults write com.apple.dt.Xcode ShowBuildOperationDuration YES而后，重启 XCode，而后编译，你会在这里看到编译工夫。
代码层面的优化
2. forward declaration
所谓forward declaration，就是@class CLASSNAME，而不是#import CLASSNAME.h。这样，编译器能大大提高 #import 的替换速度。
3. 对罕用的工具类进行打包（Framework/.a）
打包成 Framework 或者动态库，这样编译的时候这部分代码就不须要从新编译了。
4. 罕用头文件放到预编译文件里
XCode 的 pch 文件是预编译文件，这里的内容在执行 XCode build 之前就曾经被预编译，并且引入到每一个.m 文件里了。
编译器选项优化
5. Debug 模式下，不生成 dsym 文件
上文提到了，dysm 文件里存储了调试信息，在 Debug 模式下，咱们能够借助 XCode 和 LLDB 进行调试。所以，不须要生成额定的 dsym 文件来升高编译速度。
6. Debug 开启Build Active Architecture Only
在 XCode -> Build Settings -> Build Active Architecture Only 改为 YES。这样做，能够只编译以后的版本，比方 arm7/arm64 等等，记得只开启 Debug 模式。这个选项在高版本的 XCode 中主动开启了。
7. Debug 模式下，敞开编译器优化
编译器优化
** 这个公众号会继续更新技术计划、关注业内技术动向，关注一下老本不高，错过干货损失不小。
↓↓↓**