8

Based on what I study, iOS uses most(all) of system frameworks as dynamic frameworks. Does iOS load all of them when an app launches? Or iOS may load it later when iOS actually need the framework?

The advantage of loading it when an app launches: Save more time when iOS calls the functions in the dynamic frameworks.

The advantage of loading it lazily: Save more memory.

allenlinli
  • 2,066
  • 3
  • 27
  • 49

2 Answers2

7

Or iOS may load it later when iOS actually need the framework?

The Wikipedia page on dynamic linking covers both the general idea and a number of details specific to various popular operating systems. It says (in part) this about Darwin, including macOS and iOS:

The executables on the macOS and iOS platforms often interact with the dynamic linker during the execution of the process; it is even known that an executable might interact with the dynamic linker, causing it to load more libraries and resolve more symbols, hours after it initially launches.

Furthermore, if you read the man page for dyld, the dynamic loader, you'll find an environment variable called DYLD_BIND_AT_LAUNCH that is described thus:

When this is set, the dynamic linker binds all undefined symbols the program needs at launch time. This includes function symbols that can are normally lazily bound at the time of their first call.

A final piece of evidence is in Apple's Overview of Dynamic Libraries document, which says in part:

When an app is launched, the OS X kernel loads the app’s code and data into the address space of a new process. The kernel also loads the dynamic loader ( /usr/lib/dyld ) into the process and passes control to it. The dynamic loader then loads the app’s dependent libraries. These are the dynamic libraries the app was linked with. The static linker records the filenames of each of the dependent libraries at the time the app is linked. This filename is known as the dynamic library’s install name.

And in the next paragraph:

The dynamic loader resolves only the undefined external symbols the app actually uses during the launch process. Other symbols remain unresolved until the app uses them.

Given all that, it sounds like iOS probably loads each dynamic framework as part of the process of launching an app, but defers actually binding undefined names in the app to definitions in the framework until it's actually needed.

Caleb
  • 124,013
  • 19
  • 183
  • 272
  • 1
    The Medium article here says: “On the other hand, dynamic frameworks are saved in the app frameworks directory and are loaded only when necessary but they are linked to the project during startup” — Cyril Cermak https://link.medium.com/19DFQv8EMZ I am not sure it actually works as this article says in iOS. – allenlinli Sep 12 '19 at 03:14
  • And for this part `The dynamic loader then loads the app’s dependent libraries.`, I think Apple could still load the app’s dependent libraries **lazily**. And for this part, `The dynamic loader resolves only the undefined external symbols the app actually uses during the launch process. Other symbols remain unresolved until the app uses them.` It seens like the actions of resolving symbols (which is same as `linking`?) and loading into memory are seperated. – allenlinli Sep 12 '19 at 03:18
0

Apple doc says:

A framework is a bundle (a structured directory) that contains a dynamic shared library along with associated resources, such as nib files, image files, and header files. When you develop an application, your project links to one or more frameworks. For example, iPhone application projects link by default to the Foundation, UIKit, and Core Graphics frameworks. Your code accesses the capabilities of a framework through the application programming interface (API), which is published by the framework through its header files. Because the library is dynamically shared, multiple applications can access the framework code and resources simultaneously. The system loads the code and resources of a framework into memory, as needed, and shares the one copy of a resource among all applications.

Reference : https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/Framework.html

Deepak
  • 724
  • 4
  • 13
  • That document covers macOS; it talks about Cocoa and AppKit, not Cocoa Touch and UIKit. The mechanics are probably similar, but it’s not clear that 3rd party frameworks on iOS are covered by the same rules as dynamic frameworks on macOS. – Caleb Oct 06 '19 at 20:48