从Mach-O到iOS Library

做过iOS的Library开发的都知道,开发者可以创建静态库工程(Static Library),编译出来的产物是.a文件;也可以创建动态库工程(Dynamic Library),编译出来的产物是.framework文件。然而,你也有可能遇到过,外面是.framework文件,里面包含的却是.a的文件,还有的二进制文件根本没有格式后缀。但是系统的动态库文件却是.dylib(xcode 8.0以前)和.tbd(xcode 8.0及以后)格式的。刚开始接触时肯定对这些充满了疑惑,本文将对这些问题进行一些探讨。

在进行探讨之前,首先要介绍一下Mach-O。

Mach-O

Mach-O格式全称为Mach Object文件格式的缩写,是mac上可执行文件的格式,类似于windows上的PE格式 (Portable Executable ), linux上的elf格式 (Executable and Linking Format)。

mach-o文件类型分为:
  • Executable:应用的主要二进制
  • Dylib Library:动态链接库(又称DSO或DLL)
  • Static Library:静态链接库
  • Bundle:不能被链接的Dylib,只能在运行时使用dlopen( )加载,可当做macOS的插件
  • Relocatable Object File:可重定向文件类型
    看着貌似很陌生,我们可以类比着相对熟悉一点的Linux看。Linux中常见的库文件有.o文件、.a文件、.so文件。
    以一个简单的add函数源文件为例,介绍一下编译过程。
int add(int a,int b)
{
    return a+b;
}

先预处理为.i文件gcc -E add.c -o add.i
再编译为汇编文件
gcc -S add.i -o add.s
再汇编为二进制的.o文件
gcc -c add.s -o add.o
现在.o文件出来了。它就是C/C++编译的产物,因为C/C++编译的单元编译。每一个.c/.cpp文件就是一个编译单元,把所有单元都编译好之后,再连接成一个完整的程序。所以可以看出:

  • .o文件
    .o文件是源码编译出的二进制文件。
  • .a文件
    .a文件实质上就是.o文件打了个包。一般把它叫做静态库文件。它在使用的时候,效果和使用.o文件是一样的。
  • .so文件
    .so文件就不一样了,它不是简单的.o文件打了一个包,它是一个ELF格式的文件,也就是linux的可执行文件。.so文件可以用于多个进程的共享使用(位置无关的才行),所以又叫共享库文件。程序在使用它的时候,会在运行时把它映射到自己进程空间的某一处,其不在使用它的程序中。

OSX或者iOS是类Unix系统,和Linux很相似。文件格式也很类似,其中Relocatable Object File和.o文件类型对应;Static Library和.a文件类型对应;Dylib Library和.so文件类型对应。

iOS Library

在任意一个iOS工程中,可以进入到Build Settings,搜索"Mach-O",可以搜出"Mach-O Type"配置项,在下拉菜单里可以看到有5个选项,如图所示:
从Mach-O到iOS Library_第1张图片
编译产物类型配置项

可以看到,正好和前面的几种Mach-O文件类型对应。其中Executable用于编译应用,Bundle用于编译资源包,Relocatable Object File用于编译单元二进制文件。Static Library和Dynamic Library分别用于编译静态和动态库。Executable、Bundle以及Relocatable Object File比较好区分,这里主要探讨Static Library和Dynamic Library。

前面提到过,静态库一般是.a文件,动态库一般是.framework文件。为什么说一般,因为静态库也可能没有后缀;.framework文件其实只是个文件夹,真正的二进制文件在.framework里面。.framework里面的二进制文件也可能是静态库,也有可能是动态库。有后缀也可能没有后缀。因此有时候不通过工具很难区分。所以这里推荐一款Mach-O格式文件浏览器:MachOView。

MachOView下载地址:http://sourceforge.net/projects/machoview/
MachOView源码地址:https://github.com/gdbinit/MachOView

用MachOView打开Mach-O格式文件,可以清楚地看到文件类型,是动态库还是静态库。如果是动态库,可以看到Shared Library标志;如果是静态库,可以看到Static Library标志。

