The effect of IOS dynamic Framework on app startup time

Recently seen in the slow App Startup times mentioned:

The dynamic loader finds and reads the dependent dynamic libraries (dylibs) used by the App. Each library can itself have dependencies. The loading of Apple system frameworks is highly optimized but loading your embedded to frameworks can be expensive. To speed up dylib loading Apple suggests for use fewer dylibs or consider merging A suggested target is for six extra (Non-system) frameworks.

As for what is static lib what is dynamic lib here will not be launched, you can through the article at the bottom of the relevant links to learn more.

A reference to the official explanation is: A better approach are for an app to load code into its address spaces when it's actually needed, either at Laun CH or at runtime. The type of library that provides this flexibility is called Dynamic Library. When a app is launched, the app's Code-which includes the code of the The static libraries it was linked With-is to The app ' s address spaces. Applications with large executables suffer to slow launch times and large memory

If you have a simple idea that if your framework uses swift, it is dynamic lib. This is also the subject of this article: how the dynamic framework affects app startup time.

The test approach is to use the new environment variables provided by IOS 10 to dyld_print_statistics the app startup time. The Xcode version is 8.1, and the test device is the iphone 6. Cocoapod version 1.1.

Note that the test process found that the time statistics are not consistent, so my data here may be different from your own test , but I do not think this deviation affects the qualitative. Baseline: Empty OC Project VS empty Swift project

Create two empty projects without any business logic.

Start time of pure OC Project
Start time for pure Swift empty Project

There's probably a difference of 10 milliseconds. This gap, which takes into account the deviation of measurement, can be regarded as almost identical.

But there are times when swift loading suddenly increases to 400ms. This is because the dynamic framework of the system will only load one copy. Assuming that 10 app launches are used for Uikit, only one uikit is loaded inside the system. So sometimes the swift project starts with the system framework without caching, and it looks a bit longer. 6 Framework

Now let's compare the situation with the code. Two projects were added to 5 dependencies.
This is 6 dependencies of the OC Project:

  Pod ' afnetworking ', ' ~> 3.0 '
  pod ' masonry ' pod '
  mjrefresh '
  pod ' sdwebimage '
  pod ' Mbprogresshud '
  pod ' Iqkeyboardmanager '

This is the 6 reliance of the SWIFT project, in order to simulate the use of some OC libraries in real production, 3 libraries were replaced with swift codes and 3 OC libraries were retained:

  Pod ' alamofire ' pod '
  snapkit ' pod '
  mjrefresh '
  pod ' Kingfisher '
  pod ' mbprogresshud '
  pod ' Iqkeyboardmanager '

OC's start-up time is around 70-100ms. Here is a quick case of data:

OC6 a dependent start time

The SWIFT project starts at the first installation time in Dylib will be more than 100ms, do not know why. Results of the SWIFT project running after it has been installed:

Swift6 a dependency

To make a horizontal contrast chart:

Conclusions

The SWIFT project's dylib time is more than 100 milliseconds more than OC, much larger than OC. Swift does not use the framework VS . Framework

We speculate that loading the framework causes a lot of time to grow. So we put all these dependent code in the main app, not using the framework to separate. This time we exchanged a few dependent libraries for Swift:

  Pod ' alamofire ' pod '
  snapkit ' pod '
  Kingfisher ' pod '
  swiftdate '
  pod ' objectmapper '

5 dependent items in app have been installed, run open results:

5 dependencies

Considering the error, it can be considered that the code in the framework is OC or Swift has little effect on the loading time.
Merging the dependent code into the app is a way to manually copy:

Startup time statistics turned on after installation:

Contrast chart:

Conclusions

If you copy the code into the app, you can significantly reduce the dylib load time. 15 Framework OC VS Swift

Podfile of OC:

Pod ' afnetworking ', ' ~> 3.0 '
  pod ' masonry ' pod '
  mjrefresh '
  pod ' sdwebimage '
  pod ' Mbprogresshud ' Pod '
  iqkeyboardmanager ' pod '

  fmdb ' pod '
  gpuimage '
  pod ' openudid '
  pod ' datetools '
  pod ' Tmcache ' pod '
  webviewjavascriptbridge ' pod '
  zbarsdk ' pod '
  jsqmessagesviewcontroller '
  pod ' Yykit '
  pod ' dznemptydataset '

Podfile of Swift Project:

Pod ' afnetworking ', ' ~> 3.0 '
  pod ' alamofire ' pod '
  snapkit '
  pod ' mjrefresh '
  pod ' Kingfisher ' Pod ' mbprogresshud ' pod '
  iqkeyboardmanager ' pod ' fmdb ' pod '
  gpuimage '
  pod ' openudid ' Pod '
  swiftdate ' pod '
  cryptoswift ' pod '
  objectmapper '
  pod ' zbarsdk '
  pod ' cocoalumberjack/ Swift '
  pod ' yykit '
  pod ' dznemptydataset '

Results of OC:

Swift's results:

Contrast chart:

Time comparison

Vertical contrast:

Conclusions

The number of OC projects increased with dependence, the initialization time increased, but the dylib time increase was not obvious. Swift then dylib time dramatically, with little change in initialization time. The total start-up time is more than 200 milliseconds more than OC, with the increase of the framework, the start time gap widened. 25 Dynamic Framework

How much would it increase if the dylib were to be raised to 25 hours?
Add 10 more dependencies on 15 basis:

  Pod ' ezswiftextensions '
  pod ' Reactivecocoa ', ' 5.0.0-alpha.3 '
  pod ' rxswift ',    ' ~> 3.0 '
  pod ' Rxcocoa ',    ' ~> 3.0 '
  pod ' monkeyking '
  pod ' reusable '
  pod '
  swiftyjson ' pod
  ' Xcglogger ' Pod ' Gifu ',    ' ~> 2.0.0-rc '
  pod ' Spring ',: Git => ' https://github.com/MengTo/Spring.git ',: Branch => ' Swift3 '

Run Time:

Compared to the 15 Dylib:

The Dylib loading time increased from 400 to 600 and increased by about 30%. The number of dylib increased from 15 to 25 by 40%. Nearly linear. Summary

There is no doubt that using the dynamic framework will increase the app startup time. If your number is around 25, it will increase by about 0.5s compared to the static framework startup time of OC. I'm personally not too hopeful about the timing of iOS to increase the load framework, and Apple makes the custom framework permanent memory seem hopeless, which may not be wiped out in the short term.

It is also possible to artificially manage some external dependencies manually in a framework, but it would be more difficult if the complexity of the package is interdependent.

If the company has a demanding performance, it may be hard to tolerate 500ms. But I think for most products, sacrificing this 500ms performance compared to the use of OC, I think it is more uncomfortable to use OC.

RELATED links:
WWDC 2016 session 406 optimizing APP Startup Time
What are frameworks?
"Libraries" in IOS development (i)
Jverkoey/ios-framework

Wen/No story of the Zhuo classmate (Jane book author)
Original link: http://www.jianshu.com/p/3263009e9228
Copyright belongs to the author, reproduced please contact the author to obtain authorization, and labeled "Jane book author."