This may sound like an odd question, but has anyone noticed that their iPhone apps launch quicker when built for distribution over being built for debugging?
Our app initially launches really slowly when compiling it for debugging / running it through xcode. (on device)
So I then dis-connected the phone from xcode and ran some extremely unscientific tests... (To try and quantify the slowness of the app)
Turned iPhone off then on. Booted my app. Counted to 6 mississippi's.
Closed app, re-launched it. Counted to 4 mississippi's.
Turned iPhone off then on. Booted 'contacts' app. Counted to 2 mississippi's.
Closed 'contacts' app, relaunched it. Counted to 2 mississippi's
The reason I compared to the contacts app is that it's pretty similar, UIWise to my own app. (Although its probably doing a lot more than my app is in the background).
My app is a navigation based app and the root view has the following elements:
UISearchBar
UISwitch
UIImageView
3x UILabels.
Not exactly a tasking amount of elements to initially load, so if there isn't a slight speed increase when building for distribution, I need to try and find the cause of whats taking the app so long to load!
One thing I thought could be the issue is that I'm using interface builder for the layout of my view(s). Could I be taking a loading hit as the initial view de-serializes?
Thanks for any input,
Jon
It's because the Distribution configuration is usually duplicated from the Release configuration in xcode, and has the "Strip debugger symbols" option turned on. Stripping symbols only used in debugging means there's less to load - which makes it faster.
I've noticed this before. I've always assumed that it has something to do with the iPhone interfacing with the Xcode debugger. I'm just guessing here, but I just tell myself it's telling the iPhone about any breakpoints and what to do when it hits them and stuff, among other "stuff". The iPhone is also probably talking to Xcode about keeping stuff in sync in case of a crash or something.
Related
I recently created an app in flash cs6 to be used on my iPhone 4.
The app doesnt need to work through the app store its just a tech demo but when i put the app on my device all the animations become really slow/choppy.
My iPhones up to date and im using air3.2 (i did try updating to air 3.7 but then my application just became a white screen)
I have also tried cacheing all the movie clips as bitmaps bit it doesnt seem to make a difference.
(the app works fine inside the flash simulator)
please help?!
There could be a few reasons why this is happening,as I am taking a punt here as you havent gave much information on what your doing.
but your frame rate may have effect.. how are you creating your tweens?timeline animation or tween scripts.I found tween scripting works better as its distance over time opposed to distance over frames.
Also depending on your animation, images sizes, event listeners etc..
You need to take inconsideration your device itself and the resources it has available, free memory or actual storage available.
The reason it will work freely on your PC would be due to the fact of less limitations, your pc has more to computes and resources to throw at your application .
Add this line to your code to check your memory:
import flash.filesystem.File;
this.addEventListener(Event.ENTER_FRAME,performMemTest);
function performMemTest(e:Event):void {
trace(System.totalMemory);
}
I have read anywhere around 14MB++you may experience problems.
First of all I want to say that I'm I aware that my question is probably way too vague to answer and may be closed/down-voted. I just hope for some inspiring brain-storming on possible solutions.
Here's the story:
My app was crashing on iPad 2, but not on iPad 1. I've fixed the crash related to unarchiving nib and now I have a very strange problem - my universal app still runs without any problems on 1st gen iPad with iOS 4.2.1 and 4.3.3, but not on (some/all?) iPads 2 with 4.3.3. Unfortunately I don't have an access to iPad 2 with iOS < 4.3.3 to test further and narrow down the problem.
My app has it's main screen displayed by using presentModalViewController. My modal VC is MGSplitViewController (it mimics native UISplitViewController and enhances its functionality). When my VC is presented, only "root view" is displayed and remaining part of screen for "detail view" is just black and empty however the controller is loaded and active (debug logs are printed etc.).
So on iPad 2 I have access to, it fails to display detail view properly, however I've heard from one user that it's fine on his iPad 2 (both iOS 4.3.3). App also works ok on iPhone/iPod regardless iOS version, so I assume it's related only to iPad code of my universal app.
I believe it may be more general issue with displaying views. I've tried to read view property of my detail view, which should force view to be displayed, but it didn't help. It may also be related to IB stuff (the initial nib unarchiving crash only on iPad 2??), but I think everything is wired ok in IB...
Anyone has a slightest idea how to investigate this problem?
EDIT: BTW: My iPad 2 is giving me hard time as it drops Wi-Fi connection very often. Other people are also reporting this kind of "feature". Can it be that it's just something wrong with my iPad 2?
EDIT2: the app is also not correctly displayed on iOS 3.2, 4.2 and 4.3.3 Simulator (via XCode 4), but gets displayed correctly on iOS 3.2, 4.2 Simulator via Xcode 3. Strange, isn't it?
Anyone has a slightest idea how to investigate this problem?
If you'll allow a somewhat vague answer to a somewhat vague question, then yes, I do have an idea.
To approach problems like this in general, bisection of the problem field is a great way to go forward:
You identify the general problem area. Could it be presentModalViewController in your case?
Then about halfway through the code in question, you set a breakpoint/write a message to a log file/play a sound/send a mail/tweet/whatever it takes to verify that your code has come that far without a crash.
Run it and see if your message has been produced.
If it has been produced, the problem is not in the first half, so it must be in the second half (a log message at the end of the identified problem area is useful, too, just to make sure that the crash actually happens before that).
On the other hand, if there is no trace of your log message, then the crash must occur in the first half, and you can rule out the second half of your code for this particular problem.
Now you repeat the algorithm by setting your breakpoint/log message about halfway into the culprit half you just identified.
Repeat until you find the problem. It won't take many iterations.
Of course, the crash may be due to some variable stored at a previous step or in another method, but now you know where to look.
Initially the app was crashing due to unarchiving the nib. I don't recall the exact crash output, but it was quite strange for me that same nib was properly unarchived on iPad 1 with same OS version, so I suspected that the problem lies in xib file... I've recreated the xib from scratch routing everything carefully and - bam! - it started working on both iPad 1 and iPad 2! How come some nibs aren't unarchived in a same way on same OS running different HW???
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.
I have an app that has a tabBar Controller and a navBar Controller. It has ~8 views (a variety of web, table, standard, mail, address etc.), some created using IB some created using XCode to make the table views. I've ran the memory leak tester and it doesn't have memory leaks. It can crash at anytime on any of the views, If I flip back and forth between views and use some of the functions it closes the app.
I assume that either I am running 1) out of memory or 2) not releasing views correctly, which causes the app to close. The app is simple so I don't know how I could be out of memory and I've reviewed the code to the best of my ability for releasing the objects correctly.
So Here is my list of questions:
1) What and How to use some of the other debugging tools (or tell me what tools/files I should be looking for using)? I would like to narrow down the problem to its source.
2) What is the best practice for releasing these views? How?
3) How much memory do normal apps use? Is there a number that I should stay around? How do I verify that in the simulator? the Allocation tool?
Feel free to point me to apple docs or other stackoverflow questions that can help me.
UPDATE: It appears to only be crashing one view is used, which has a table view with custom cells... The cell are populated from a plist file... this view worked fine a few days ago, I notice that some cells do not have data from the plist file... it could be a plist file problem with not storing proper data. I'll continue to work on it.
UPDATE #2: I went back to older rev of my files, to when this particular tableView worked just fine (pre 3.0) and guess what it works just fine, I change the simulator to 3.0 with this rev of the app and bam crash on this tableView shows up. Thanks for the help so far, I'll try somethings mentioned below and let you know what I find. If you have some tips on why a tableView w/custom cells from 2.2.1 to 3.0 would start crashing, I'll take them. If I can't get anywhere I'll post the code soon. BTW, I mis-spoke above, I thought it wasn't crashing in the simulator... I was wrong it is.
Solution: thanks for the troubleshooting tips the fix was quite simple, but it's odd it didn't crash in 2.2.1... it should have crashed a long time ago for the problem, I was releasing an object one to many times in my custom cell... duh.
On the first and second generation phone's you really don't want to be going over about 20 megs of real memory usage - once you get over that you are at risk of being killed by springboard.
One of the big culprits I've seen is autoreleased memory, since the autorelease pool can hold onto memory a lot longer than you would really like - if you are using a lot of autoreleased objects that can be a potential problem. You can improve this by doing more explicit retain/release where possible and by creating local autorelease pools manually and releasing them after doing a more intensive operation with a lot of autoreleased objects.
The most effective way to keep track of real memory usage I've found so far is running a debug build on a test phone and running with Activity Monitor. That will give you a clear idea of how much memory is getting taken and held onto by your app. As well as how much is being used when it crashes on you.
You can run with Activity Monitor in Xcode on the Run menu -> Start With Performance Tool -> Activity Monitor.
One other very useful tool is the CLang Static Analyzer that you can run against your code base and can give some very helpful memory management information. As mentioned here.
One thing I would try is putting some debug messages into your didReceiveMemoryWarning method(s). That way, if you are running out of memory, you'll at least have some warning.