本篇文章主要是探索程序启动流程。
load方法断点
首先我们来个简单程序
static __attribute__((constructor)) void hfmain()
{
NSLog(@"hello HF");
}
int main(int argc, char * argv[]) {
NSString * appDelegateClassName;
@autoreleasepool {
// Setup code that might create autoreleased objects goes here.
appDelegateClassName = NSStringFromClass([AppDelegate class]);
}
return UIApplicationMain(argc, argv, nil, appDelegateClassName);
}
在viewcontroller.m 里添加load方法
@interface ViewController ()
@end
@implementation ViewController
+ (void)load {
NSLog(@"[%s]", __FUNCTION__);
}
- (void)viewDidLoad {
[super viewDidLoad];
// Do any additional setup after loading the view.
}
@end
2021-07-13 16:34:47.731823+0800 Dyld启动流程[19287:6264922][+[ViewController load]]
2021-07-13 16:34:54.092403+0800 Dyld启动流程[19287:6264922] hello HF
通过打印我们知道+load
> c++构造函数
> main
接下来我们看看+load
方法的函数调用堆栈
_dyld_start
->dyldbootstrap::start
->dyld::_main
->dyld dyld::initializeMainExecutable
->ImageLoader::runInitializers
->dyld ImageLoader::processInitializers
->ImageLoader::recursiveInitialization
->dyld::notifySingle
->load_images
可以看到+load方法的调用函数堆栈,接下来我们就可以顺着这条主线去dyld源码里面看是否是这样的一个流程,dyld-852
目前最新的源码,很可惜并不能调试,所以我们只能去看代码,顺着断点里的主线一步步研究
load流程分析
1 _dyld_start
_dyld_start
调用了dyldbootstrap::start
2 dyldbootstrap::start
3 _main
_main
函数有点大,截图不过来,有兴趣的可以去下载源码看,这边就附上_main函数的流程
注意:这边的_main不是我们主程序里面的main,所以不要搞混了
紧接着我们顺着主线来到initializeMainExecutable
4 initializeMainExecutable
这边主要分为动态库调用
runInitializers
和主程序调用runInitializers
,所以我们只要分析一个就够了
5 runInitializers
[图片上传中...(image.png-642a8d-1626161970567-0)]
6 processInitializers
processInitializers
里面递归调用,目的是某些库有依赖其他库,当遇到依赖库就需要优先加载
7 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); // dyld_image_state_dependents_initialized
// initialize this image
bool hasInitializers = this->doInitialization(context); // 加载系统库,系统库初始化注册类和所有load方法
// let anyone know we finished initializing this image
fState = dyld_image_state_initialized;
oldState = fState;
context.notifySingle(dyld_image_state_initialized, this, NULL); // 调用了所有类的load方法
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();
}
看到这里面有调用到notifySingle
8 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
// Include UUIDs for shared cache dylibs in all image info when using private mapped shared caches
if (!image->inSharedCache()
|| (gLinkContext.sharedRegionMode == ImageLoader::kUsePrivateSharedRegion)) {
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);
}
}
其实在源码中有两个notifySingle函数,但是我们通过真机里面断点,查看汇编代码来确定该函数。
9 _dyld_objc_notify_register的引出
(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());
这边正是调用load_Images
函数从而调用我们的+load
方法。但是这边sNotifyObjCInit
是个函数指针,所以一定有地方进行赋值操作
通过全局搜索找到在这边进行了赋值操作,但是呢我们还是不知道这边的
init
究竟是什么害的一层层往上找
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在objc_init方法中有看到调用
如图这边的
load_image
方法.我们可以进去看看这个方法的实现
void
load_images(const char *path __unused, const struct mach_header *mh)
{
if (!didInitialAttachCategories && didCallDyldNotifyRegister) {
didInitialAttachCategories = true;
loadAllCategories();
}
// Return without taking locks if there are no +load methods here.
if (!hasLoadMethods((const headerType *)mh)) return;
recursive_mutex_locker_t lock(loadMethodLock);
// Discover load methods
{
mutex_locker_t lock2(runtimeLock);
prepare_load_methods((const headerType *)mh);
}
// Call +load methods (without runtimeLock - re-entrant)
call_load_methods();
}
void call_load_methods(void)
{
static bool loading = NO;
bool more_categories;
loadMethodLock.assertLocked();
// Re-entrant calls do nothing; the outermost call will finish the job.
if (loading) return;
loading = YES;
void *pool = objc_autoreleasePoolPush();
do {
// 1. Repeatedly call class +loads until there aren't any more
while (loadable_classes_used > 0) {
call_class_loads();
}
// 2. Call category +loads ONCE
more_categories = call_category_loads();
// 3. Run more +loads if there are classes OR more untried categories
} while (loadable_classes_used > 0 || more_categories);
objc_autoreleasePoolPop(pool);
loading = NO;
}
上面就是调用的类的+load
方法
虽然我们通过+load
断点一步步跟踪大概知道了流程,但是这个load_images
方法是什么时候注册的我们并不知道.接下来我们通过断点_objc_init
来看看什么时候调用
_objc_init 调用流程
从函数堆栈中我们可以看到也是从dyld_start开始,只是后面的流程略有不同,那我们就来看看流程走向
dyld ImageLoaderMachO::doInitialization
->dyld ImageLoaderMachO::doModInitFunctions
->libSystem.B.dylib libSystem_initializer
->libdispatch.dylib libdispatch_init
->libdispatch.dylib _os_object_init
doInitialization
看源码recursiveInitialization
确实调用了doInitialization
doModInitFunctions
这边有个注释,
libSystem
库必须第一个加载,所以就很可能会在加载的过程中注册,这样整个流程就比较顺畅了.
libSystem
接下来我们来看看libSystem的库源码
__attribute__((constructor)) static void libSystem_initializer(int argc, const char* argv[], const char* envp[], const char* apple[], const struct ProgramVars* vars)
这边是构造函数,也就是默认会调用的函数,而在函数里面会调用到libdispatch_init()
刚好串起来。
c++构造方法流程分析
前面的流程跟
+load
一模一样到doInitialization
这边就跟objc_init
流程一样,但是只到了doModInitFunctions
,其实这边我们就可以确定了,doModInitFunctions
方法就是调用各个库的c++构造方法,只是libSystem
库必须优先第一个调用
为什么load方法在c++构造方法之前?
从这边就可以看得是先调用的
notifySingle
后再调用doInitialization
源码地址
https://opensource.apple.com/tarballs/libdispatch/
https://opensource.apple.com/tarballs/Libsystem/
https://opensource.apple.com/tarballs/objc4/
https://opensource.apple.com/tarballs/dyld/