How to reduce the time to launch applications for iOS
Mobile processors and memory are getting faster, and applications are still loading. What is the salt? The question of the launch time of iOS applications is taken by the mind of more than one developer (especially after switching to Swift). We decided to find out the reasons for the long load and solutions to this problem from Nikolai Lihogrud, the developer of Mobile Yandex.Map.
Under the cut: typical rakes, useful tools and the right approach to solving performance problems.
- Please tell us in a few words about yourself and your work.
')
Nikolai Lihogrud: 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 guidance of Yuri Podorozhny. For some time I worked there on various projects, gained experience, and after our transition to Yandex, I switched to Mobile Yandex.Maps. I have been in this project for almost 3 years, I have been working as a team leader for the last year
- What role do experiments with accelerating the launch of iOS applications play in your work?
Nikolai Lihogrud: Startup time is one of the key indicators of a 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 its improvement.
- Where does the struggle to reduce the application launch time stand in the overall sequence of work to improve the performance of the application?
Nikolai Lihogrud: It all depends on what your application is written on - in Objective-C or Swift, and on which device park it is oriented. Objective-C applications run faster in principle due to the fact that Objective-C runtime libraries are built into the system, and Objective-C code can be compiled into static libraries. This eliminates the resource-intensive loading of dynamic libraries at startup. With Swift, the situation is completely different - even an empty application on iPhone 5 loads for 2 seconds. Therefore, for Swift, the launch problem comes out on top.
- Are there any typical rakes (related to the speed of launching applications), which developers most often “attack”?
Nikolai Lihogrud: One of the main problems is the use of pods written in Swift, since in this case, all CocoaPods targets are collected in separate dynamic libraries. Even if there is not enough code in the project in the main target, submissions to Swift can increase the launch time several times.
- Is it possible to deal with them somehow (besides the obvious solution - not to use CocoaPods with Swift)?
Nikolai Lihogrud: Yes. There is a method that allows, on the one hand, to tighten dependencies through CocoaPods, but on the other hand, not to compile them into separate dynamic libraries.
- Are these “rakes” relevant to all versions of iOS (Swift)? Or does each version have its own “gentleman's set” of pitfalls?
Nikolai Lihogrud: At the moment this is true for all versions of Swift and for all iOS, both old and new. Loading of user 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 time for verifying the signature of dynamic libraries, but the situation has not changed radically.
- From what, in your opinion, do you need to start working towards optimizing the launch time of the application?
Nikolai Lihogrud: The first step is to turn on the environment variable DYLD_PRINT_STATISTICS and see how much time is spent on the pre-main and after-main - that is, on the part of the launch, for which the system is responsible and directly your application. This will allow you to identify exactly where the problems are - in your code or in the work of the system loader, which collects the application image in memory. Further actions depend on the measurement results. There are ways to reduce the time of the system part of the boot, and your code is optimized as usual - the profiler helps a lot.
- As part of your report on Mobius 2017, will you talk in more detail about the system part of downloading applications to Swift?
Nikolai Lihogrud: 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 pre-main time. I will also touch on the optimization of my own code - there were some simple moments in our project, which gave a good increase. Perhaps this experience is useful to someone. But in general, after-main optimization is related to the more general task of optimizing iOS applications, so I will not dwell on it in detail, since 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 to work on accelerating the launch of the application?
Nikolai Lihogrud: The main tool is the variable DYLD_PRINT_STATISTICS, which displays the statistics of the system loader. It is also possible to output loadable dynamic libraries through the variable DYLD_PRINT_LIBRARIES. For more advanced users, there are console utilities that allow you to view 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 the iOS update alone solve all the problems with the launch time (without additional optimization)?
Nikolai Lihogrud: The problem is that Swift is still quite young and continues to grow rapidly, regardless of iOS. Therefore, used by Swift Standard Libraries are built into every Swift application, and therefore there is no static linking for Swift. But at some point, Swift will stabilize, become part of the operating system, and make a normal link for it. And then the whole problem with the slow launch of projects on Swift will completely disappear, the 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 in Swift immaturity, then is it really necessary to use it now? Is it possible to continue writing in Objective C?
Nikolai Lihogrud: Swift is promoted by Apple itself, and the future of development for iOS will follow. Already, there are frameworks that have ceased to develop their implementation in Objective-C. Anyway, Objective-C is slowly becoming some 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 objective-c - swift interoperability is not enough for you to use modern frameworks or you will encounter problems in hiring new developers, because most newbies are learning Swift now. Of course, at the moment we have to face certain problems of compiler quality, Xcode brakes, start-up time. But they will be solved 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 iOS update?
Nikolai Lihogrud: There is a possibility of changes in the iOS SDK, which will lead to an increase in the time of the user part of the download, but the pre-main time will not worsen the system update. True, each time new iOS is getting worse and worse on older devices - the iPhone 5 worked on native iOS 6 objectively better than from the latest iOS 10. But this will not affect the top devices soon.
- Would you recommend any sources of information on the problem of accelerating the launch of applications on Swift?
Nikolai Lihogrud: The WWDC 2016 “Optimizing App Startup Time” report is a must- read . Prior to that, Apple developers practically did not mention the problem, and at WWDC 2016 they devoted a separate session to the launch time, revealed the details of the bootloader and possible sources of optimizations. There is also a good Mail.Ru report on Habré about the optimization of launch time, but the truth is, it deals with an application in Objective C, so the problem of reducing the pre-main is mentioned in passing - no deeper than at WWDC. But a lot of time is spent working with the profiler, optimizing after-main and Continuous Integration.
As noted above, the specialist will give more detailed recommendations on how to optimize the launch time of iOS applications on Swift as part of their report on Mobius 2017.
Also at the conference you are waiting for other reports on the optimization of 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 rakes, useful tools and the right approach to solving performance problems.
- Please tell us in a few words about yourself and your work.
')
Nikolai Lihogrud: 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 guidance of Yuri Podorozhny. For some time I worked there on various projects, gained experience, and after our transition to Yandex, I switched to Mobile Yandex.Maps. I have been in this project for almost 3 years, I have been working as a team leader for the last year
- What role do experiments with accelerating the launch of iOS applications play in your work?
Nikolai Lihogrud: Startup time is one of the key indicators of a 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 its improvement.
- Where does the struggle to reduce the application launch time stand in the overall sequence of work to improve the performance of the application?
Nikolai Lihogrud: It all depends on what your application is written on - in Objective-C or Swift, and on which device park it is oriented. Objective-C applications run faster in principle due to the fact that Objective-C runtime libraries are built into the system, and Objective-C code can be compiled into static libraries. This eliminates the resource-intensive loading of dynamic libraries at startup. With Swift, the situation is completely different - even an empty application on iPhone 5 loads for 2 seconds. Therefore, for Swift, the launch problem comes out on top.
- Are there any typical rakes (related to the speed of launching applications), which developers most often “attack”?
Nikolai Lihogrud: One of the main problems is the use of pods written in Swift, since in this case, all CocoaPods targets are collected in separate dynamic libraries. Even if there is not enough code in the project in the main target, submissions to Swift can increase the launch time several times.
- Is it possible to deal with them somehow (besides the obvious solution - not to use CocoaPods with Swift)?
Nikolai Lihogrud: Yes. There is a method that allows, on the one hand, to tighten dependencies through CocoaPods, but on the other hand, not to compile them into separate dynamic libraries.
- Are these “rakes” relevant to all versions of iOS (Swift)? Or does each version have its own “gentleman's set” of pitfalls?
Nikolai Lihogrud: At the moment this is true for all versions of Swift and for all iOS, both old and new. Loading of user 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 time for verifying the signature of dynamic libraries, but the situation has not changed radically.
- From what, in your opinion, do you need to start working towards optimizing the launch time of the application?
Nikolai Lihogrud: The first step is to turn on the environment variable DYLD_PRINT_STATISTICS and see how much time is spent on the pre-main and after-main - that is, on the part of the launch, for which the system is responsible and directly your application. This will allow you to identify exactly where the problems are - in your code or in the work of the system loader, which collects the application image in memory. Further actions depend on the measurement results. There are ways to reduce the time of the system part of the boot, and your code is optimized as usual - the profiler helps a lot.
- As part of your report on Mobius 2017, will you talk in more detail about the system part of downloading applications to Swift?
Nikolai Lihogrud: 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 pre-main time. I will also touch on the optimization of my own code - there were some simple moments in our project, which gave a good increase. Perhaps this experience is useful to someone. But in general, after-main optimization is related to the more general task of optimizing iOS applications, so I will not dwell on it in detail, since 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 to work on accelerating the launch of the application?
Nikolai Lihogrud: The main tool is the variable DYLD_PRINT_STATISTICS, which displays the statistics of the system loader. It is also possible to output loadable dynamic libraries through the variable DYLD_PRINT_LIBRARIES. For more advanced users, there are console utilities that allow you to view 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 the iOS update alone solve all the problems with the launch time (without additional optimization)?
Nikolai Lihogrud: The problem is that Swift is still quite young and continues to grow rapidly, regardless of iOS. Therefore, used by Swift Standard Libraries are built into every Swift application, and therefore there is no static linking for Swift. But at some point, Swift will stabilize, become part of the operating system, and make a normal link for it. And then the whole problem with the slow launch of projects on Swift will completely disappear, the 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 in Swift immaturity, then is it really necessary to use it now? Is it possible to continue writing in Objective C?
Nikolai Lihogrud: Swift is promoted by Apple itself, and the future of development for iOS will follow. Already, there are frameworks that have ceased to develop their implementation in Objective-C. Anyway, Objective-C is slowly becoming some 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 objective-c - swift interoperability is not enough for you to use modern frameworks or you will encounter problems in hiring new developers, because most newbies are learning Swift now. Of course, at the moment we have to face certain problems of compiler quality, Xcode brakes, start-up time. But they will be solved 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 iOS update?
Nikolai Lihogrud: There is a possibility of changes in the iOS SDK, which will lead to an increase in the time of the user part of the download, but the pre-main time will not worsen the system update. True, each time new iOS is getting worse and worse on older devices - the iPhone 5 worked on native iOS 6 objectively better than from the latest iOS 10. But this will not affect the top devices soon.
- Would you recommend any sources of information on the problem of accelerating the launch of applications on Swift?
Nikolai Lihogrud: The WWDC 2016 “Optimizing App Startup Time” report is a must- read . Prior to that, Apple developers practically did not mention the problem, and at WWDC 2016 they devoted a separate session to the launch time, revealed the details of the bootloader and possible sources of optimizations. There is also a good Mail.Ru report on Habré about the optimization of launch time, but the truth is, it deals with an application in Objective C, so the problem of reducing the pre-main is mentioned in passing - no deeper than at WWDC. But a lot of time is spent working with the profiler, optimizing after-main and Continuous Integration.
As noted above, the specialist will give more detailed recommendations on how to optimize the launch time of iOS applications on Swift as part of their report on Mobius 2017.
Also at the conference you are waiting for other reports on the optimization of performance for iOS:
- The Mysterious Swift Performance . Marcin KrzyĹĽanowski, PSPDFKit GmbH;
- 60 fps UI on iOS . Sergey Pronin, App in the Air.
Source: https://habr.com/ru/post/325796/
All Articles