April 7, 2017 at 10:21How to reduce the launch time of applications for iOS
Mobile processors and memory are getting faster and applications are loading the same way. What is the salt? The question of the launch time of iOS-applications is occupied by the mind of more than one developer (especially after switching to Swift). We decided to find out the reasons for the long download and solutions to this problem from Nikolai Likhogrud, the developer of Mobile Yandex.Maps.
Under the cut: typical rake, useful tools and the right approaches to solving performance problems.
- Please tell us briefly about yourself and your work.
Nikolay Likhogrud:In 2012, I graduated from the Faculty of Computational Mathematics and Cybernetics of Moscow State University and almost immediately began working at Any Void under the direction of Yuri Podorozhny. I worked there on various projects for some time, gained experience, and after our transition to Yandex, I switched to Mobile Yandex.Maps. I’ve been in this project for almost 3 years, the last year I have been working as a team leader.
- What role do experiments with accelerated launch of iOS applications play in your work?
Nikolay Likhogrud:Launch time is one of the key indicators of the mobile application. Yandex.Maps should help users quickly understand where they are and where to go. If the application starts for a long time, it will annoy people, they will go to competitors or write angry reviews. As a development manager, I am directly responsible for this key indicator, and lately we have done a lot of work towards improving it.
- Where is the struggle to reduce application launch time in the overall sequence of work to improve application performance?
Nikolay Likhogrud:It all depends on what your application is written on - Objective-C or Swift, and which device park it is oriented to. Objective-C applications run fundamentally faster because the Objective-C runtime libraries are built into the system, and Objective-C code can be compiled into static libraries. This eliminates the time-consuming operations of loading dynamic libraries at startup. With Swift, the situation is completely different - even an empty application on the iPhone 5 takes 2 seconds to load. Therefore, for Swift, the launch problem comes first.
- Are there any typical rakes (related to the speed of launching applications) that developers most often “attack”?
Nikolay Likhogrud:One of the main problems is the use of hearths written in Swift, as In this case, all CocoaPods targets are collected in separate dynamic libraries. Even if there is little code in the project in the main target, Swift pods can increase the startup time by several times
- Is there any way to deal with them (besides the obvious solution - do not use CocoaPods with Swift)?
Nikolai Likhogrud: Yes. There is a way that allows, on the one hand, to pull up dependencies through CocoaPods, but on the other hand, not to compile them into separate dynamic libraries.
- Are these "rakes" relevant for all versions of iOS (Swift)? Or does each version have its own “gentleman's set” of pitfalls?
Nikolay Likhogrud:At the moment, this is true for all versions of Swift and for all iOS, both for old and new. Loading custom dynamic libraries takes a long time, especially on 32-bit devices. Apple developers are trying to improve the situation. For example, in iOS 9.3, they reduced the signature verification time of dynamic libraries, but the situation has not changed radically.
- With what, in your opinion, it is necessary to begin work in the direction of optimizing the launch time of the application?
Nikolay Likhogrud:The first step is to turn on the DYLD_PRINT_STATISTICS environment variable and see how much time is spent on pre-main and after-main - i.e. to the launch parts for which the system and your application are responsible. This will reveal exactly where the problems are - in your code or in the work of the system loader, which collects the image of the application in memory. Further actions depend on the measurement results. There are ways to reduce the system load time, and your code is optimized as usual - here the profiler helps a lot.
- As part of your report at Mobius 2017, will you talk more about the system part of downloading applications on Swift?
Nikolay Likhogrud:Yes. Since we have an application on Swift, the main problem was with the system part. I will tell you in detail how to measure pre-main and after-main, about cold and warm starts, about ways to optimize the pre-main time. I will also touch on the optimization of my own code a bit - in our project there were a few simple points that gave a good increase. Perhaps this experience is useful to someone. But in general, after-main optimization is a more general task of optimizing iOS applications, so I will not dwell on it in detail, because Each application has its own problems - unlike the system part, the optimization of which is the same for all applications.
- Do you have any preferred tools for working on accelerating the launch of the application?
Nikolay Likhogrud:The main tool is the DYLD_PRINT_STATISTICS variable, which displays statistics on the operation of the system loader. It is also possible to display loadable dynamic libraries through the DYLD_PRINT_LIBRARIES variable. For more advanced users, there are console utilities that allow you to watch the dependencies of individual libraries, symbol tables, how many rebase and bind will be performed at boot time. But these parameters are difficult to influence manually, especially for third-party libraries.
- Can an iOS update alone solve all problems with startup time (without additional optimization)?
Nikolay Likhogrud:The problem is that Swift is still quite young and continues to develop rapidly, regardless of iOS. Therefore, Swift Standard Libraries used are embedded in every Swift application, and therefore there is no static link for Swift. But at some point Swift stabilizes, becomes part of the operating system, they will make a normal link for it. And then all this problem with the slow launch of projects on Swift will completely disappear, after-main optimization will come to the fore, as in Objective-C. This business is not tomorrow, but the near future.
- If the problem is actually Swift's immaturity, is it really necessary to use it now? Can't I continue to write in Objective-C?
Nikolay Likhogrud:Swift is being promoted by Apple itself, and behind it is the future of iOS development. Already now there are frameworks that have ceased to develop their implementations on Objective-C. One way or another, Objective-C is slowly becoming a kind of archaic. Writing on Swift is really cool - comfortable and modern. Using Objective-C, at some point you will come to the conclusion that you do not have enough objective-c - swift interoperability to use modern frameworks or you will encounter problems hiring new developers, because most newcomers are learning Swift now. Of course, at the moment we have to deal with certain compiler quality problems, Xcode brakes, and startup time. But they will be resolved when Swift completes its development.
-Suppose we solve the problem with the launch time of the application for the current version of iOS. Can the achieved result disappear with the iOS update?
Nikolai Likhogrud: There is a possibility of changes in the iOS SDK that will lead to an increase in the user load time, but the pre-main system update is unlikely to worsen. True, each time new iOSs work worse and worse on older devices - iPhone 5 worked on native iOS 6 objectively better than with the latest iOS 10. But this will not affect top-end devices soon.
- Will you advise any sources of information on the issue of accelerating the launch of applications on Swift?
Nikolay Likhogrud: The WWDC 2016 report “Optimizing App Startup Time” is a must. Prior to this, Apple developers practically did not mention the problem, and at WWDC 2016 they dedicated a separate session to the launch time, revealed the details of the bootloader and possible sources of optimizations. There is still a good report by Mail.Ru on Habré about optimization of launch time, but, the truth, it is about an application on Objective-C, so the problem of reducing the pre-main is mentioned in passing - no deeper than at WWDC. But a lot of time was devoted to working with the profiler, after-main optimization and Continuous Integration.
As noted above, a specialist will give more detailed recommendations on optimizing the launch time of iOS applications on Swift as part of his report on Mobius 2017.
Also at the conference you will find other reports on optimizing performance for iOS:
-The Mysterious Swift Performance . Marcin Krzyżanowski, PSPDFKit GmbH;
- 60 fps UI on iOS . Sergey Pronin, App in the Air.
Under the cut: typical rake, useful tools and the right approaches to solving performance problems.
- Please tell us briefly about yourself and your work.
Nikolay Likhogrud:In 2012, I graduated from the Faculty of Computational Mathematics and Cybernetics of Moscow State University and almost immediately began working at Any Void under the direction of Yuri Podorozhny. I worked there on various projects for some time, gained experience, and after our transition to Yandex, I switched to Mobile Yandex.Maps. I’ve been in this project for almost 3 years, the last year I have been working as a team leader.
- What role do experiments with accelerated launch of iOS applications play in your work?
Nikolay Likhogrud:Launch time is one of the key indicators of the mobile application. Yandex.Maps should help users quickly understand where they are and where to go. If the application starts for a long time, it will annoy people, they will go to competitors or write angry reviews. As a development manager, I am directly responsible for this key indicator, and lately we have done a lot of work towards improving it.
- Where is the struggle to reduce application launch time in the overall sequence of work to improve application performance?
Nikolay Likhogrud:It all depends on what your application is written on - Objective-C or Swift, and which device park it is oriented to. Objective-C applications run fundamentally faster because the Objective-C runtime libraries are built into the system, and Objective-C code can be compiled into static libraries. This eliminates the time-consuming operations of loading dynamic libraries at startup. With Swift, the situation is completely different - even an empty application on the iPhone 5 takes 2 seconds to load. Therefore, for Swift, the launch problem comes first.
- Are there any typical rakes (related to the speed of launching applications) that developers most often “attack”?
Nikolay Likhogrud:One of the main problems is the use of hearths written in Swift, as In this case, all CocoaPods targets are collected in separate dynamic libraries. Even if there is little code in the project in the main target, Swift pods can increase the startup time by several times
- Is there any way to deal with them (besides the obvious solution - do not use CocoaPods with Swift)?
Nikolai Likhogrud: Yes. There is a way that allows, on the one hand, to pull up dependencies through CocoaPods, but on the other hand, not to compile them into separate dynamic libraries.
- Are these "rakes" relevant for all versions of iOS (Swift)? Or does each version have its own “gentleman's set” of pitfalls?
Nikolay Likhogrud:At the moment, this is true for all versions of Swift and for all iOS, both for old and new. Loading custom dynamic libraries takes a long time, especially on 32-bit devices. Apple developers are trying to improve the situation. For example, in iOS 9.3, they reduced the signature verification time of dynamic libraries, but the situation has not changed radically.
- With what, in your opinion, it is necessary to begin work in the direction of optimizing the launch time of the application?
Nikolay Likhogrud:The first step is to turn on the DYLD_PRINT_STATISTICS environment variable and see how much time is spent on pre-main and after-main - i.e. to the launch parts for which the system and your application are responsible. This will reveal exactly where the problems are - in your code or in the work of the system loader, which collects the image of the application in memory. Further actions depend on the measurement results. There are ways to reduce the system load time, and your code is optimized as usual - here the profiler helps a lot.
- As part of your report at Mobius 2017, will you talk more about the system part of downloading applications on Swift?
Nikolay Likhogrud:Yes. Since we have an application on Swift, the main problem was with the system part. I will tell you in detail how to measure pre-main and after-main, about cold and warm starts, about ways to optimize the pre-main time. I will also touch on the optimization of my own code a bit - in our project there were a few simple points that gave a good increase. Perhaps this experience is useful to someone. But in general, after-main optimization is a more general task of optimizing iOS applications, so I will not dwell on it in detail, because Each application has its own problems - unlike the system part, the optimization of which is the same for all applications.
- Do you have any preferred tools for working on accelerating the launch of the application?
Nikolay Likhogrud:The main tool is the DYLD_PRINT_STATISTICS variable, which displays statistics on the operation of the system loader. It is also possible to display loadable dynamic libraries through the DYLD_PRINT_LIBRARIES variable. For more advanced users, there are console utilities that allow you to watch the dependencies of individual libraries, symbol tables, how many rebase and bind will be performed at boot time. But these parameters are difficult to influence manually, especially for third-party libraries.
- Can an iOS update alone solve all problems with startup time (without additional optimization)?
Nikolay Likhogrud:The problem is that Swift is still quite young and continues to develop rapidly, regardless of iOS. Therefore, Swift Standard Libraries used are embedded in every Swift application, and therefore there is no static link for Swift. But at some point Swift stabilizes, becomes part of the operating system, they will make a normal link for it. And then all this problem with the slow launch of projects on Swift will completely disappear, after-main optimization will come to the fore, as in Objective-C. This business is not tomorrow, but the near future.
- If the problem is actually Swift's immaturity, is it really necessary to use it now? Can't I continue to write in Objective-C?
Nikolay Likhogrud:Swift is being promoted by Apple itself, and behind it is the future of iOS development. Already now there are frameworks that have ceased to develop their implementations on Objective-C. One way or another, Objective-C is slowly becoming a kind of archaic. Writing on Swift is really cool - comfortable and modern. Using Objective-C, at some point you will come to the conclusion that you do not have enough objective-c - swift interoperability to use modern frameworks or you will encounter problems hiring new developers, because most newcomers are learning Swift now. Of course, at the moment we have to deal with certain compiler quality problems, Xcode brakes, and startup time. But they will be resolved when Swift completes its development.
-Suppose we solve the problem with the launch time of the application for the current version of iOS. Can the achieved result disappear with the iOS update?
Nikolai Likhogrud: There is a possibility of changes in the iOS SDK that will lead to an increase in the user load time, but the pre-main system update is unlikely to worsen. True, each time new iOSs work worse and worse on older devices - iPhone 5 worked on native iOS 6 objectively better than with the latest iOS 10. But this will not affect top-end devices soon.
- Will you advise any sources of information on the issue of accelerating the launch of applications on Swift?
Nikolay Likhogrud: The WWDC 2016 report “Optimizing App Startup Time” is a must. Prior to this, Apple developers practically did not mention the problem, and at WWDC 2016 they dedicated a separate session to the launch time, revealed the details of the bootloader and possible sources of optimizations. There is still a good report by Mail.Ru on Habré about optimization of launch time, but, the truth, it is about an application on Objective-C, so the problem of reducing the pre-main is mentioned in passing - no deeper than at WWDC. But a lot of time was devoted to working with the profiler, after-main optimization and Continuous Integration.
As noted above, a specialist will give more detailed recommendations on optimizing the launch time of iOS applications on Swift as part of his report on Mobius 2017.
Also at the conference you will find other reports on optimizing performance for iOS:
-The Mysterious Swift Performance . Marcin Krzyżanowski, PSPDFKit GmbH;
- 60 fps UI on iOS . Sergey Pronin, App in the Air.