iOS强化 : 熟悉Mach-O 文件

前言:

关于Mach-O 文件,在iOS App 加载流程知识中已经提到过。看到优秀进行一波儿转载。本文转载https://www.jianshu.com/p/d641e8270108

整体结构大致如下:


Mach-O定义

Mach-O(Mach Object)是macOS、iOS、iPadOS存储程序和库的文件格式。对应系统通过应用二进制接口(application binary interface,缩写为ABI) 来运行该格式的文件。

Mach-O格式用来代替BSD系统的a.out格式Mach-O文件格式保存了在编译过程链接过程中产生的机器代码和数据,从而为静态链接动态链接的代码提供了单一文件格式。

Mach-O = 文件配置 + 二进制文件

除了可执行文件之外,还有一些文件也是Mach-O格式,比如:

  • 目标文件.o
  • 库文件
    .a
    .dylib
    Framework
  • dyld(动态链接器)
  • .dsym(符号表)

由此我们知道,可执行文件只是Mach-O的一种,因此我们将Mach-O文件分为以下几种:

名称 注释
Mach-O Object 目标文件
Mach-O ececutable 可执行文件
Mach-O dynamically 动态库文件
Mach-O dynamic linker 动态链接器文件
Mach-O DSYM companion 符号表文件

通用二进制文件(Universal binary)

支持多架构的Mach-O ececutable(可执行文件)被称为:通用二进制文件,即多种架构都可读取运行。

  • 通用二进制文件具有以下特性:
    1、Apple 提出的一种程序代码,能够同时适配多种架构的二进制文件。
    2、同一个程序包中,同时为多种架构提供最理想的性能。
    3、通用二进制应用程序通常比单一平台二进制程序大,因为需要存储多种代码。
    4、由于多种架构之间有共通的非执行资源,所以并不会比单一架构的两倍大。
    5、程序在执行的时候只调用一部分代码,运行起来不需要额外的内存。

  • 那么多种架构是什么意思呢?下面我们通过file指令来看一下我们的可执行文件:

    image

    通过上图,我们可以看到test可执行文件的类型是Mach-O;架构是x86_64,这是我们用模拟器运行的可执行文件。
    我们再实际开发中遇到的设置arm64&armv7这些都是对应的架构:

    名字 注释
    arm64 真机64位处理器需要arm64架构(iphone6,iphone6p以上的真机)
    armv7s 真机32位处理器 ( ipnone5,iphone5s真机/armv7s)
    armv7 真机32位处理器 (iphone4真机/armv7)
    x86_64 模拟器64位处理器 (iphone6以上的模拟器)
    i386 模拟器32位处理器 (iphone5,iphone5s以下的模拟器)
  • Tips:
    在Xcode中设置ArhitecturesDebug属性设置为NO的时候,会编译支持所有架构的版本,编译的速度会变慢,设置为yes的时候,只编译当前的Arhitectures版本,编译速度快。

    image

通用二进制文件的拆分 与 组合

  • MachOView中,通用二进制文件也被叫做Fat binary
    这种二进制文件是可以拆分、或者重新组合
    ⚠️ 注意这里我采用的是真机测试,Scheme对应的Build Configuration选用Release模式。(关于Xcode环境的配置,有不清楚的同学可以看这里:Xcode 多环境的配置)
    ⚠️ 这里还有一点要注意:测试的时候,如果工程只包含一种架构,此时要手动添加其他架构。

  • 我们可以通过file指令,也可以通过lipo -info指令查看二进制文件支持的架构:

    image
    image

可以看到,目前test可执行程序支持arm64arm_v7两种架构。
那么下面我们先进行文件拆分:

拆分Fat binary
linpo mach-o文件名 -thin 要拆分的架构名 -output 拆分出来的文件名

拆分前的ipa包内容:

image

拆分后的ipa包内容:

image

⚠️ 拆分后源文件并不会发生改变,类似于从源文件中copy出来一个架构单一的二进制文件,注意这里不是单独的分离架构。

