In the last post we didn’t look at this method _dyLD_OBJC_NOTIFy_register in detail but in this video we’re going to look at this process

1.dyldlinkobjcThe function of board

We run _dyLD_objC_notify_register (&map_images, load_images, unmap_image) inside the _objc_init function in objC4-818.2; As shown in the figure:

  • &map_images =_dyld_objc_notify_mapped mapped
  • load_images =_dyld_objc_notify_init init
  • unmap_image =_dyld_objc_notify_unmapped unmapped

In objC4-818.2, it is found that the implementation of _dyLD_OBJC_NOTIFy_register can not be found in the dyld source code

_dyLD_OBJc_notify_register can be implemented in either dyld3 or dyld2 and what we’re looking at here is dyld2 and why. Because we set a breakpoint debugging found is going dyld2

So when did this _dyLD_OBJC_NOTIFY_register map_images and load_images get called

  • map_images = mapped = sNotifyObjCMapped
  • load_images = init = sNotifyObjCInit

When are sNotifyObjCMapped and sNotifyObjCInit invoked

SNotifyObjCMapped when do we find a notifyBatchPartial execution

When is sNotifyObjCInit called and we find it called at notifySingle

notifySingleWhen do we call itrecursiveInitializationcall

Map_images will call

Invokes the map_images_nolock

Method call to load_images

Prepare_load_methods method call

The call_load_methods load method calls the ViewController load method first

Next __attribute__((constructor)) void kcFunc() calls this method

2.dyld to main()function

The lastjmpjumpmain()function

supplement

The real machine calls the method dyld3

Map_images -> Key data

  • 1. Load-protocol-properties of the classro–rwSlow process – lazy load – Non-lazy load
  • 2.map_imagesWhen is it called
  • 3.load_images() Load method + CXX + main
  • 4.dyld->main
  • 5. Analysis of the previous test
  • 6. Videowwdc2017 dyld2 VS dyld3