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.
Related
I have a timer app, it counts up for an indefinite amount of time (until the user stops the timer). It works much like the default iOS clock stopwatch.
I have read the articles about being a responsible background app. I don't have any UI changes happening and stop the timer when the app goes in the background and resume the timer upon returning to foreground. The app does send a local notification every 30 minutes or so to remind the user to take a break.
Problem: Without fail my app is terminated after a few hours (between 2-6 or so hours) and the current timer and info is lost.
Things I've tried:
-As aforementioned I changed my app to follow the guidelines of being a responsible background app (before I had the timer UI counting up and also the timer running, even while in background). I thought this would solve the problem since my app isn't using up much memory or doing any intensive tasks.
-I also have tried saving out the data of the current timer (to NSUserDefaults) in ApplicationWillTerminate and then restore it on DidFinishLaunchingWithOptions. It doesn't seem to work. It's almost like my app is force quit or something because if ApplicationWillTerminate was being called then it would save the data and restore it upon the app launching again. Mystery.
-Currently I'm saving an NSDate of the start time of the NSTimer on ApplicationDidEnterBackground, invalidating the timer, and starting the timer and restoring the start time upon ApplicationWillEnterForeground. Still no luck.
The thing is this is affecting a very small percentage of my users--so it's not like it's a problem for everyone, which makes it more confusing. I still want to fix it of course because it's a pretty lame bug--and I've encountered it myself (on an iPhone 5), so it's not necessarily an old iPhone low memory somethingorother problem.
This has really boggled me, I've done my research and also scoured fairly well the stack overflow questions and don't seem to find much of anything to help me.
Any help would be appreciated, feel free to ask more questions or tell me to clarify.
applicationWillTerminate is basically never called. It will not be called when your app is in the background and it gets removed from memory. You should expect your app to be removed from memory if it hasn't been used for a while. How long "a while" is depends on what else the device is doing at the time... Best to use applicationDidEnterBackground: or applicationWillResignActive:.
When your app goes into the background, record your timer's elapsed time (eg: in NSUserDefaults or however you prefer). Also record the current time. When the app comes back into the foreground, look at the two values you recorded and update the elapsed time accordingly, ie:
elapsedTime = savedElapsedTime + (currentTime - timeWentIntoBackground)
There's really no reason your app needs to remain active in the background burning the user's battery just to keep track of seconds ticking by.
Also, don't rely on applicationWillTerminate. Use applicationWillEnterBackground.
In a cocos2D powered iphone app, I use the CCRepeatForever action to make the background pass by. It works fine when I debug the app (build and run via XCode). Even if I quit the app and resume it, no problem.
However when I bundle the app into an .ipa for beta testing I get a weird problem :
At launch the background passes by nicely. But if I quit the app and resume the game later, the app takes me back where I left it, with everything working but the moving background. And after a time (roughly proportional to the time since I quitted the app) the background starts moving again as it should, without me doing anything particular.
Is this a know issue ?
Thanks
OH, I had a very similar problem a little while ago. I would pause the game, then on resume nothing would happen, then it would suddenly jump and I'd be swarmed with monsters.
I can't tell you precisely where to look, but here's what I was doing:
I had a timer that was not using the (ccTime)dt to calculate time, but was using an NSDate timestamp. The problem was that I had an event to be scheduled at a certain time based on the date, but was using the dt to figure out when to trigger the event.
As far as I could tell, pausing the game was halting the scheduled events, so the "dt" wasn't incrementing at all, but the system clock kept ticking, so what ended up happening is that I would pause for say 10 seconds, the system clock ticked up and triggered, but the "dt" was adding into a float timeElapsed, and until that caught up, nothing happened.
What you probably need to look for is something inside a scheduled event that is using an NSDate or a unix timestamp or the iPad/iPod system clock. When you halt the simulator, the system clock doesn't seem to run the same way it does on an actual iPad.
Sorry, I don't know EXACTLY how this stuff works, but I also went through an agonizing time with a similar problem and it was based on the system timer. Just make sure you're pausing everything with the CCDirector properly and make sure you're not using any system clock stuff for game timing
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.
When I run my Iphone app on my Ipod touch, it runs fine most of the time. But every so often, it will hang for a short while -- anywhere from 5 to 15 seconds. After the hang, it resumes running normally.
The strange thing is that to all appearances, the app's demands on the system should be fairly steady. It is doing a lot of dragging stuff around with calls to TouchesMoved. But it drags a maximum of two labels at a time.
How might I go about tracking down such a problem?
A good start would be to run your app under Shark to see where it is spending most time during those periods.
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.