image
合并 Fat binary
lipo -create macho_arm64 macho_armv7 -output newTest

合并之后的文件与原文件并无差异,我们可以通过哈希值也看一下:

image

Mach-O 文件结构

  • Mach-O文件主要由 3 部分组成:
名字 注释
Mach Header (Mach-O头) 描述了Mach-OCPU架构、文件类型以及加载命令等信息
Load Commands (加载命令) 描述了文件中数据的具体组织结构,不同的数据类型用不同的加载命令表示
Data (数据区) Data中每一个段 (Segment) 的数据都保存在这里,都拥有一个或多个Section,用来存储数据和代码
image

⚠️ 既然Mach-O是二进制文件,那么它又是怎么知道哪一块内容是Load commands,哪一块又是Header的呢?
其实这里涉及到一个概念叫做结构体对齐,简单的讲就是:按照一定的规则组合到一起,再按照既定的规则拆分就可以了。

Mach Header
image

可以看到Mach Header里面有很多的Description(描述)那么对应的都是什么意思呢?
我们可以在工程中搜索一下,使用快捷键(command + shift + o) 搜索load.h文件,打开该文件,由于是当前是64位的,所以找到:

/*
 * 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_64mach_header(32位的头文件)多了一个保留字段

uint32_t    reserved;   /* reserved */

mach_header是链接器加载的时候最先读取的内容,它决定了一些基础架构,系统类型,指令条数等信息。

Load Commands

Load Commands 详细保存着加载指令的内容,告诉链接器如何去加载当前的Mach-O文件。
那么每一条Load Command对应的又是什么意思呢?
同样的我们也可以在load.h搜索的到,我们以LC_SEGMENT_64为例:

image

下面我们列举一些常见的:

名字 注释
LC_SEGMENT_64 将文件中的段映射到进程地址空间中
LC_DYLD_INFO_ONLY 加载动态链接库信息(重定向地址、弱引用绑定、懒加载绑定、开放函数等的偏移值信息)
LC_SYMTAB 载入符号表地址
LC_DYSYMTAB 载入动态符号表地址
LC_LOAD_DYLINKER 加载动态链接器
LC_UUID 唯一标识,crash解析中也会用到,检查dysm文件和crash文件是否匹配
LC_VERSION_MIN_MACOSX / LC_VERSION_MIN_IPHONEOS 二进制文件支持的最底操作系统版本
LC_SOURCE_VERSION 构建二进制文件使用的源代码版本
LC_MAIN 设置程序主线程的入口地址和栈大小(这也就是为什么我们的程序每次运行都是从main()进来的原因)
LC_ENCRYPTION_INFO_64 获取加密信息
LC_LOAD_DYLIB 加载额外的动态库
LC_FUNCTION_STARTS 函数起始地址表
LC_DATA_IN_CODE 定义在代码段(__text)内的非指令表
LC_CODE_SIGNATURE 应用的签名信息
Data

Data段又分为:__TEXT段 和 __DATA

  • __TEXT
    代码的读取是从__TEXT段开始读取的,其中不同的__TEXT代表的意思如下:
名字 注释
__text 主程序代码
__cstring C 语言字符串
__const const关键字修饰的常量
__stubs 用于Stub的占位代码,很多地方称之为桩代码
__stubs_helper Stub无法找到真正的符号地址后的最终指向
__objc_methname OC 方法名
__objc_methtype OC 方法类型
__objc_classname OC 类名
  • __DATA
    __DATA段在内存中紧跟在__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,存放 未初始化的全局变量,就是常说的静态内存分配
__data 初始化的可变数据

⚠️ 这里有一点大家需要注意,系统库的方法在我们自己的Mach-O文件里面是找不到的,它存放在共享缓存区。那么我们自己的Mach-O文件又怎么去调用这些系统方法实现呢?

你可能感兴趣的:(iOS强化 : 熟悉Mach-O 文件)