When I launch the app on my 3GS it sits on the Default.png for 4-5 seconds. I'm not sure what it is doing during this time. I placed NSLog timing statements at the top of main and didFinishLaunchingWithOptions. The NSLog statement from main does not print to the console until the moment that Default.png goes away, and the entire process from the top of main to the bottom of didFinishLaunchingWithOptions only takes 1 second.
So, what is my app doing before it starts main, and what can I do to speed that time up?
Don't start from Xcode with a debugger, that takes a lot of time. You will see that your app starts much faster when you launch it via the icon on your homescreen.
I suggest you look at your plist file and xib files (not 100% sure if root view gets loaded before or after main, but worth a shot). Also, how big is that png file? Try launching without it and see how long it takes.
Does your application do this even when there are no other programs resident in memory? The reason that I ask: since you have observed that the delay appears to happen prior to entering main(), then it is possible that iOS believes that more memory is needed in order to run your program. If there are other apps in the Suspended state, then iOS could be busy waking those apps up momentarily in order to invoke didReceiveMemoryWarning on their view controllers, and perhaps ultimately tell them to go away by calling their app delegate's applicationWillTerminate:. Perhaps this is what is taking time.
One easy test you could perform would be to completely reboot your phone and then launch your app a few times without running anything else first. After the first invokation of your app, I would expect it to start quickly (unless your app, itself, allocates a lot of memory!).
If you didn't want to reboot your phone, you could manually remove all of the apps from your multi-tasking switcher by closing each one by touching the red minus signs that you can bring up using touch-and-hold. Then run your app and see if you are still seeing the 4-to-5 second delay.
Related
I have an app where I have 5 sets of animations that I'm storing in an array. The animations get picked to play randomly after a button touch. This is all working perfectly, however I noticed a bug when I quit the app and reopen immediately, I'll see my main view, then it'll jump to my second view that has the animation in it. (This shouldn't happen since you have to tap the main view in order for it to modally swap in the second view. If I interact with it everything works for a few seconds, then it closes with no crash log.
I finally realized that some of the objects must not be getting released fast enough, since if I close the app and wait three seconds, then reopen, everything executes fine.
I didn't want to put down code to show as this is more of a brainstorming question. I'd love any insight that could point me the right way. I changed a lot of my code to get rid of convenience methods and have all my variables defined and then released in my dealloc.
Is there a way to truly tell the app to kill everything on quit? It's not set to run in the background so this is a bit odd. Thanks for your help I'm still new to this and learning!
Alright, after working on this all weekend and doing more research comparing a barebones version of my app to my prerelease version, I traced memory leaks to the Flurry Analytics api that I am using. Apparently I was suffering from the same issue as the post here: App hangs on restart with latest Flurry SDK and ios4 . I resolved this by setting these optional methods to false, since they take extra time to send data after the app terminates, and depending on the connection it takes a few seconds.
FlurryAnalytics.h
/*
optional session settings that can be changed after start session
*/
+ (void)setSessionReportsOnCloseEnabled:(BOOL)sendSessionReportsOnClose; // default is YES
+ (void)setSessionReportsOnPauseEnabled:(BOOL)setSessionReportsOnPauseEnabled; // default is YES
Hope this helps anyone else who experienced something similar to me!
All apps can enter the background by default. Normally they do not do anything there, but they stay there in a frozen state and when you open them again, your program does not restart, it just picks up where it left off.
Anything that's set as an animation delegate might not get released, since it's retained for that purpose until the animation completes.
You can add an applicationDidEnterBackground: method to your app delegate to get informed when your app is going into the background, but exactly what you need to do depends on the design of your app. You can also add applicationWillEnterForeground: to do anything you need to do differently when restarting, as opposed to newly starting.
You might be able to force your animations to complete by starting a new animation with duration 0.0 (or very short if for some reason you can't do that).
If this happens only if your app goes to bkgnd and comes back AND you don't mind if the app restarts everytime it comes back then just put UIApplicationExitsOnSuspend in your app's plist. In all my cases where these and other bad things happen with apps going to and returning from bkgnd this helped.
While you might still see the app on the buttom when double tapping it is really stopped and will restart. Apps that show on the buttom do not always have to run or be stored in the bkgnd I learned.
ps. don't forget to set the value of UIApplicationExitsOnSuspend to YES
Consider an app that was in the multitask bar, and was closed, clicking on the minus sign.
What is supposed to be the behavior of this app at restart?
Does the app restart from scratch with the splash screen and without old data?
Or does the app load saved data and restart without splash screen and with previous data reloaded?
Thank you.
The application should restore its previous state in as many cases as possible. Prior to multitasking, all the applications tried to do this, to give the users the impression of multitasking. With multitasking in iOS 4, this doesn't change. You still need to do this to:
Support older devices.
Keep the user experience the same even if the user opens tons of apps and the device frees memory automatically.
If its closed then it will start from "scratch" unless you use the app delegate methods which are fired to store data and create the functionality to reload somewhere specific in your app yourself.
The splash screen will show if there is loading time needed, just like when you start an app the first time.
I think a user who clicks the minus is probably doing it, either just to clean up, or because he/she would like the app to return to it's beginning setup, just as if the device was reset.
I handle the minus, just like that, and start fresh with the splash screen. (not sure what the apple guide recommends)
This operation (tapping on minus icon) is intended for freeing memory.
When Apple has introduced multitasking in iOS, usage of memory has increased a lot!
So, why you have to tap on minus to kill application? When do you have to do this?
When your device responsiveness is too bad.
After killing (closing) application, when you restart the app, it start from scratch or resume last operation depending on how the application has developed!
For example, look at FacebookApp. If you are logged-in and quit app, at next restart it's reopen your account and last page seen!
For something like a game, I would suggest you restore the user's state ONLY IF they were in the middle of a game, else just start from scratch. However, for anything else, always start from scratch.
If you do nothing, your app will probably start from scratch at the moment.
In one of my apps when returning from background I get a non consistent behavior:
Sometimes I get the default.png and sometimes I get a snapshot of the last screen which the app was in.
In both cases it takes the UI a good second or two to respond again.
Therefore I would rather show the default.png rather then "unresponsive UI"
Is there a way to make the app display the default.png always until the app becomes active again?
Currently the "stupid" way to do it I thought about is by displaying some Modal view with the default.png and removing it on return to foreground.
Few Clarification:
I am doing this to avoid unresponsive UI.
I am using the default.png as it looks like loading and gives a better experience then unresponsive UI
The app has to run in background.
(And to whoever asked - no it is not closed when I sometimes return and see the default.png and not the last UI state - App loading from the start has a very different path and I'm sure of that)
Thanks in advance.
This is not a correct behavior and you may experiencing a bug. Basically as long as your app is in the background, when you launch it, you should not see the default.png, unless you remove it from background (double click on home button and delete that app).
For future people interested in this you can use the fact the last view in the app is used to be displayed when the app loads back.
You can display a VC as your moving to background which will represent some loading - hence achieving the desired behavior.
I've already seen a few other apps using the same behavior in cases operations are ran when coming back into the app.
Most probably, you are taking too long (performing too many calculations) in methods such as applicationWillEnterForeground:, applicationDidBecomeActive:, etc. As a simple test, try commenting out the code in these methods and see if the problem occurs again.
Simply set in your Info.plist the property "Application doesn't run in background" to YES. The app will never go in background and when the home button is pressed it will be simply terminated. So you're back to the pre-iOS4 behavior.
Note that when you see now the default image at start-up it is simply because your app has been terminated while it was in background. This is normal especially for apps that take a lot of memory and then don't free it enough before going in the background (I think the threshold for the OS is about 18MB but I'm not sure)
I'm doing performance testing on my iphone app and I'm noticing that sometimes a good 3-4 secs elapse at startup before I start seeing my NSLogs from applicationDidFinishLaunching. I've optimized what happens once the code enters applicationDidFinishLaunching but I'm not sure how to optimize what goes on before that. I'm using a Default.png splash screen so it basically just stalls on that screen before it enters applicationDidFinishLaunching and starts doing something.
Just to give you guys some context, I have no nib files and I'm using core animation, if that makes any difference. I have about 10 different controllers and my total bundle size is just under 2MBs.
Try running it without the debugger attached - one of the things it does on startup is wait to connect to your mac ;)
If you just run it in the device without your mac connected do you still see the delay?
I did some experimentation a little while back and found that default start time for most apps is 3 seconds or more.
I was annoyed that the voice memo apps took up to 10 seconds to launch by which time I had forgotten what I was going to say. I tried to write one that would launch faster and by using a default.png and starting the recording automatically I got a recorder that constantly launched in 1-1.5 seconds. To get that launch time, I had to start the recorder before the interface became active.
However, in this research I found that most apps e.g. an app compiled straight from an Xcode template without modifications, launched in 3-5 seconds.
Based on that fact, I would say you really don't have a problem. The startup time falls in the expected range. deanWombourne's observation about the debugger is most likely correct and it probably adds a second or two to your startup time.
I'm debugging slow startup of an iPhone application (Xcode, Objective C++). It's a tabbar-based app with three tabs. All three tabs are loaded in a single NIB - about 20 objects total.
The first round of significant initialization takes place in the viewDidLoad handler of the first tab's view controller. However, it takes about 1 second between main() and that method's start time - about 2/3 of the total loading time. Question - what is going on during that time, and how do I investigate that (short of stepping through the disassembly)? To the best of my knowledge, there's no my code in between the two moments - the delay happens entirely in the system code.
Maybe some kind of Instrument that can give me per-function time profile?
The bundle is ~4 MB total, but I'm loading the biggest file (~3.5 MB) later than that, in the applicationDidFinishLaunching handler. Removing that file from the bundle and commenting out the relevant code does nothing for that 1-second delay.
UPDATE: there was debug interference after all. If I run it on the device while watching the console, the startup time us considerably shorter, and the proportion of delay - system code to my code - is skewed, too. But still, there's a noticeable delay between main and viewDidLoad, and it's about 50% of total loading time.
By the way, of all ways of loading a largish file from the bundle completely into memory, the fastest one was direct memory-mapping (using POSIX mmap()).
If you really are curious about what's executing during startup, and the relative times each method takes to run, you can create a custom DTrace script to track this. I describe how to do that towards the end of this article. This script will show you every method executed by your application in order from startup to the end of -applicationDidFinishLaunching:, along with the time spent in that method. You can run this script as a custom instrument in Instruments or as a standalone script (the standalone script tends to be more accurate on a system under load).
The major caveat of this approach is that it will only run in the Simulator, given the current lack of support for DTrace in the iPhone OS itself. However, you should be able to extract the order in which things are executed in your application's startup, as well as relative times that your application spends in each method. This will even show behind-the-scenes private API calls being made as your application starts, which might provide some additional clues as to what's going on.
For additional startup tuning suggestions, I'd recommend reading James Thomson's article "How To Make Your iPhone App Launch Faster".
There are two things that could be going on here. If you're debugging your app from within XCode, there's a good chance that the application is waiting at startup to attach to the GDB debugger. In my experience, that takes about a second. Try running your app without saying "Build and Go" in XCode and see if the results are any different. (Just click it from the home screen instead)
Your NIB file might also be the issue. 20 objects isn't too many, but you might consider breaking each tab into a separate NIB file if all else fails. The contents of NIB files referenced from your primary NIB file are lazily loaded, so the app will not load views for the two tabs that are invisible until they are selected. That might give you a performance boost at startup, though I don't think it could account for a full second.
Apple's got some great performance analysis tools in the iPhone SDK, but they're a bit hard to find. In the Run menu, select "Run with Performance Tool" -> "CPU Sampler." That will launch a separate application called Instruments which allows you to do all sorts of great runtime analysis. When you have the CPU instrument selected, the bottom half of the Instruments window provides a breakdown of what was taking CPU time in your app. You can double click functions to dive into them, and get a line by line breakdown of % of cycles used. It should give you more information about what specifically is causing your problem.
I'd recommend splitting up your app into three NIBS; the tab bar and the tab bar controller displayed on launch in the first, then lazily load the other two the first time the user switches to them.
I believe you can use the File >> Decompose Interface function in Interface Builder to accomplish this.
If you found your xib files are too large, I advice you build your UI with pure code.
large xib files will surely slow your startup time, and also slow your app when you first use an object in your xib.
I don't use xib in my projects, cause when somebody changed the xib in svn, you can hardly find what is changed. That's to say, xib is not going well with SVN.