• 1

  • 360

OC底层-应用程序加载初探

黑猫

我不是黑客

4天前

写在开始

应用程序加载,是我们每天都要面对的一个课题。每年的WWDC都会关于应用程序的启动时间做出一些优秀的改进更新说明。具体在程序的底层,应用程序的加载做了哪些工作,我们去一探究竟。

一、准备工作

动态库和静态库

  • 库:是已写好的、供使用的 可复用代码,每个程序都要依赖很多基础的底层库。从本质上,库是一种可执行代码的二进制形式。可以被操作系统载入内存执行。库分为两种:静态库(.a .lib)和 动态库 (framework .so .dll)。所谓的静态、动态指的是 链接的过程。
  • 静态库:在链接阶段,会将汇编生成的目标文件.o 与 引用的库一起链接到可执行文件中。对应的链接方式称为 静态链接。
    • 静态库对函数库的链接是在编译期完成的。执行期间代码装载速度快。
    • 使可执行文件变大,浪费空间和资源(占空间)。
    • 对程序的更新、部署与发布不方便,需要全量更新。如果 某一个静态库更新了,所有使用它的应用程序都需要重新编译、发布给用户。
  • 动态库:在程序编译时并不会链接到目标代码中,而是在运行时才被载入。不同的应用程序如果调用相同的库,那么在内存中只需要有一份该共享库的实例,避免了空间浪费问题。同时也解决了静态库对程序的更新的依赖,用户只需更新动态库即可。动态库在内存中只存在一份拷贝,如果某一进程需要用到动态库,只需在运行时动态载入即可。
    • 动态库把对一些库函数的链接载入推迟到程序运行时期(占时间)。
    • 可以实现进程之间的资源共享。(因此动态库也称为共享库)
    • 将一些程序升级变得简单,不需要重新编译,属于增量更新。

Mach-O

  • Mach-O:为 Mach Object 文件格式的缩写,是 iOS 系统不同运行时期可执行文件的文件类型统称。它是一种用于可执行文件、目标代码、动态库、内核转储的文件格式。简单的可以分为三个部分,Header,Load Commands,Segment Data。
    • Header中包含的是可执行文件的CPU架构,Load Commands的数量和占用空间。
    • Load Commands中包含的是Segment的Header与内存分布,以及依赖动态库的版本和Path等
    • Segment Data就是Segment汇编代码的实现,每段Segment的内存占用大小都是分页页数的整数倍。

dyld

  • dyld:the dynamic link editor[动态链接器]是苹果操作系统一个重要部分,在 iOS / macOS 系统中,仅有很少的进程只需内核就可以完成加载,基本上所有的进程都是动态链接的,所以 Mach-O 镜像文件中会有很多对外部的库和符号的引用,但是这些引用并不能直接用,在启动时还必须要通过这些引用进行内容填充,这个填充的工作就是由 dyld 来完成的。
  • dyld源码链接

dyld2 和 dyld3

  • dyld2:ios13之前使用。主要流程为
    • 解析 Mach-O的Header 和 Load Commands,找到其依赖的库,并递归找到所有依赖的库
    • 加载Mach-O文件
    • 进行符号查找
    • 绑定和变基
    • 运行初始化程序
  • dyld3:ios13之后使用,把很多耗时的查找、计算和I/O 的事件都预先处理好,使得启动速度有了很大的提升。dyld3包含了3个组件来完成dyld的工作
    • 作为一个进程外的Mach-O 解析器:先处理了所有可能影响启动速度的search path、@rpaths 和环境变量 然后分析Mach-O的Header和依赖,并完成了所有符号查找的工作 最后将这些结果创建成一个启动闭包 这是一个普通的daemon进程,可以使用通常的测试架构
    • 作为一个进程内的引擎:用来运行启动闭包 这部分在进程中处理 验证启动闭包的安全性,然后映射到dylib之中,再跳转到main函数 不需要解析Mach-O的 Header 和依赖,也不需要符号查找。
    • 作为一个启动闭包缓存服务:系统App的启动闭包被构建在一个Shared Cache [共享缓存]中,我们甚至不需要打开一个单独的文件对于第三方的App,我们会在App安装或者升级的时候构建这个启动闭包。在iOS、tvOS、watchOS中,这一切都是App启动之前完成的。在macOS上,由于有Side Load App,进程内引擎会在首次启动的时候启动一个daemon进程,之后就可以使用启动闭包启动了。

