I'm trying to find ways to reduce load times for a large application.
Here is some background:
The app uses a lot of the iphone frameworks (openGL,mapping,location,quartz,audio) as well a few libraries from other sources (JSON, ARKit, Flurry, Facebook connect)
The code + nib size is around 3.5MB with about 150 source files.
The app compresses to around 2.5MB.
Load times are around 13s on an iPhone 3GS. The actual time spent in my code is only around 1s. (from the start of main() to the end of applicationDidFinishLaunching)
The app delegate has references to most of the view controllers in the app as they are referenced from many places and often store persistent information.
Everything in the app is already lazily initialised so I can't just do things later on.
Is there anything I can do to reduce the load times in this case or is this just how long the device takes to load all the code into memory? I don't know very much about how compilers/linkers work so I was wondering if there are any coding practices that can reduce load times?
13 seconds is incredible. Linking to a few libraries should not take that much time.
Note that running it while attached to the debugger will make launching slower, because GDB spends a while looking up symbols or something like that.
Related
I am developping my first application on iOS. I am on this language since few days and I am going to share this application in Apple Store ASAP. But I have a big question around architecture.
Currently, I have with about 40 different type of Views, others components and a lot of PNG (30x30). I know that I can reduce considerably the number of Views through the development of a small framework but as it's my first learning-by-practice application, I wanted to move on quickly about all standards components and to start this development without architecture, reusables class or design pattern ... without think too hard.
To be short, I am wondering about the real size of applications in production and the performances. Have we got some constraints with:
Apple Store (upload apps)
Ram Capacity of iPhone during using
Download application from apple store for the user
etc...
Basicly, is it acceptable to have with about 40 screens for an iPhone Application?
Best regards.
There is a limit of 50 MB for over-the-air downloads.
Number of screens is probably not going to be a problem. The amount of executable code associated with each screen is probably not going to be significant. The bigger issue is how much PNG data you are going to have embedded in the app. A single 30x30 PNG isn't very big. 40 of them probably won't very big (depending on how well they compress). But if you have dozens of them per screen, or if you have a big hi-res background image for each screen, then the total amount of data could get big.
My advice would be to just start developing everything in the most straightforward way you can. Don't worry about sizes until you have some evidence that it may be a problem. And do a lot of testing on an actual device (don't rely on the Simulator) running whatever the oldest OS version is that you are willing to support.
I have an iPad app that has a process for downloading lots of map files (a couple of gigs of data and 10s of thousands of files).
In my most recent test release, the device will sometimes reboot during the download process, (downloads can take a couple of hours).
When the app reboots, it does not leave a crash report. We have observed this behavior on both an iPad 1 and an iPad 2 running 4.3.3.
The only thing I can think of is we increased the max concurrent threads from 4 to 20 for doing these downloads.
Completely exhausting the system memory triggers a hard reboot of the device. This used to be more common in iPhone OS 2.0, running on the limited hardware of the initial iPhones and iPod touches. In recent OS versions, Apple has more rigidly enforced the hard kill of your application when it exceeds its memory ceiling, so it's become much harder to do this. Also, the devices have much more memory than they used to.
One way that you can sometimes do this is by loading many large textures or other graphical components that may not be immediately identified as memory used by your application. I've been able to cause a system reboot when loading a pile of data onto the GPU in a tight loop. You may be encountering something similar here.
I doubt that this is related to the number of active threads you have going, although they probably make it easier for you to dump a mess of data into memory before the system can kill your application.
As an aside, rather than having piles of threads, which consume resources, have you looked at using GCD or a queue-based framework like ASIHTTPRequest? These might be more efficient for your application, yet still provide the concurrency you need.
Your app is crashing most likely due to memory management. Since you are downloading several GB's of data, maybe you are running out of disk space? I am not sure why it would take your device several hours to reboot.
Try posting some code.
Have you debugged in Instruments? This will show you if allocations are rising and filling memory. If you are attempting to load these GBs into memory, then of course your going to experience a crash.
Also, have you looked at dispatch_apply instead of threads? GCD automatically distributes and increases/reduces the threads it uses based on load. This way you don't have to manage this yourself. It might be worth a shot.
I'm having frequent crashes on iOS 4.0 within my application due to excessive memory. Instruments tells me that it's category is "Malloc 600KB" and the responsible library is ImageIO and the responsible caller is ImageIO_Malloc. I'm using lots of images in this app but no more than I have used in other applications. It's odd because if I run the same code on 3.0 then I have no real problems and on 4.0 sometimes it will jump from 5MB to 30MB Memory even if I haven't touched it and it hasn't loaded any new images (as far as my knowledge goes).
Does anyone have any ideas or know how I might find the source of the problem?
Thanks in advance!
Something I've noticed about every iPhone app I've tried is that they all have places where they seem very slow and unresponsive. It's true of the games, the free apps, the pricy, popular, "professional" apps, and even a couple of Apple's built-in apps. They all seem to have places where they take many seconds or even a minute to respond to screen touches; bog down and show a spinning beachball for seconds at a time; "queue up" input so that a button press appears to ignored only to actually do something ten seconds later like a poorly made DVR; and lock up for so long that the OS watchdog just kills them.
Because these perf issues are so widespread it seems to me that there must be some common performance pitfalls some system gotchas that are coming up over and over again for lots of different people. I'm not an iPhone developer myself, so I'm canvassing the community's opinions:
What are the most common performance mistakes on the iPhone?
Or, what human factors of iPhone development make it too easy to ship with poor performance?
I think that the performance issues are a matter of perception. Apple has employed animation throughout every aspect of the iPhone's interface, which produces the impression of a smooth, responsive device. The slowdowns you refer to appear much worse than they might be because they stand out from the otherwise fluid interface. If you compare the total execution times of these tasks to similar applications on other mobile devices, I'd guess that the iPhone implementations would still come out near the top.
There's always room for improvement, though, and I'd expect that many of the tricks people have learned in the last year will lead to faster, more responsive applications. Even the development tools themselves are advancing, and that should make it easier to diagnose and deal with performance bottleneck. I know I keep learning new tricks every week for squeezing a little more out of the CPU, GPU, or onboard memory.
I'm still surprised by how quickly people have shifted their expectations as to what handheld devices can do. I'm the author of an open source application called Molecules, which does 3-D molecular modeling on the iPhone. A little over ten years ago, these types of renderings were being done on dedicated SGI Irix workstations. A few weeks after the launch of the App Store, I started receiving emails from people complaining that the application was a little jerky when they tried to manipulate molecules with over 20,000 atoms in their structure. In a very short time, people went from treating these devices like phones and music players to viewing them as portable computers.
Memory management is a bit of a beast.
But I think the biggest problem is this: How long can you afford to polish a product that will sell for 99 cents and compete with tens of thousands of other apps and has unknown revenue potential in a rapidly changing market?
The iPhone is a GREAT little device, but the competition for mindshare is fierce and expensive.
As mentioned before the ratio of profit/time spent in development would explain it.
More technically, I would say that the lag you see is created on startup when apps are either getting data over network or calling home to check for updates and so on. Additionaly it may be created with initializing application like loading large amounts of data from database/files, loading gui components and images, drawing and so on.
Similar to memory management this all can be solved by designing operations to run in background, lazy loading and so on but that requires more time, time is money, you don't get much for 99C app which may or may not sell at all.
It is interesting that so many times it is pointed out in professional articles (no ref...) that we should not care anymore about memory and speed because desktops are getting faster with more memory. What people tend to forget is that at the same we're trying to squeeze more power from smaller and smaller devices that are running with smaller resources.
Most web pages for example are nowadays designed to load huge amounts of animations and images and, unlike some, are not tweaked at all for performance but do just okay on desktops. Those web pages have no chance of loading on mobile device. The same goes for applications, designing a fat big framework (or gui widget library) for desktop will make it ultra difficult to port the functionality to sleek mobile device be it iphone, some fruit berry and what not.
As in other things in life, you get what you paid for.
My 99C.
I think the biggest issue is that it's impossible to determine the speed of an app without actually running it on the device. Developers perform most of the basic app testing in the iPhone Simulator (which can run up to 1000x times as fast in my experience). Some operations that take a split second in the simulator might require a progress indicator on the phone, and by the time you realize, it would require a lot of effort to go back and add (and in some cases thread) the operation in question. As Noshredna pointed out, it's generally a 99c app.
The iPhone's processor is also just fundamentally limiting. I've seen several nice looking apps that try to do very impressive things without accepting the constraints of the platform.
This is sort of a side note, and I don't want to start the mobile platform wars, but I've found that iPhone Apps are generally more responsive than Android apps...
Well, because maybe you deleated the app and install again because something wrong happens to it, so it must took awhile, it took me about 2 or 3 days to get full loaded so be patient, it will come eventually. Also maybe your iphone doesn't have any more spaces for your app, or your app is quite heavy, try and delete other apps so it will have rooms.
As anyone with an iPhone knows, some applications launch quickly, while others take several seconds.
What are the best techniques for ensuring an iPhone app launches and becomes usable in a snappy manner?
Apple recommends you "lazy load" every view. I.e. only load the first page on start up, and other pages only when they are navigated to.
In terms of graphics, use PNGs wherever possible as the device is heavily optimized for this format.
Also include the startup screenshot so the user knows the application is loading.
I use lots of external resources, so I use Lazy loading to get up and running quickly. This way the APP can start with the barest minimum and then load the rest while its already begun.
Made a big difference in start time
This is one of those things where there is no sure-fire path to success. Use Apple's excellent Instruments tool to monitor your application's launch. You then need to delve into the results to figure out ways to optimise the launch process.
Also try profiling with Shark, to find any performance bottlenecks.
http://developer.apple.com/iphone/library/documentation/DeveloperTools/Conceptual/SharkUserGuide/Introduction/Introduction.html