转:iOS程序main函数之前发生了什么

原文地址:http://blog.sunnyxx.com/2014/08/30/objc-pre-main/

我是前言

一个iOS app的main()函数位于main.m中,这是我们熟知的程序入口。但对objc了解更多之后发现,程序在进入我们的main函数前已经执行了很多代码,比如熟知的+ load方法等。本文将跟随程序执行顺序,刨根问底,从dyldruntime,看看main函数之前都发生了什么。

从dyld开始

动态链接库

iOS中用到的所有系统framework都是动态链接的,类比成插头和插排,静态链接的代码在编译后的静态链接过程就将插头和插排一个个插好,运行时直接执行二进制文件;而动态链接需要在程序启动时去完成“插插销”的过程,所以在我们写的代码执行前,动态连接器需要完成准备工作。 

这个是在xcode中看到的Link列表:


这些framework将会在动态链接过程中被加载,另外还有隐含link的framework,可以测试出来:先找到可执行文件,我这里叫TestMain的工程,模拟器路径下找到TestMain.app,可执行文件默认同名,再通过otool命令: 

1
$ otool -L TestMain

-L参数打印出所有link的framework(去掉了版本信息): 

1
2
3
4
5
6
7
TestMain:
    /System/Library/Frameworks/CoreGraphics.framework/CoreGraphics 
    /System/Library/Frameworks/UIKit.framework/UIKit
    /System/Library/Frameworks/Foundation.framework/Foundation
    /System/Library/Frameworks/CoreFoundation.framework/CoreFoundation 
    /usr/lib/libobjc.A.dylib 
    /usr/lib/libSystem.dylib

除了多了的CoreGraphics(被UIKit依赖)外,有两个默认添加的lib。libobjc即objc和runtime,libSystem中包含了很多系统级别lib,列几个熟知的:libdispatch(GCD),libsystem_c(C语言库),libsystem_blocks(Block),libcommonCrypto(常用的md5函数)等等。这些lib都是dylib格式(如windows中的dll),系统使用动态链接有几点好处: 

  • 代码共用:很多程序都动态链接了这些lib,但它们在内存和磁盘中中只有一份
  • 易于维护:由于被依赖的lib是程序执行时才link的,所以这些lib很容易做更新,比如libSystem.dyliblibSystem.B.dylib的替身,哪天想升级直接换成libSystem.C.dylib然后再替换替身就行了
  • 减少可执行文件体积:相比静态链接,可执行文件的体积要小很多

dyld

dyld - the dynamic link editor(这缩写对应的很奇怪,我感觉是DYnamic Linker Daemon呢- -?)apple的动态链接器,系统kernel做好启动程序的初始准备后,交给dyld负责,援引并翻译《mikeask这篇blog》对dyld作用顺序的概括:

  1. 从kernel留下的原始调用栈引导和启动自己
  2. 将程序依赖的动态链接库递归加载进内存,当然这里有缓存机制
  3. non-lazy符号立即link到可执行文件,lazy的存表里
  4. Runs static initializers for the executable
  5. 找到可执行文件的main函数,准备参数并调用
  6. 程序执行中负责绑定lazy符号、提供runtime dynamic loading services、提供调试器接口
  7. 程序main函数return后执行static terminator
  8. 某些场景下main函数结束后调libSystem的_exit函数

得益于dyld是开源的,github地址,我们可以从源码一探究竟。

一切源于dyldStartup.s这个文件,其中用汇编实现了名为__dyld_start的方法,汇编太生涩,它主要干了两件事:

  1. 调用dyldbootstrap::start()方法(省去参数)
  2. 上个方法返回了main函数地址,填入参数并调用main函数

这个步骤随手就能验证出来,设置一个符号断点断在_objc_init


这个函数是runtime的初始化函数,后面会提到。程序运行在很早的时候断住,这时候看调用栈:


看到了栈底的dyldbootstrap::start()方法,继而调用了dyld::_main()方法,其中完成了刚才说的递归加载动态库过程,由于libSystem默认引入,栈中出现了libSystem_initializer的初始化方法。

ImageLoader