二、APP加载流程

load方法引入

在viewController中重写load方法,查看对应执行的堆栈信息

_dyld_start

打开下载好的dyld源码,搜索_dyld_start如下

dyldbootstrap::start

搜索dyldbootstrap如下

dyld::_main

command进入实现方法,发现dyld::_main有很多行代码,这里分享一个分析源码的小思路:

  • 我们先将带有{}的代码折叠为代码块,看主线流程
  • 主线流程理的差不多,再展开分析细节
  • 注意看英文注释抓关键点

通过分析我们看到dyld::_main为我们做了以下事情

1、环境变量配置,根据环境变量设置相应的值以及获取当前运行架构

2、共享缓存,检查是否开启了共享缓存,以及共享缓存是否映射到共享区域!

3、实例化主程序

4、插入动态库

5、link 主程序

6、link 动态库

7、弱符号绑定

8、执行初始化方法

8.1、initializeMainExecutable方法

8.2、ImageLoader::runInitializers

8.3、ImageLoader::processInitializers

8.4、ImageLoader::recursiveInitialization

8.5、sNotifyObjCInit

  • 全局搜索sNotifyObjCInit

  • 发现没有实现,只有赋值操作

  • 继续搜索registerObjCNotifiers

  • 追寻_dyld_objc_notify_register,在dyld中_dyld_objc_notify_register已经是尽头了,_dyld_objc_notify_register的实现是在 libobjc源码中

  • _dyld_objc_notify_register 追踪,_objc_init源码中调用了该方法,并传入了参数load_images,所以sNotifyObjCInit的赋值的就是objc中的load_images,而load_images会调用所有的+load方法。所以综上所述,notifySingle是一个回调函数

  • 进入load_images的源码实现,调用了call_load_methods

  • call_load_methods 可以看到调用了load方法。

  • 至此印证了load在程序启动的堆栈信息。这里留下疑问_objc_init的调用时机。

8.6、doInitialization

  • dyld追踪doInitialization实现
  • doImageInit,遍历加载所有镜像文件
  • doModInitFunctions,加载所有的cxx方法

8.7、_objc_init的调用时机

  • 添加符号断点_objc_init,查看堆栈信息

  • 在libsystem中查找libSystem_initializer

  • 在libdispatch中查找libdispatch_init

  • 进入_os_object_init,至此找到_objc_init的调用时机,

9、寻找主程序入口即main函数

这里在开头的汇编源码里也有说明对照。

10、dyld 和 libobjc 关联

关键先生:sNotifyObjCInit,当程序准备好初始化的时候会递归去初始化已经加载的镜像文件recursiveInitialization,我在这里理解为程序添加sNotifyObjCInit的通知,然后执行 doInitialization,初始化则会执行 ->libSystem_initializer -> libdispatch_init -> _os_object_init -> _objc_init。而_objc_init 执行则会发送_dyld_objc_notify_register的通知,_dyld_objc_notify_register会传递已经加载好的 map_images、load_image、unmap_image回调给sNotifyObjCInit。至此形成闭环关联。

三、写在结束

  • dyld的源码总体来说,还是比较晦涩的。所以这次写的比较详细,贴图也给到位。方便自己后边回头来看。
    • 研究源码的时候重要的是方法,前面我也简单提到了自己的一些小方法。
    • 不要半途而废,遇到get不到的点,多查资料,前面已经有很多巨人,我们可以站在巨人的肩膀上继续前行
    • 眼见为真,只有自己理解到了,并且程序真的调试到了,才能算是探究,切勿人云亦云。
  • 这里后期会补充下流程图。
免责声明:文章版权归原作者所有,其内容与观点不代表Unitimes立场,亦不构成任何投资意见或建议。

信息安全

360

相关文章推荐

未登录头像

暂无评论