Any improvements you make to rebase/binding time will also apply to this setup time. ObjC setup time The Objective-C runtime needs some setup for class registration, category registration and selector uniquing. Using Swift Structs is also generally faster. If your app uses C++ code use less virtual functions. Apps with large numbers of Objective-C classes, selectors and categories can add 800ms to launch times (large is 20,000). To speed up rebase/binding time you need fewer pointer fix-ups. Rebase/binding time fix-ups adjust pointers within an image (rebasing) and set pointers that point to symbols outside the image (binding). To speed up dylib loading Apple suggests you use fewer dylibs or consider merging them A suggested target is for six extra (non-system) frameworks. The loading of Apple system frameworks is highly optimized but loading your embedded frameworks can be expensive. Each library can itself have dependencies. WWDC 2016 Session 406 Optimizing App Startup Time goes into detail on each of these steps together with tips for improving times but here are my quick notes:ĭylib loading time The dynamic loader finds and reads the dependent dynamic libraries ( dylibs) used by the App. The output shows you the total time taken up to the point the system calls your application main() followed by a breakdown of the main steps. When testing for slow app launch times remember to use the slowest device you support (if you can). LibSystem.B.dylib : 6.58 milliseconds (8.8% ) libBacktraceRecording.dylib : 6.27 milliseconds (8.4% ) Total pre-main time: 74.37 milliseconds (100.0% ) dylib loading time: 41.05 milliseconds (55.2% ) rebase/binding time: 8.10 milliseconds (10.9% ) ObjC setup time: 9.87 milliseconds (13.2% ) initializer time: 15.23 milliseconds (20.4% ) slowest intializers : The pre-main time of under 75ms is well within target: Here is a typical output for an Objective-C project running on an iPad Air 2 (using iOS 10 beta 3). To try it out add the environment variable DYLD_PRINT_STATISTICS to your project scheme with a value of 1: With iOS 10 Apple has made the output from enabling DYLD_PRINT_STATISTICS much easier to understand. It has been possible to add the DYLD_PRINT_STATISTICS environment variable to your project scheme but the output was hard to figure out. Before iOS 10 it was not easy to understand why an app was slow to launch for reasons other than your own code. Pre-main TimeĪ lot happens before the system executes your app’s main() function and calls app delegate functions like applicationWillFinishLaunching. You control what your application delegate does but how do you debug slow startup times that happen before your code is even called? Here is a tip from WWDC 2016 that might help. Apple suggest to aim for a total app launch time of under 400ms and you must do it in less than 20 seconds or the system will kill your app.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |