I am developping a relatively simple frame based iphone game, and it runs quite smoothly. However, when I switch views and then back again a couple of times everything starts to lagg severely.
Maybe someone recognizes this as a simple programming problem. (e.g. not setting iVars to nil, not switching views correctly, loading too much variables at the same time, etc.)
NOTE: this happens only after having switched views over 10 times.
Related
I've seen a lot of questions like this, none of which work because they're in an old version of Swift (all the dispatch_global stuff).
My game currently freezes for several seconds before switching scenes. Any way to have an animation while the next scene loads?
I'm building an iPhone app (in iOS 5) with several different views, one of which contains a map (also has separate view controller). The first time I go over to this view, it takes a while for it to load, and things such as animating pin drops also don't work well as a result of it. Not to mention that it takes a bit for the location to stabilize.
What I want to know is if there's a way to load MKMapView before a user goes to that view, so by the time they get there, these issues aren't present anymore.
I've already seen this and this question but they haven't been very helpful. Keep in mind that I don't really need to interact with that view before I get there, I just want it to be fully loaded by the time I go there.
I am working on an OpenGL application for the iPhone...
My app has only 2 views:
An OpenGL view and, as a subview for the OpenGL view, a view with the sole purpose of catching touch events...
The problem is that after about 10-15 minutes of keeping the app running on the device, I get a big (0.5s-1s) delay between every touchesMoved:withEvent: call
The animation runs smooth, and CPU usage is also not the problem (10% at most)
I have no idea what might be causing this
That is weird, eh.
This happens ON THE DEVICE right? When you are not running tethered from XCode?
I would guess you are using up a lot of memory, either a leak or just in some way using up more and more memory as time goes on.
Are you familiar with the various memory tools to watch what is going on?
Also, what about this: launch a few other large apps that remain in the background. Run your app until the problem exhibits. Then, kill the other apps. Does the problem suddenly go away? If so that would suggest you're low on memory.
Would be interested to hear.
I have a game that runs fine as is (around 30fps), but fps went down the drain when I tried to implement ads. I tried Greystripe and iAds but with same result (iAds were maybe bit worse). Average fps is almost same, but there are huge spikes all the times (1-2 spikes per second) and game is unplayable.
I guess it is because ad is in another view. I read somewhere that opengl apps on iphone don't like having another views with them, but there is plenty of games with ads on app store. How do they do it?
My implementation should be ok. I did everything as documentation and samples told me. I have my opengl view and ad view as subviews in app window, adview being in front of opengl view and thus covering part of it. Could this be the problem? Is it better to make opengl view smaller to left space for ad so they don't overlap? Do you have any other ideas what could be wrong?
Lope, I've created a gist at this link with a singleton "AdManager" class I wrote to handle iAds using cocos2d. Cocos2d sits on top of OpenGL, of course, and I've found that this code doesn't affect FPS even for relatively complicated games.
You'll have to modify this a bit to work with your application, changing out the cocos2d calls, etc, but this will give you asynchronous loading of iAds, which should help the FPS issue.
To use this class, include its header and call
[[AdManager sharedManager] attachAdToView:self.view];
wherever you need iAds. The ads will remain hidden until an ad loads, at which time they'll pop up at the top of screen. (The class works for iOS 4.0, 4.1 and 4.2).
Also, I should add that I have cocos2d running inside of an overall UIViewController that I call "Cocos2DController". When I attach the ads to a cocos2d view, I'm using
[[AdManager sharedManager] attachAdToView:[[CCDirector sharedDirector] openGLView]];
Best of luck!
We can hit and miss with apple's choices, but go for the sure thing and implement the ads in other parts to be appealing and not intrusive. It will be better for the framerate, and for you.
Try downloading the ads in a seperate, low priority, thread. You can, thus, nsure that the ads loading does not take too much CPU time. With a bit of CPU synchronisation you can make sure you don't try to display the new ad until it is completely ready to display. Sure it will suck some CPU time away from what you are trying to do but set your priorities right and it should only suck time when you are busy doing nothing.
Please excuse the thread necro'ing here, but I've used Stack Overflow a lot to help me through the problems I've had during coding, and thought my experience might be useful to someone in the future.
My simple cocos2d game ran with decent FPS (rarely changed the FPS display at all) until I implemented AdWhirl (integrating AdMob + iAd only). It would then run OK for the first few iterations, but upon upon the 9th or 10th scene refresh (single screen game, time in each scene < 5 seconds on average) the FPS would dive to ~20FPS, and drop again each time the scene refreshed.
Turns out, in my n00biness (this may be particular to me :) ), I was calling the scene from within itself. That is, once the actions had finished, the last action was to call the main scene again (a lazy way of rebuilding the scene for the user to have another go). This init'd the views and view controllers I had inserted to handle the AdWhirl ads all over again, and not only did I have a memory leak, I had 10+ view controllers all trying to request and service ads from AdWhirl. Once I got a clue and took that self-referring loop out, all was good.
I was wondering if there is a difference between using .xib files for GUI design and doing this programmatically.
As it is a compiler I would assume that there is no relevant time lost.
Am I wrong?
(Note: Tapping this out on my phone, so I apologize ahead of time for any weird formatting or grammar - if there are issues, I'll fix them when I'm back at my laptop.)
I've done some quick, dirty, and extremely informal tests to check this out for myself, and here's what I found (note that the app I built for the tests was just scratch and not necessarily representative of a "real" app):
Startup time was faster when when the initial screen was a nib
For all subsequent screens, performance increased when coding the UI by hand
It's odd at first, but when you think about it, maybe it isn't really all that strange.
The startup issue confuses me, but I assume it's because Apple, being Apple and being obsessed with startup times (in a good way, of course), just optimized the phone's unarchiver in such a way that loading from an archive (nib) can be faster than coding by hand.
That said, most people write apps that aren't going to be significantly affected by any differences. My (again: quick and dirty) tests showed that, from a cold start (you haven't run the app yet or in a while), the nib-based app consistently loaded its initial screen about twice as fast as the hand-coded version. While that sounds like a big deal, we're talking just a few milliseconds. That difference will be imperceptible to users. For a warm start (you've already opened and closed the app), the differences for startup time were much smaller.
For this reason, I like to use nibs for laying out the foundation of an app: any top-level navigation (tab controllers, nav controllers, etc.), and then code the rest of the UI by hand.
Plus, because the iPhone UI is so specific to, well, the iPhone (surprise!), coding UIs by hand isn't difficult the way it is when writing desktop apps. You use the same UI components over and over - once you've got that down, whipping up a UI in code is easy. You don't have eight-billion widgets to choose from as you would developing a Windows/OS X/whatever application. The iPhone's consistency makes it the easiest platform I've developed against in ages when it comes to hand coding UIs.
I've also found that NSCoding (which is what I use for persisting state across app runs) is much easier to work with when I've hand-coded a UI. I've run into problems where a nib-based screen wouldn't properly archive because of UIImage instances. UIImage (at least the last time I checked) doesn't conform to NSCoding, so the archive process dies (and a rather unpleasant death it is). I used UIImage as an example here, but anything the archiver tries to store that doesn't conform to NSCoding is going to foul up the process, so that's something to think about.
Another time I always code UIs by hand is whenever I'm using a dynamic table. If I'm creating a static table - one whose cells will basically never change - nibs are fine. For any other kind of table, and especially those that have, say, thumbnails and other resource-intensive bits, the control I get when coding by hand makes it possible to get performance you aren't going to get with nib-based table cells. For that, you do have to skip CocoaTouch and work directly with CoreGraphics, but the performance improvements you can make are worth every last line of code you have to write. For examples of table performance from projects I've worked on, see the Barnes and Noble Store (not the ebook reader) and Style.com. We built a framework for those (and other) apps, and the secret to the smooth table scrolling is that we never once used cells loaded from nibs (it's more complex than that, but skipping nibs was the first step to getting the performance you'll see in those apps).
Generally speaking, possibly the most important thing to consider when using nibs is that you need to break your UI up across files. That is, don't stick your app's entire UI into a single nib. When a nib is being loaded, it's the whole thing - there might be a view in the nib your users will rarely, if ever, see, and those get loaded just like everything else, sucking up resources for no reason. If you don't use separate nibs for each of your app's screens, it's easy to run into memory and performance issues.
To further clarify: if you have an app with five view controllers, stick each controller in its own nib. You don't want to load anything until its needed. There are exceptions to this, but that's simply how coding is - given enough time, you'll find a reason to do something "the wrong way," but the a-nib-for-each-screen approach is the way you ought to be doing it unless you have a good reason not to.
I'll leave it there - I hope it helps a little.
Just remember:
My informal mucking around showed that startup was faster with a nib (as long as you keep the nib as simple as possible, keeping only what you need in it).
After startup, performance seemed to improve for hand-coded UIs.
If done correctly, and if you aren't writing a game or something, nibs shouldn't result in perceptible performance issues.
In my experience, tables are different - they're one place I will rarely use nibs.
If you're using NSCoding for persisting app state, nibs can be problematic, and any workarounds probably aren't worth the effort since coding iPhone UIs by hand is relatively easy.
Keep your nibs as simple as possible - I can't say this enough. Wherever possible, create a nib for each screen of your app rather than stuffing your entire app's UI into a single nib.
Ok. Stopping for real this time.
Hope this helps :)
Very little. There are some exceptions. For example, if you use a xib to load the image that goes into a UITableViewCell, then that could be a problem since UITableViews with many cells are sensitive to loading times. However, for all intents and purposes, there should be no noticeable performance hit.
The information in the xib does have to be decoded at runtime and loaded into memory, which is not as fast as just creating UI elements programmatically and directly.
Beware premature optimization, especially when it involves writing a great deal more code than you need to.