Static Library:
ipa package file is large.
By default, static libraries only link useful class files to Mach-O (with class files as the smallest link unit)
The ipa package can be smaller. For example: try to put the code in a static library. If the code of a file in the static library is not referenced anywhere, it won't link the file into the executable file (Category is often optimized away, generally use -Objc and -all_load or -force_load to deal with static library Category loading problem)
Fast cold start. The premise is not to use the dynamic library split with the dynamic library lazy loading scheme. There are rebase and bind in the app startup process, and multiple static libraries only need to rebase and bind once.
There is a possibility of symbolic conflict.
Shared TEXT segment. Before iOS 9, the TEXT limit of a single Mach-O was 60M After iOS 9, the TEXT limit of a single Mach-O is 500M
No additional signature verification is required.
The visibility of static library symbols can be modified during linking.
The file format is primarily static library files in fat format.
Most of the forms are .a and .framework.
When the static library does not contain bitcode, the target deployment that references the static library cannot include bitcode.
Dynamic Library:
ipa package file is small.
The ipa package can be bigger. For example: Use the dynamic library lazy loading scheme. Because this scheme will copy the entire lib into ipa.
Slow cold start. There are rebase and bind in the app startup process, and multiple dynamic libraries need to rebase and bind multiple times.
Need to set the appropriate runpath.
Need to be loaded dynamically.
Need signature and need to verify the signature. Will check the signatures of all frameworks, the signature must contain the TeamIdentifier, and the TeamIdentifier of the framework and the host App must be the same. If you use Xcode re-signature, you need to ensure the consistency of dynamic library signatures.
Need to export symbols.
Repeated arch structure.
Duplicate code in App and dynamic library can coexist without symbol conflict. Because the executable file is in the construction and linking stage, it will be added when it encounters the static libraries, and it will be marked when it encounters the dynamic libraries, maintaining independence from each other. For symbols from dynamic libraries, the compiler will mark and hand it over to dyld to load and link the symbols, which means that the linking process is postponed until runtime. For example, the App uses the 3.0 version SDK, and the dynamic library uses the 1.0 version SDK, which can run normally, but there are risks.
Need to include distribution size after linking.
It will be loaded before the main function during the cold start process. Too many dynamic libraries will slow down the cold start speed by default. If it is in the form of lazy loading dynamic libraries, it can speed up the startup speed of the App. We can use dlopen and bundle to do lazy loading optimization.
When the dynamic library does not contain bitcode, the target deployment that references the dynamic library can have bitcode.
Since CocoaPods v0.36.0, we can add the keyword use_frameworks! to compile into a structure similar to Embedded Framework (it can be called umbrella framework) By default, all dependencies of the project are changed to dynamic libraries (we can use use_modular_headers!, or we can add s.static_framework = true to podsepc to avoid it) CocoaPods executes the script to embed the dynamic library into the Framework directory of the .app (equivalent to adding a dynamic library to Embedded Binaries)
Follow me on:
Comments