当然这个image不是图片的意思,它大概表示一个二进制文件(可执行文件或so文件),里面是被编译过的符号、代码等,所以ImageLoader作用是将这些文件加载进内存,且每一个文件对应一个ImageLoader实例来负责加载
两步走:

  1. 在程序运行时它先将动态链接的image递归加载 (也就是上面测试栈中一串的递归调用的时刻)
  2. 再从可执行文件image递归加载所有符号 

当然所有这些都发生在我们真正的main函数执行前。

runtime与+load

刚才讲到libSystem是若干个系统lib的集合,所以它只是一个容器lib而已,而且它也是开源的,里面实质上就一个文件,init.c,细节不说了,由libSystem_initializer逐步调用到了_objc_init,这里就是objc和runtime的初始化入口。

除了runtime环境的初始化外,_objc_init中绑定了新image被加载后的callback:

1
2
3
dyld_register_image_state_change_handler(dyld_image_state_bound,1/*batch*/,&map_images);
dyld_register_image_state_change_handler(dyld_image_state_dependents_initialized,0/*not batch*/,&load_images);

可见dyld担当了runtimeImageLoader中间的协调者,当新image加载进来后交由runtime大厨去解析这个二进制文件的符号表和代码。继续上面的断点法,断住神秘的+load函数:

清楚的看到整个调用栈和顺序:

  1. dyld开始将程序二进制文件初始化
  2. 交由ImageLoader读取image,其中包含了我们的类、方法等各种符号
  3. 由于runtime向dyld绑定了回调,当image加载到内存后,dyld会通知runtime进行处理
  4. runtime接手后调用map_images做解析和处理,接下来load_images中调用call_load_methods方法,遍历所有加载进来的Class,按继承层级依次调用Class的load方法和其Category的load方法

至此,可执行文件中和动态库所有的符号(Class,Protocol,Selector,IMP,…)都已经按格式成功加载到内存中,被runtime所管理,再这之后,runtime的那些方法(动态添加Class、方法混合等等才能生效)

关于load方法的几个QA

Q: 重载自己Class的load方法时需不需要调父类?
A: runtime负责按继承顺序递归调用,所以我们不能调super

Q: 在自己Class的load方法时能不能替换系统framework(比如UIKit)中的某个类的方法实现
A: 可以,因为动态链接过程中,所有依赖库的类是先于自己的类加载的

Q: 重载load时需要手动添加@autoreleasepool么?
A: 不需要,在runtime调用load方法前后是加了objc_autoreleasePoolPush()objc_autoreleasePoolPop()的。

Q: 想让一个类的load方法被调用是否需要在某个地方import这个文件
A: 不需要,只要这个类的符号被编译到最后的可执行文件中,load方法就会被调用(Reveal SDK就是利用这一点,只要引入到工程中就能工作)

简单总结

整个事件由dyld主导,完成运行环境的初始化后,配合ImageLoader将二进制文件按格式加载到内存,
动态链接依赖库,并由runtime负责加载成objc定义的结构,所有初始化工作结束后,dyld调用真正的main函数。
值得说明的是,这个过程远比写出来的要复杂,这里只提到了runtime这个分支,还有像GCDXPC等重头的系统库初始化分支没有提及(当然,有缓存机制在,它们也不会玩命初始化),总结起来就是main函数执行之前,系统做了茫茫多的加载和初始化工作,但都被很好的隐藏了,我们无需关心。

孤独的main函数

当这一切都结束时,dyld会清理现场,将调用栈回归,只剩下:


孤独的main函数,看上去是程序的开始,确是一段精彩的终结

References

https://www.mikeash.com/pyblog/friday-qa-2012-11-09-dyld-dynamic-linking-on-os-x.html
http://newosxbook.com/articles/DYLD.html
http://docstore.mik.ua/orelly/unix3/mac/ch05_02.htm
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/dyld.1.html

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


