I have an iOS Xcode project that previously would load fast, but from time to time, now will hang for five seconds or more during loading. When the app is run on an iPhone, the launch screen displays instantly, but sometimes, not always, and unpredictably, the app just hangs for around 5 seconds or more until the actual interface is displayed. It occurs both on the simulator and device across different iOS versions 7, 8, 9.
Recently, a UIView's class that contains a drawRect function was changed slightly, it has an outlet connection to one of the ViewControllers, but no significant changes made overall. One ViewController has code in the ViewDidLoad, ViewWillAppear, ViewDidAppear functions. All these things I'm investigating if they are impacting the load time.
When I terminate the app, the next time I try running it, it loads super fast without issue. I have no idea what to make of this load behaviour.
Questions
1 - What methods can I use in Xcode to debug an app that loads slowly at irregular and unpredictable times?
2 - What obvious items should I be on the look out in the project that typically cause slow or prolonged load times?
3 - Does Xcode include tools to monitor the processes operating live while loading occurs?
4 - Is it possible to print output for load processes I can review?
Any experienced advice really appreciated. Thanks.
Not sure if you have looked instrumentation. It is the best way to determine this kind of issues with your app.
https://developer.apple.com/library/watchos/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/index.html
When I terminate the app, the next time I try running it, it loads super fast without issue. I have no idea what to make of this load behavior.
Do you mean exiting the app? Or actually killing it? Cause if it is the former, then the reason is the app was just launched from a suspended state.
I would suggest take a closer look at didFinishLaunchingWithOptions:, and check if you are doing something that takes more time than needed. Run your app with the time profiler instrument, it will tell you where is your bottleneck.
Related
I have an Electron app (running on a Mac) that waits in the background for a key press, before showing a window.
If I leave it in the background overnight and then use it, it will be very slow for the first 10 seconds or so. It seems like updating the DOM and inter-process communication are both slow. The delay isn't coming from my code, and it seems to affect the renderer process primarily. After the initial slowness, it starts working normally.
Is there any reason that an Electron app would do this? Is it getting unloaded from memory somehow?
What's odd is that the initial display of the window happens instantly; it's just after I start to do some inter-process communication that it slows down.
There are a few possible answers to this, but after spending countless hours figuring it out, I thought I'd share the one that worked for me.
I was showing an animated SVG when I put the app in the foreground, and hiding it when I put it in the background. Apparently this was queueing up animation frames even while hidden, and then un-queueing them when it was shown, causing the delay.
It was fixed by upgrading Electron from 8.5.5 to 9.0.0, which I believe upgraded Chromium from 80.0.3987.165 to 83.0.4103.64. Not sure what the exact fix was, but it worked.
My iOS app launch screen takes about 3 - 5 seconds. I have a map that will load after the launch screen. My users have to wait for the launch screen to load and then wait another 3 seconds for the map to load.
Is there a way to minimize launch screen time?
Basically this delay means that you are doing something very wrong during launch. Your job is to launch immediately. Indeed, the WatchDog app will kill you dead if you don't.
There are excellent WWDC videos on this topic, and you should watch them. But in general there are two ways to go wrong:
You must do nothing time-consuming on the main thread. If you have a time-consuming thing to do, like loading your map or networking, you must do that on a background thread. You need to get out of the way so that the runtime can launch your app now.
Just the other way around, you must not touch the interface on any other thread but the main thread. Doing this wrong causes just the kind of delay you are reporting. Do your work on a background thread, but then get back on the main thread to talk to your views, view controllers, etc.
Finally, I should point out that you might be able to get some idea what you're doing wrong by using Instruments. Unfortunately it works rather badly against app launch, but it can be worth a try. Above all, watch those videos!
I am developing my first iOS app and I am almost ready to submit to app store. However, I am having problems with launch time. It is taking ~3 seconds to launch. The app has a ContainerView with three UIViewControllers as Child View Controllers. The middle UIViewController is a camera and the left and right UIViewControllers are mostly made up of UITableViews that make basic network queries (not on main thread) to populate them. Basically, I am trying to figure out why my app takes 3 seconds whereas apps like SnapChat and Instagram take <1 second.
I tried seeing what was taking so long using Time Profiler in Instruments. There were a couple easy fixes but now I am stuck. It says 357ms are from main but when I double click on it, it just takes me to AppDelegate and shows me that AppDelegate is accounting for 100% (of the 357ms? - correct me if this is wrong). But this isn't helpful because I know that main() is to launch the app (?) but it isn't telling me anymore. Whereas when I click on other methods listed it breaks it down for me (i.e. what each part of the code is accounting for). This is my first time using Time Profiler and any help would be greatly appreciated.
While attempting to optimize load speed I started placing timers in different places and looking at the performance. The app uses OpenGL and Core Data and has a decent amount of screens and artwork.
But the largest part of the lag seems to be taking place prior to applicationWillEnterForeground (assuming it's not a cold load)
The app shows up and is displayed and the UI is unresponsive for close to 5 seconds. I start a timer and print a time as soon as I can press a button. The time between applicationWillEnterForeground and when I can press the button is 200 milliseconds.
What can be causing my application to be slow to load prior to applicationWillEnterForeground or what can I do evaluate what is happening there? Instruments does not seem to display any information about that part of the launch.
Other testing app I have don't seem the same performance. Is it the bundle size or the amount of memory used by the application? Loading dynamic libraries?
This was related to OpenAL. The app was not closing the OpenAL context and for some reason this caused considerable problems when closing and reloading the app. The app uses CosCos Denshion so I to make sure to call these.
[CDAudioManager end];
[SimpleAudioEngine end];
I am getting a strange behavior when I reopen my app after it loses focus from the home button. On the simulator the app screen goes black for 5 seconds or more before the application is resumed. On the test device, the application either does the long delay or quits entirely and resets to starting state. I have put NSLog debug comments in the “applicationWillEnterForeground” and “applicationDidBecomeActive” but these only appear after the long delay so I will assume for now that nothing in these functions cause this delay.
I am using the following components in my program:
* a Tab Bar Controller
* 2 Timers, the Map kit
* IP socket streams
* 24 ViewControllers strung together on a storyboard.
* quite a few background images and image buttons
I would happily post code if I know what parts of the program was causing this error, but as it is I am clueless. Has anyone else experienced this type of error? Do any of the components I have listed have a history of causing similar errors?
I was quite far in development when this bug was discovered and I did not test for loss of focus via home button during the incremental development process. Other, smaller projects (which used sockets and timers) did not suffer from the same bug on the same test hardware.
I am using “applicationWillResignActive” to disable the timers, and close the streams. I am using “applicationDidBecomeActive” to restart the timers, and reopen the streams. The delay is occurring before “applicationWillEnterForeground” and “applicationDidBecomeActive” is run. Further more I tried disabling the code that initiates the streams and timers, but this did not have any effect on the bug.
I am using xCode4.4.1, ios6, and am building exclusively for iPads.
It's possible that the debugger is playing tricks with your mind regarding when it shows that you hit a breakpoint and the code execution of applicationWillEnterForeground. I suggest you commit your most recent code to source control and start deleting sections one at a time till you see the behavior go away.