The difference between static and dynamic libraries

A Library is simply a piece of compiled binary code that, with a header file, can be used by others.

When do we use libraries? In one case, some code needs to be used by others, but we don’t want others to see the source code, so we need to wrap it in a library, exposing only the initial files. On the other hand, if we want to reduce compilation time for code that will not change much, we can package it as a library, because the library is already compiled binary, and only need to Link when compiling, so we won’t waste compilation time.

As mentioned above, the library needs Link when it is used. There are two ways of Link, static and dynamic, so the static library and dynamic library are generated.

Static library

Static libraries are statically linked libraries (.lib for Windows,.a for Linux, and.a for Mac). It is called static because the static library is copied directly into the target program at compile time, and the code does not change in the target program.

The benefits of static libraries are obvious: once compiled, the library files are virtually useless. The target program runs without external dependencies. Of course, its disadvantages are also obvious, that is, the volume of the target program will be increased.

The dynamic library

Dynamic libraries are dynamically linked libraries (.dll for Windows,.so for Linux,.dylib/.tbd for Mac). In contrast to static libraries, dynamic libraries are not copied at compile time into the target program, which stores only references to dynamic libraries. The dynamic library is not actually loaded until the program runs.

The advantage of a dynamic library is that it does not need to be copied into the target program, does not affect the size of the target program, and the same library can be used by multiple programs (for this reason, dynamic libraries are also called shared libraries). Also, features that are loaded at compile time allow us to replace libraries at any time without recompiling the code. The main problem with dynamic libraries is that dynamic loading leads to a performance loss, and using dynamic libraries also makes the program dependent on the external environment. If your environment lacks a dynamic library or has an incorrect version of the library, the program will not run (the beloved Lib Not Found error on Linux).

iOS Framework

In addition to the.a and.dylib/.tbd mentioned above, Mac OS/iOS platforms can also use the Framework. The Framework is actually a way of packaging library binaries, header files, and related resource files together for easy management and distribution.

Before iOS 8, iOS platform does not support the use of dynamic Framework, developers can use apple’s own Framework UIKit.Framework, Foundation.Framework, etc. This restriction may be for security reasons (see discussion here). On the other hand, because iOS apps run in a sandbox, different programs cannot share code, and dynamic downloading of code is forbidden by Apple, there is no way to give full play to the advantages of dynamic library, in fact, there is no need for the existence of dynamic library.

Due to the limitations mentioned above, if developers want to share code on iOS, the only option is to package it as a static library. A file and attach it to it (e.g. wechat SDK). But this way of packaging is not convenient, it is also difficult to use, people still want to share code like Framework, directly thrown into the project can be used. So people have come up with all sorts of clever ways to get Xcode to Build a Framework that iOS can use, and see how this works here and here, There is also a difference between a “Fake” Framework and a “Real” Framework.

With the release of iOS 8/Xcode 6, dynamic library support has been added to the iOS platform, and Xcode 6 has native Framework support (both dynamic and static), so all of the aforementioned wizardry is no longer necessary (see the new approach here). Why was dynamic library support added to iOS 8? The only reason is probably Extension. Extension and App are two separate executables that need to share code, in which case dynamic library support is essential. But this dynamic Framework is very different from the SYSTEM’S UIKit.Framework. The Framework of the system does not need to be copied to the target program. The Framework made by ourselves, even if it is dynamic, still needs to be copied to the App (the Bundle of App and Extension is shared). So Apple calls this Framework Embedded Framework.

Swift support

Swift was also released with iOS8 / Xcode 6. If you want to use external code in a project, there are only two options: copy the code into the project, or use the dynamic Framework. Using static libraries is not supported.

The main reason for this is that the Swift runtime is not included in the iOS system, but packaged into the App (which is also the reason for the large size of the Swift App), and the static library will result in the final target application containing duplicate runtime (this is apple’s own explanation). Copying Runtime also causes problems with Swift libraries in projects that are pure ObjC. Apple claims that this limitation will be removed when Swift Runtime stabilizes and is added to the system (see the problem description, also from Apple’s own documentation).

The practice of CocoaPods

In a project of pure ObjC, CocoaPods uses the compile static library.a method to integrate code into the project. Each target in the Pods project corresponds to a static library for that Pod. A files are not actually produced during compilation. If you need.a files, refer here, or use the cocoasPods-Packager plugin.

When you don’t want to distribute code, you can also distribute pods using the Framework. CocoaPods provides the Vendored_framework option to use third-party frameworks, as described here and here.

For Swift projects, CocoaPods provides dynamic Framework support. Through use_frameworks! Option control. For libraries written by Swift, if you want to import projects through CocoaPods, you must add use_frameworks! Options. See Swift in the previous section for specific reasons.

Additional information on code distribution can be found in this blog post: geeklu.com/2014/02/obj…

The resources

  • Stackoverflow.com/questions/2…
  • Stackoverflow.com/questions/2…
  • Stackoverflow.com/questions/6…
  • Blog.cocoapods.org/CocoaPods-0…