当我们远离最新的 iOS 16 更新版本时,我们听到了困扰 Apple 最新软件的错误和性能问题。
欧版/美版 特别说一下,美版选错了 可能会永久丧失4G,不过只有5%的概率会遇到选择运营商界面且部分必须连接到iTunes才可以激活
一般在接外包的时候, 通常第三方需要安装你的app进行测试(这时候你的app肯定是还没传到app store之前)。
前言为了让更多的人永远记住12月13日,各大厂都在这一天将应用变灰了。那么接下来我们看一下Flutter是如何实现的。Flutter中实现整个App变为灰色在Flutter中实现整个App变为灰色是非常简单的,只需要在最外层的控件上包裹ColorFiltered,用法如下:ColorFiltered(颜色过滤器)看名字就知道是增加颜色滤镜效果的,ColorFiltered( colorFilter:ColorFilter.mode(Colors.grey, BlendMode.
flutter升级/版本切换
(1)在C++11标准时,open函数的文件路径可以传char指针也可以传string指针,而在C++98标准,open函数的文件路径只能传char指针;(2)open函数的第二个参数是打开文件的模式,从函数定义可以看出,如果调用open函数时省略mode模式参数,则默认按照可读可写(ios_base:in | ios_base::out)的方式打开;(3)打开文件时的mode的模式是从内存的角度来定义的,比如:in表示可读,就是从文件读数据往内存读写;out表示可写,就是把内存数据写到文件中;
文章目录方法一:分别将图片和文字置灰UIImage转成灰度图UIColor转成灰度颜色方法二:给App整体添加灰色滤镜参考App页面置灰,本质是将彩色图像转换为灰度图像,本文提供两种方法实现,一种是App整体置灰,一种是单个页面置灰,可结合具体的业务场景使用。方法一:分别将图片和文字置灰一般情况下,App页面的颜色深度是24bit,也就是RGB各8bit;如果算上Alpha通道的话就是32bit,RGBA(或者ARGB)各8bit。灰度图像的颜色深度是8bit,这8bit表示的颜色不是彩色,而是256
领导让调研下黑(灰)白化实现方案,自己调研了两天,根据网上资料,做下记录只是学习过程中的记录,还是写作者牛逼
让学前端不再害怕英语单词(二),通过本文,可以对css,js和es6的单词进行了在逻辑上和联想上的记忆,让初学者更快的上手前端代码
用Python送你一颗跳动的爱心
在uni-app项目中实现人脸识别,既使用uni-app中的live-pusher开启摄像头,创建直播推流。通过快照截取和压缩图片,以base64格式发往后端。
商户APP调用微信提供的SDK调用微信支付模块,商户APP会跳转到微信中完成支付,支付完后跳回到商户APP内,最后展示支付结果。CSDN前端领域优质创作者,资深前端开发工程师,专注前端开发,在CSDN总结工作中遇到的问题或者问题解决方法以及对新技术的分享,欢迎咨询交流,共同学习。),验证通过打开选择支付方式弹窗页面,选择微信支付或者支付宝支付;4.可取消支付,放弃支付会返回会员页面,页面提示支付取消;2.判断支付方式,如果是1,则是微信支付方式。1.判断是否在微信内支付,需要在微信外支付。
Mac命令行修改ipa并重新签名打包
首先在 iOS 设备中打开开发者模式。位于:设置 - 隐私&安全 - 开发者模式(需重启)
一 现象导入MBProgressHUD显示信息时,出现如下异常现象Undefined symbols for architecture x86_64: "_OBJC_CLASS_$_MBProgressHUD", referenced from: objc-class-ref in ViewController.old: symbol(s) not found for architecture x86_64clang: error: linker command failed wit
Profiles >> 加号添加 >> Distribution >> "App Store" >> 选择 2.1 创建的App ID >> 选择绑定 2.3 的发布证书(.cer)>> 输入描述文件名称 >> Generate 生成描述文件 >> Download。Certificates >> 加号添加 >> "App Store and Ad Hoc" >> “Choose File...” >> 选择上一步生成的证书请求文件 >> Continue >> Download。
今天有需求,要实现的功能大致如下:在安卓和ios端实现分享功能可以分享链接,图片,文字,视频,文件,等欢迎大佬多多来给萌新指正,欢迎大家来共同探讨。如果各位看官觉得文章有点点帮助,跪求各位给点个“一键三连”,谢啦~声明:本博文章若非特殊注明皆为原创原文链接。