关于objective-c:iOS编译过程的原理和应用

浏览本文你将播种：

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

编译各个.m文件，应用CompileC和clang命令。

CompileC ClassName.o ClassName.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compilerexport LANG=en_US.US-ASCIIexport 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.build

Tips：
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    Section0x1000021B0    0x0077EBC3    __TEXT    __text //代码0x100780D74    0x00000FD8    __TEXT    __stubs0x100781D4C    0x00001A50    __TEXT    __stub_helper0x1007837A0    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_frame0x10089C000    0x00000010    __DATA    __nl_symbol_ptr0x10089C010    0x000012C8    __DATA    __got0x10089D2D8    0x00001520    __DATA    __la_symbol_ptr0x10089E7F8    0x00000038    __DATA    __mod_init_func0x10089E840    0x0003E140    __DATA    __const //常量0x1008DC980    0x0002D840    __DATA    __cfstring0x10090A1C0    0x000022D8    __DATA    __objc_classlist // OC 办法列表0x10090C498    0x00000010    __DATA    __objc_nlclslist 0x10090C4A8    0x00000218    __DATA    __objc_catlist0x10090C6C0    0x00000008    __DATA    __objc_nlcatlist0x10090C6C8    0x00000510    __DATA    __objc_protolist // OC协定列表0x10090CBD8    0x00000008    __DATA    __objc_imageinfo0x10090CBE0    0x00129280    __DATA    __objc_const // OC 常量0x100A35E60    0x00010908    __DATA    __objc_selrefs0x100A46768    0x00000038    __DATA    __objc_protorefs 0x100A467A0    0x000020E8    __DATA    __objc_classrefs 0x100A48888    0x000019C0    __DATA    __objc_superrefs // OC 父类援用0x100A4A248    0x0000A500    __DATA    __objc_ivar // OC ivar0x100A54748    0x00015CC0    __DATA    __objc_data0x100A6A420    0x00007A30    __DATA    __data0x100A71E60    0x0005AF70    __DATA    __bss0x100ACCDE0    0x00053A4C    __DATA    __common

3. 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       Name0x1000021B0    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-5B11267B5D1FCPU Type: arm64Slide Address: 0x0000000100000000Binary 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/NameUUID: 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 0x0000000100075288Looking 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开发中，编译打包必备的两个命令是：

//编译成.appxcodebuild  -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模式下，敞开编译器优化

编译器优化

**这个公众号会继续更新技术计划、关注业内技术动向，关注一下老本不高，错过干货损失不小。
↓↓↓**

前言