动态库(这里只讲自己编译的动态库,因为系统的动态库还有些不一样,后面会讲到)和静态库的主要区别有以下几点:

  • 在使用静态库时,把库拖进工程,设置好library search path即可使用;在使用动态库时,多一个步骤,要在Build Settings——>General——>Embeeded Binaries中add一下,否则应用启动时会崩溃。
  • 静态库里不能有资源文件;动态库有.framework文件夹包裹着,可以带资源文件。
  • 静态库会被编译进应用的二进制文件里;动态库只是被完整地拷贝到应用的沙盒里,不会被编译进应用的二进制文件里。
  • 静态库实质上就是源码编译出的多个.o二进制文件打了个包;动态库可以用于多个进程的共享使用(位置无关的才行),所以又叫共享库文件。程序在使用它的时候,会在运行时把它映射到自己进程空间的某一处,其不在使用它的程序中。
  • 在应用启动时,系统会把应用所链接的所有静态库(包括系统的和自己编译的)全部放进分配好的内存空间里,如果一次性加载的内容过多,会造成App启动慢;动态库分两种情况,如果是自己编译的,则会被通过load的方式全部加载进内存;如果是系统的动态库则相对智能些,只有当应用用到这个库时,系统才把这个库加载进内存。

现在对静态库应该没有什么疑问了,很容易区分。但是自己编译的动态库和系统的动态库还不是很清晰。有人把自己编译的动态库归类静态库,可能有两点理由:1、自己编译的动态库用法和静态库很类似,而且不能动态加载;2、自己编译的动态库是.framework文件,而系统的动态库是.tbd文件,格式都不一样。

目前,自己编译的动态库用法和静态库用法确实很类似,而且不能动态加载。但是不能动态加载的原因是系统的限制。查看苹果的API文档,会发现有一个方法提供了加载可执行文件的功能,那就是NSBundle的load方法(底层实现为dlopen函数), 如下所示:

从Mach-O到iOS Library_第2张图片
加载可执行文件方法
详见官方文档: https://developer.apple.com/documentation/foundation/nsbundle/1415927-load?language=objc
然而,这个方法的使用是有前提的。那就是库和app的签名必需一致。iOS可能是出于安全考虑,在加载可执行代码前,需要校验签名。load方法的内部实现是调用了dlopen,而dlopen内部还会调用dlopen_preflight先校验签名。如果库不是事先打包进app,和app使用同一签名,就会报签名错误,从而加载不成功。如下图所示:
从Mach-O到iOS Library_第3张图片
加载framework代码
从Mach-O到iOS Library_第4张图片
加载失败信息

那么肯定有人会问,既然无法加载成功,苹果为什么要提供这个方法?答案是,虽然iOS无法使用,但是Mac OS可以使用,很明显这个方法目前是提供给Mac OS使用的。如果以后系统放开签名校验,那么iOS中也就可以动态加载了。

至于系统的动态库是.tbd文件,不妨先调查一下这个.tbd。详见:http://www.cocoachina.com/ios/20160506/16141.html
简而言之,其实tbd文件不是一个库,而是一个文本文件,其中包含架构信息,和在真实运行时候二进制所在的位置,以及动态库的符号表还有类的一些信息,这些信息在编译阶段足够了。在系统要使用时才通过tbd文件中的链接信息加载真正的二进制文件。

总结

  • Mach-O格式的几种文件和iOS工程Build Settings里面的配置项是对应的。
  • 可以通过MachOView工具查看Mach-O格式,不能只看文件后缀。
  • iOS工程Build Settings里面的配置项选择Static Library和Dynamic Library分别编译出的二进制文件还是有本质区别的。
  • 系统动态库和自己编译的动态库本质上是一样的,只是使用方式不一样。自己编译的动态库由于签名校验限制,只能当作静态库一样使用;系统的动态库不受签名校验限制,可以动态加载。

参考链接:
http://blog.csdn.net/zhangjie1989/article/details/54614246
https://www.jianshu.com/p/54d842db3f69
http://www.cocoachina.com/ios/20160506/16141.html

你可能感兴趣的:(从Mach-O到iOS Library)