Mach-O(Mach Object)是macOS、iOS、iPadOS存儲程序和庫的文件合適。對應(yīng)系統(tǒng)通過應(yīng)用二進制接口(application binary interface，縮寫為ABI) 來運行該格式的文件。

Mach-O格式用來代替BSD系統(tǒng)的a.out格式。Mach-O文件格式保存了在編譯過程和鏈接過程中產(chǎn)生的機器代碼和數(shù)據(jù)，從而為靜態(tài)鏈接和動態(tài)鏈接的代碼提供了單一文件格式。

除了之外，還有一些文件也是Mach-O格式，比如：

• 目標(biāo)文件.o
• 庫文件
  .a
.dylib
Framework
• dyld（動態(tài)鏈接器）
• .dsym（符號表）

由此我們知道，可執(zhí)行文件只是Mach-O的一種，因此我們將Mach-O文件分為以下幾種：

通用二進制文件（Universal binary）

支持多架構(gòu)的Mach-O ececutable(可執(zhí)行文件)被稱為：通用二進制文件，即多種架構(gòu)都可讀取運行。

• 通用二進制文件具有以下特性：
  1、Apple 提出的一種程序代碼，能夠同時適配多種架構(gòu)的二進制文件。
  2、同一個程序包中，同時為多種架構(gòu)提供最理想的性能。
  3、通用二進制應(yīng)用程序通常比單一平臺二進制程序大，因為需要存儲多種代碼。
  4、由于多種架構(gòu)之間有共通的非執(zhí)行資源，所以并不會比單一架構(gòu)的兩倍大。
  5、程序在執(zhí)行的時候只調(diào)用一部分代碼，運行起來不需要額外的內(nèi)存。

• 那么多種架構(gòu)是什么意思呢？下面我們通過file指令來看一下我們的可執(zhí)行文件：
  

  image.png
  
  通過上圖，我們可以看到test可執(zhí)行文件的類型是Mach-O；架構(gòu)是x86_64，這是我們用模擬器運行的可執(zhí)行文件。
  我們再實際開發(fā)中遇到的設(shè)置arm64&armv7這些都是對應(yīng)的架構(gòu)：
  |名字|注釋|
  |---|---|
  |arm64|真機64位處理器需要arm64架構(gòu)(iphone6,iphone6p以上的真機)|
  | armv7s |真機32位處理器 ( ipnone5,iphone5s真機/armv7s)|
  | armv7 |真機32位處理器 (iphone4真機/armv7)|
  | x86_64 |模擬器64位處理器 (iphone6以上的模擬器)|
  | i386|模擬器32位處理器 (iphone5,iphone5s以下的模擬器)|

• Tips：
  在Xcode中設(shè)置Arhitectures，Debug屬性設(shè)置為NO的時候，會編譯支持所有架構(gòu)的版本，編譯的速度會變慢，設(shè)置為yes的時候，只編譯當(dāng)前的Arhitectures版本，編譯速度快。
  

  image.png

通用二進制文件的拆分 與 組合

• 在MachOView中，通用二進制文件也被叫做Fat binary。
  這種二進制文件是可以拆分、或者重新組合的
  ?? 注意這里我采用的是真機測試，Scheme對應(yīng)的Build Configuration選用Release模式。(關(guān)于Xcode環(huán)境的配置，有不清楚的同學(xué)可以看這里：Xcode 多環(huán)境的配置)
  ?? 這里還有一點要注意：測試的時候，如果工程只包含一種架構(gòu)，此時要手動添加其他架構(gòu)。

• 我們可以通過file指令，也可以通過lipo -info指令查看二進制文件支持的架構(gòu)：
  

  image.png
  
  
  image.png

可以看到，目前test可執(zhí)行程序支持arm64 和 arm_v7兩種架構(gòu)。
那么下面我們先進行文件拆分：

拆分Fat binary

linpo mach-o文件名 -thin 要拆分的架構(gòu)名 -output 拆分出來的文件名

拆分前的ipa包內(nèi)容：

image.png

image.png

image.png

合并 Fat binary

lipo -create macho_arm64 macho_armv7 -output newTest

合并之后的文件與原文件并無差異，我們可以通過哈希值也看一下：

image.png

Mach-O 文件結(jié)構(gòu)

• Mach-O文件主要由 3 部分組成：

mach-o.png

?? 既然Mach-O是二進制文件，那么它又是怎么知道哪一塊內(nèi)容是Load commands，哪一塊又是Header的呢？
其實這里涉及到一個概念叫做結(jié)構(gòu)體對齊，簡單的講就是：按照一定的規(guī)則組合到一起，再按照既定的規(guī)則拆分就可以了。

Mach Header

image.png

/*
 * The 64-bit mach header appears at the very beginning of object files for
 * 64-bit architectures.
 */
struct mach_header_64 {
    uint32_t    magic;      /* mach magic number identifier */
    cpu_type_t  cputype;    /* cpu specifier */
    cpu_subtype_t   cpusubtype; /* machine specifier */
    uint32_t    filetype;   /* type of file */
    uint32_t    ncmds;      /* number of load commands */
    uint32_t    sizeofcmds; /* the size of all the load commands */
    uint32_t    flags;      /* flags */
    uint32_t    reserved;   /* reserved */
};

在load.h文件中mach_header_64比mach_header(32位的頭文件)多了一個保留字段

uint32_t    reserved;   /* reserved */

mach_header是鏈接器加載的時候最先讀取的內(nèi)容，它決定了一些基礎(chǔ)架構(gòu)，系統(tǒng)類型，指令條數(shù)等信息。

Load Commands

Load Commands 詳細保存著加載指令的內(nèi)容，告訴鏈接器如何去加載當(dāng)前的Mach-O文件。
那么每一條Load Command對應(yīng)的又是什么意思呢？
同樣的我們也可以在load.h搜索的到，我們以LC_SEGMENT_64為例：

image.png

Data

Data段又分為：__TEXT段 和 __DATA段

• __TEXT段
  代碼的讀取是從__TEXT段開始讀取的，其中不同的__TEXT代表的意思如下：

• __DATA段
  __DATA段在內(nèi)存中緊跟在__TEXT段之后

名字	注釋
__got	全局偏移表
__la_symbol_ptr	lazy binding的指針表，表中的指針一開始都指向__stub_helper
__cfstring	工程中使用的Core Foundation字符串(CFStringRefs)
__objc_classlist	OC 類列表
__objc_protolist	OC protocol列表
__objc_imginfo	OC 鏡像信息
__const	沒有初始化過的常量
__objc_selfrefs	OC 引用的SEL列表
__objc_protorefs	OC 引用的protocol列表
__objc_superrefs	OC 引用的父類列表
__objc_ivar	OC ivar信息
__objc_data	class信息
__bss	BSS，存放 的全局變量，就是常說的靜態(tài)內(nèi)存分配
__data	初始化的可變數(shù)據(jù)

?? 這里有一點大家需要注意，系統(tǒng)庫的方法在我們自己的Mach-O文件里面是找不到的，它存放在共享緩存區(qū)。那么我們自己的Mach-O文件又怎么去調(diào)用這些系統(tǒng)方法實現(xiàn)呢？
這個問題我們再之后的文章中再做討論。