方法执行顺序
我们在main函数中加了一个C++方法和一个普通的打印方法，在ViewController中重写了load方法，思考5秒钟，请问它们的打印先后顺序是什么？
// 内存 main() dyld image init 注册回调通知 - dyld_start -> dyld::main() -> main()
// rax
int main(int argc, char * argv[]) {
NSString * appDelegateClassName;
NSLog(@"23333");
@autoreleasepool {
// Setup code that might create autoreleased objects goes here.
appDelegateClassName = NSStringFromClass([AppDelegate class]);
}
return UIApplicationMain(argc, argv, nil, appDelegateClassName);
}
// load -> Cxx -> main
__attribute__((constructor)) void zgFunc(){
printf("来了 : %s \n",__func__);
}
+ load方法
@interface ViewController ()
@end
@implementation ViewController
+ (void)load{
NSLog(@"%s",__func__);
}
- (void)viewDidLoad {
[super viewDidLoad];
// Do any additional setup after loading the view.
}
5,4,3,2,1...
运行程序，查看load、zgFunc、main的打印顺序，下面是打印结果，通过结果可以看出其顺序是load --> C++方法 --> main，我们都知道main函数是程序的入口函数，那么为什么不是main先打印呢？原来在main函数之前，苹果还做了大量的工作，其中dyld就是其中重要的一环。
什么是dyld?
dyld 是the dynamic link editor的简写，翻译过来就是动态链接器，是苹果操作系统的一个重要的组成部分。在iOS/Mac OSX 系统中，仅有很少量的进程只需要内核就能完成加载，基本上所有的进程都是动态链接的，所以Mach-O镜像文件中会有很多对外部的库和符号的引用，但是这些引用并不能直接用，在启动时还必须要通过这些引用进行内容的填补，这个填补工作就是由 动态链接器dyld来完成的，也就是符号绑定。
动态链接器dyld在系统中以一个用户态的可执行文件形式存在，一般应用程序会在Mach-O 文件部分指定一个LC_LOAD_DYLINKER 的加载命令，此加载命令指定了dyld 的路径，通常它的默认值是/usr/lib/dyld 。系统内核在加载Mach-O 文件时，都需要用dyld（位于 /usr/lib/dyld ）程序进行链接。
dyld是开源的，感兴趣可以下载查阅。dyld源码下载
代码编译过程
在分析app启动之前，我们需要先了解app代码的编译过程以及动态库和静态库。
其中编译过程如下图所示，主要分为以下几步：
源文件：载入.h、.m、.cpp等文件
预处理：替换宏，删除注释，展开头文件，产生.i文件
编译：将.i文件转换为汇编语言，产生.s文件
汇编：将汇编文件转换为机器码文件，产生.o文件
链接：对.o文件中引用其他库的地方进行引用，生成最后的可执行文件
静态库可以看成是一堆对象文件(object files)的归档。当链接这样一个库到应用中时，静态链接器static linker将会从库中收集这些对象文件并把它们和应用的对象代码一起打包到一个单独的二进制文件中。这意味着应用的可执行文件大小将会随着库的数目增加而增长`。另外，当应用启动时，应用的代码（包含库的代码）将会一次性地导入到程序的地址空间中去。
动态库是可以被多个 app的进程共用的，所以在内存中只会存在一份；如果是静态库，由于每个 app的 Mach-O 文件中都会存在一份，则会存在多份。相对静态库，使用动态库可以减少 app 占用的内存大小。动态库不能直接运行，而是需要通过系统的动态链接加载器dyld 进行加载到内存后执行。
dyld加载流程
我们在ViewController的load方法处加一个断点，通过bt打印堆栈信息查看app启动是从哪里开始的
我们可以看到dyld是从_dyld_start方法开始的，所以我们去dyld的源码中一探究竟。
我们在源码中搜索_dyld_start。在 dyldStartup.s 文件中找到了入口，这里是用汇编实现的，尽管在不同架构下有所区别，但都是会调用 dyldbootstrap 命名空间下的start方法，这和上面的堆栈顺序也是相同的，这里我们以arm64架构为例
这里的
call相当于bl跳转指令的作用
dyldbootstrap::start
dyldbootstrap::start就是指 dyldbootstrap 这个命名空间作用域里的 start函数。
来到源码中 , 搜索dyldbootstrap , 然后找到 start函数。
uintptr_t start(const dyld3::MachOLoaded* appsMachHeader, int argc, const char* argv[],
const dyld3::MachOLoaded* dyldsMachHeader, uintptr_t* startGlue)
{
...省略一些代码
// now that we are done bootstrapping dyld, call dyld's main
uintptr_t appsSlide = appsMachHeader->getSlide();
return dyld::_main((macho_header*)appsMachHeader, appsSlide, argc, argv, envp, apple, startGlue);
}
可以看到其核心是返回值的调用了dyld的main函数
dyld::_main
main函数洋洋洒洒写了600多行...，这里简单的罗列一下其中都做了什么
uintptr_t
_main(const macho_header* mainExecutableMH, uintptr_t mainExecutableSlide,
int argc, const char* argv[], const char* envp[], const char* apple[],
uintptr_t* startGlue)
{
......省略部分代码
// 设置运行环境，可执行文件准备工作
......省略部分代码
// load shared cache 加载共享缓存
mapSharedCache();
......省略部分代码
reloadAllImages:
......省略部分代码
// instantiate ImageLoader for main executable 加载可执行文件并生成一个ImageLoader实例对象
sMainExecutable = instantiateFromLoadedImage(mainExecutableMH, mainExecutableSlide, sExecPath);
......省略部分代码
// load any inserted libraries 加载插入的动态库
if ( sEnv.DYLD_INSERT_LIBRARIES != NULL ) {
for (const char* const* lib = sEnv.DYLD_INSERT_LIBRARIES; *lib != NULL; ++lib)
loadInsertedDylib(*lib);
}
// link main executable 链接主程序
link(sMainExecutable, sEnv.DYLD_BIND_AT_LAUNCH, true, ImageLoader::RPathChain(NULL, NULL), -1);
......省略部分代码
// link any inserted libraries 链接所有插入的动态库
if ( sInsertedDylibCount > 0 ) {
for(unsigned int i=0; i < sInsertedDylibCount; ++i) {
ImageLoader* image = sAllImages[i+1];
link(image, sEnv.DYLD_BIND_AT_LAUNCH, true, ImageLoader::RPathChain(NULL, NULL), -1);
image->setNeverUnloadRecursive();
}
if ( gLinkContext.allowInterposing ) {
// only INSERTED libraries can interpose
// register interposing info after all inserted libraries are bound so chaining works
for(unsigned int i=0; i < sInsertedDylibCount; ++i) {
ImageLoader* image = sAllImages[i+1];
// 注册符号插入
image->registerInterposing(gLinkContext);
}
}
}
......省略部分代码
//弱符号绑定
sMainExecutable->weakBind(gLinkContext);
sMainExecutable->recursiveMakeDataReadOnly(gLinkContext);
......省略部分代码
// run all initializers 执行初始化方法
initializeMainExecutable();
// notify any montoring proccesses that this process is about to enter main()
notifyMonitoringDyldMain();
return result;
}
总结：
第一步： 设置运行环境，为可执行文件的加载做准备工作
第二步： 映射共享缓存到当前进程的逻辑内存空间
第三步： 实例化主程序
第四步： 加载插入的动态库
第五步： 链接主程序
第六步： 链接插入的动态库
第七步： 执行弱符号绑定（weakBind）
第八步： 执行初始化方法;
第九步： 查找程序入口并返回main( )
我们观察LLDB 调试堆栈结果， 发现dyld::_main函数之后走的是 dyld::initializeMainExecutable函数，那么是怎么调到这一步的呢？
我们发现是sMainExecutable->instantiateFromLoadedImage-> instantiateFromLoadedImage，这样一步步调的。
instantiateFromLoadedImage
static ImageLoaderMachO* instantiateFromLoadedImage(const macho_header* mh, uintptr_t slide, const char* path)
{
// try mach-o loader
if ( isCompatibleMachO((const uint8_t*)mh, path) ) {
ImageLoader* image = ImageLoaderMachO::instantiateMainExecutable(mh, slide, path, gLinkContext);
addImage(image);
return (ImageLoaderMachO*)image;
}
throw "main executable not a known format";
}
这里通过instantiateMainExecutable方法创建创建一个ImageLoader实例对象，isCompatibleMachO 是检查Mach-O的subtype是否是当前cpu可以支持，内核会映射到主可执行文件中，我们需要为映射到主可执行文件的文件，创建ImageLoader。
这个函数的主要目的：dyld 获得控制权之前，内核会映射到可执行文件，这一步正是创建了可执行文件的映射ImageLoader， 返回给我们的主程序 sMainExecutable， 加在了我们的镜像 image 里面。
instantiateMainExecutable
ImageLoader* ImageLoaderMachO::instantiateMainExecutable(const macho_header* mh, uintptr_t slide, const char* path, const LinkContext& context)
{
//dyld::log("ImageLoader=%ld, ImageLoaderMachO=%ld, ImageLoaderMachOClassic=%ld, ImageLoaderMachOCompressed=%ld\n",
// sizeof(ImageLoader), sizeof(ImageLoaderMachO), sizeof(ImageLoaderMachOClassic), sizeof(ImageLoaderMachOCompressed));
bool compressed;
unsigned int segCount;
unsigned int libCount;
const linkedit_data_command* codeSigCmd;
const encryption_info_command* encryptCmd;
sniffLoadCommands(mh, path, false, &compressed, &segCount, &libCount, context, &codeSigCmd, &encryptCmd);
// instantiate concrete class based on content of load commands
if ( compressed )
return ImageLoaderMachOCompressed::instantiateMainExecutable(mh, slide, path, segCount, libCount, context);
else
#if SUPPORT_CLASSIC_MACHO
return ImageLoaderMachOClassic::instantiateMainExecutable(mh, slide, path, segCount, libCount, context);
#else
throw "missing LC_DYLD_INFO load command";
#endif
}
这里代码主要是为Mach-O创建映像，返回一个ImageLoader类型的image对象，即主程序。其中sniffLoadCommands函数时获取Mach-O类型文件的Load Command的相关信息，并对其进行各种校验。
sniffLoadCommands
// determine if this mach-o file has classic or compressed LINKEDIT and number of segments it has
void ImageLoaderMachO::sniffLoadCommands(const macho_header* mh, const char* path, bool inCache, bool* compressed,
unsigned int* segCount, unsigned int* libCount, const LinkContext& context,
const linkedit_data_command** codeSigCmd,
const encryption_info_command** encryptCmd)
{
*compressed = false;
*segCount = 0;
*libCount = 0;
*codeSigCmd = NULL;
*encryptCmd = NULL;
......省略部分代码
switch (cmd->cmd) {
case LC_DYLD_INFO:
case LC_DYLD_INFO_ONLY:
case LC_LOAD_DYLIB:
case LC_LOAD_WEAK_DYLIB:
case LC_REEXPORT_DYLIB:
case LC_LOAD_UPWARD_DYLIB
......省略部分代码
}
这个函数就是根据 Load Commands 来加载主程序 .
compressed -> 根据LC_DYLD_INFO_ONYL来决定 。
segCount 段命令数量 , 最大不能超过 255 个。
libCount依赖库数量 ,LC_LOAD_DYLIB (Foundation / UIKit ..), 最大不能超过 4095 个。
codeSigCmd , 应用签名 。
encryptCmd , 应用加密信息 , ( 我们俗称的应用加壳 , 我们非越狱环境重签名都是需要砸过壳的应用才能调试) 。
接下来我们通过LLDB打印的堆栈信息可以看到，下面会调用ImageLoader::runInitializers方法。这里是在dyld::_main函数的第八步初始化方法，进入initializeMainExecutable源码
initializeMainExecutable
void initializeMainExecutable()
{
// record that we've reached this step
gLinkContext.startedInitializingMainExecutable = true;
// run initialzers for any inserted dylibs
ImageLoader::InitializerTimingList initializerTimes[allImagesCount()];
initializerTimes[0].count = 0;
const size_t rootCount = sImageRoots.size();
if ( rootCount > 1 ) {
for(size_t i=1; i < rootCount; ++i) {
sImageRoots[i]->runInitializers(gLinkContext, initializerTimes[0]);
}
}
// run initializers for main executable and everything it brings up
sMainExecutable->runInitializers(gLinkContext, initializerTimes[0]);
// register cxa_atexit() handler to run static terminators in all loaded images when this process exits
if ( gLibSystemHelpers != NULL )
(*gLibSystemHelpers->cxa_atexit)(&runAllStaticTerminators, NULL, NULL);
// dump info if requested
if ( sEnv.DYLD_PRINT_STATISTICS )
ImageLoader::printStatistics((unsigned int)allImagesCount(), initializerTimes[0]);
if ( sEnv.DYLD_PRINT_STATISTICS_DETAILS )
ImageLoaderMachO::printStatisticsDetails((unsigned int)allImagesCount(), initializerTimes[0]);
}
主要是循环遍历，都会执行runInitializers方法
runInitializers
void ImageLoader::runInitializers(const LinkContext& context, InitializerTimingList& timingInfo)
{
uint64_t t1 = mach_absolute_time();
mach_port_t thisThread = mach_thread_self();
ImageLoader::UninitedUpwards up;
up.count = 1;
up.imagesAndPaths[0] = { this, this->getPath() };
processInitializers(context, thisThread, timingInfo, up);
context.notifyBatch(dyld_image_state_initialized, false);
mach_port_deallocate(mach_task_self(), thisThread);
uint64_t t2 = mach_absolute_time();
fgTotalInitTime += (t2 - t1);
}
根据 LLDB调试堆栈结果。我们知道接下来我们要进processInitializers函数
processInitializers
void ImageLoader::processInitializers(const LinkContext& context, mach_port_t thisThread,
InitializerTimingList& timingInfo, ImageLoader::UninitedUpwards& images)
{
uint32_t maxImageCount = context.imageCount()+2;
ImageLoader::UninitedUpwards upsBuffer[maxImageCount];
ImageLoader::UninitedUpwards& ups = upsBuffer[0];
ups.count = 0;
// Calling recursive init on all images in images list, building a new list of
// uninitialized upward dependencies.
for (uintptr_t i=0; i < images.count; ++i) {
images.imagesAndPaths[i].first->recursiveInitialization(context, thisThread, images.imagesAndPaths[i].second, timingInfo, ups);
}
// If any upward dependencies remain, init them.
if ( ups.count > 0 )
processInitializers(context, thisThread, timingInfo, ups);
}
同样的根据LLDB 调试堆栈结果。我们知道接下来我们要进recursiveInitialization函数，发现点不进去recursiveInitialization，我们就全局搜索recursiveInitialization (
recursiveInitialization
void ImageLoader::recursiveInitialization(const LinkContext& context, mach_port_t this_thread, const char* pathToInitialize,
InitializerTimingList& timingInfo, UninitedUpwards& uninitUps)
{
recursive_lock lock_info(this_thread);
recursiveSpinLock(lock_info);
if ( fState < dyld_image_state_dependents_initialized-1 ) {
uint8_t oldState = fState;
// break cycles
fState = dyld_image_state_dependents_initialized-1;
try {
// initialize lower level libraries first
for(unsigned int i=0; i < libraryCount(); ++i) {
ImageLoader* dependentImage = libImage(i);
if ( dependentImage != NULL ) {
// don't try to initialize stuff "above" me yet
if ( libIsUpward(i) ) {
uninitUps.imagesAndPaths[uninitUps.count] = { dependentImage, libPath(i) };
uninitUps.count++;
}
else if ( dependentImage->fDepth >= fDepth ) {
dependentImage->recursiveInitialization(context, this_thread, libPath(i), timingInfo, uninitUps);
}
}
}
// record termination order
if ( this->needsTermination() )
context.terminationRecorder(this);
// let objc know we are about to initialize this image
uint64_t t1 = mach_absolute_time();
fState = dyld_image_state_dependents_initialized;
oldState = fState;
context.notifySingle(dyld_image_state_dependents_initialized, this, &timingInfo);
// initialize this image
bool hasInitializers = this->doInitialization(context);
// let anyone know we finished initializing this image
fState = dyld_image_state_initialized;
oldState = fState;
context.notifySingle(dyld_image_state_initialized, this, NULL);
if ( hasInitializers ) {
uint64_t t2 = mach_absolute_time();
timingInfo.addTime(this->getShortName(), t2-t1);
}
}
catch (const char* msg) {
// this image is not initialized
fState = oldState;
recursiveSpinUnLock();
throw;
}
}
recursiveSpinUnLock();
}
同样的根据LLDB 调试堆栈结果。我们知道接下来我们要进notifySingle函数，发现点不进去notifySingle，我们就全局搜索notifySingle (
notifySingle
static void notifySingle(dyld_image_states state, const ImageLoader* image, ImageLoader::InitializerTimingList* timingInfo)
{
//dyld::log("notifySingle(state=%d, image=%s)\n", state, image->getPath());
std::vector* handlers = stateToHandlers(state, sSingleHandlers);
if ( handlers != NULL ) {
dyld_image_info info;
info.imageLoadAddress = image->machHeader();
info.imageFilePath = image->getRealPath();
info.imageFileModDate = image->lastModified();
for (std::vector::iterator it = handlers->begin(); it != handlers->end(); ++it) {
const char* result = (*it)(state, 1, &info);
if ( (result != NULL) && (state == dyld_image_state_mapped) ) {
//fprintf(stderr, " image rejected by handler=%p\n", *it);
// make copy of thrown string so that later catch clauses can free it
const char* str = strdup(result);
throw str;
}
}
}
if ( state == dyld_image_state_mapped ) {
// Save load addr + UUID for images from outside the shared cache
if ( !image->inSharedCache() ) {
dyld_uuid_info info;
if ( image->getUUID(info.imageUUID) ) {
info.imageLoadAddress = image->machHeader();
addNonSharedCacheImageUUID(info);
}
}
}
if ( (state == dyld_image_state_dependents_initialized) && (sNotifyObjCInit != NULL) && image->notifyObjC() ) {
uint64_t t0 = mach_absolute_time();
dyld3::ScopedTimer timer(DBG_DYLD_TIMING_OBJC_INIT, (uint64_t)image->machHeader(), 0, 0);
(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());
uint64_t t1 = mach_absolute_time();
uint64_t t2 = mach_absolute_time();
uint64_t timeInObjC = t1-t0;
uint64_t emptyTime = (t2-t1)*100;
if ( (timeInObjC > emptyTime) && (timingInfo != NULL) ) {
timingInfo->addTime(image->getShortName(), timeInObjC);
}
}
// mach message csdlc about dynamically unloaded images
if ( image->addFuncNotified() && (state == dyld_image_state_terminated) ) {
notifyKernel(*image, false);
const struct mach_header* loadAddress[] = { image->machHeader() };
const char* loadPath[] = { image->getPath() };
notifyMonitoringDyld(true, 1, loadAddress, loadPath);
}
}
接下来 LLDB调试堆栈就没有了，分析可知其重点函数是(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());这句,我们来找一下 sNotifyObjCInit这个函数，发现它在registerObjCNotifiers这个函数里面
registerObjCNotifiers
void registerObjCNotifiers(_dyld_objc_notify_mapped mapped, _dyld_objc_notify_init init, _dyld_objc_notify_unmapped unmapped)
{
// record functions to call
sNotifyObjCMapped = mapped;
sNotifyObjCInit = init;
sNotifyObjCUnmapped = unmapped;
// call 'mapped' function with all images mapped so far
try {
notifyBatchPartial(dyld_image_state_bound, true, NULL, false, true);
}
catch (const char* msg) {
// ignore request to abort during registration
}
// call 'init' function on all images already init'ed (below libSystem)
for (std::vector::iterator it=sAllImages.begin(); it != sAllImages.end(); it++) {
ImageLoader* image = *it;
if ( (image->getState() == dyld_image_state_initialized) && image->notifyObjC() ) {
dyld3::ScopedTimer timer(DBG_DYLD_TIMING_OBJC_INIT, (uint64_t)image->machHeader(), 0, 0);
(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());
}
}
}
搜索registerObjCNotifiers在哪里调用了，发现在_dyld_objc_notify_register进行了调用
void _dyld_objc_notify_register(_dyld_objc_notify_mapped mapped,
_dyld_objc_notify_init init,
_dyld_objc_notify_unmapped unmapped)
{
dyld::registerObjCNotifiers(mapped, init, unmapped);
}
接下来我们去探索_dyld_objc_notify_register的源码
注意：
_dyld_objc_notify_register的函数需要在libobjc源码中搜索
_objc_init
void _objc_init(void)
{
static bool initialized = false;
if (initialized) return;
initialized = true;
// fixme defer initialization until an objc-using image is found?
environ_init();
tls_init();
static_init();
runtime_init();
exception_init();
cache_init();
_imp_implementationWithBlock_init();
_dyld_objc_notify_register(&map_images, load_images, unmap_image);
#if __OBJC2__
didCallDyldNotifyRegister = true;
#endif
}
来到这里 , 我们就看到了 _dyld_objc_notify_register被调用 , 传递了三个参数
-
map_images: dyld 将image加载进内存时 , 会触发该函数。 -
load_images: dyld 初始化 image 会触发该方法。( 我们所熟知的 load 方法也是在此处调用 ) -
unmap_image: dyld 将 image 移除时 , 会触发该函数。也就是说_objc_init中注册并保存了map_images , load_images , unmap_image函数地址。
走到这里我们还是没有找到堆栈的闭环。怎么办呢？
.....
我们回到 recursiveInitialization 当中的这行代码查看doInitialization方法
doInitialization
根据LLDB调试堆栈我们就差 load images这一步了，很明显，我们需要进入 doImageInit函数看看里面做了什么。
bool ImageLoaderMachO::doInitialization(const LinkContext& context)
{
CRSetCrashLogMessage2(this->getPath());
// mach-o has -init and static initializers
doImageInit(context);
doModInitFunctions(context);
CRSetCrashLogMessage2(NULL);
return (fHasDashInit || fHasInitializers);
}
我们进入到doImageInit的源码中
doImageInit
void ImageLoaderMachO::doImageInit(const LinkContext& context)
{
if ( fHasDashInit ) {
const uint32_t cmd_count = ((macho_header*)fMachOData)->ncmds;
const struct load_command* const cmds = (struct load_command*)&fMachOData[sizeof(macho_header)];
const struct load_command* cmd = cmds;
for (uint32_t i = 0; i < cmd_count; ++i) {
switch (cmd->cmd) {
case LC_ROUTINES_COMMAND:
Initializer func = (Initializer)(((struct macho_routines_command*)cmd)->init_address + fSlide);
#if __has_feature(ptrauth_calls)
func = (Initializer)__builtin_ptrauth_sign_unauthenticated((void*)func, ptrauth_key_asia, 0);
#endif
// verify initializers are in image
if ( ! this->containsAddress(stripPointer((void*)func)) ) {
dyld::throwf("initializer function %p not in mapped image for %s\n", func, this->getPath());
}
if ( ! dyld::gProcessInfo->libSystemInitialized ) {
// libSystem initializer must run first
dyld::throwf("-init function in image (%s) that does not link with libSystem.dylib\n", this->getPath());
}
if ( context.verboseInit )
dyld::log("dyld: calling -init function %p in %s\n", func, this->getPath());
{
dyld3::ScopedTimer(DBG_DYLD_TIMING_STATIC_INITIALIZER, (uint64_t)fMachOData, (uint64_t)func, 0);
func(context.argc, context.argv, context.envp, context.apple, &context.programVars);
}
break;
}
cmd = (const struct load_command*)(((char*)cmd)+cmd->cmdsize);
}
}
}
简单分析一下这个函数，其实就是将函数方法的指针进行平移，最终找到其初始化的实现。
我们通过观察注释// 这里可以看到，这个函数第一次执行 , 进行libsystem的初始化 . 会走到 doInitialization -> doModInitFunctions -> libSystemInitialized
libsystem 的初始化 , 它会调用起libdispatch_init, libdispatch 的 init 会调用_os_object_init , _os_object_init 这个函数里面调用了_objc_init
前面我们说过，_objc_init中注册并保存了 map_images, load_images, unmap_image 函数地址，到这里终于 找到了load images调用的地方，LLDB调用堆栈的结果终于形成完整的闭环了!