I have an app that I added a lot of animation to. The app also used "iPhone sleep preventer" to play silent audio. Since then, I noticed that the battery consumption increased by up to 4 times! I'd like to find a method to profile the power consumption (I think I saw an option in Instruments) to find and eliminate the offending method(s).
Where would I start looking for information like this? Currently I have the phone left on the desk for ~3 hours to record power drain over time. Is there a better method to predict when the app will run out of power if running my app continuously?
An extra side question: are the % of battery left displayed in the status bar linear or is there some non-linearity towards the end of the battery life?
Edit: I found a "power" preset in xcode>product>profile>CPU>Energy diagnostics. It doesn't seem to work perfectly, as the power consumption level is always 0/20. But it does tell me how much of the CPU time is spent on app foreground, graphics and music!
Now I dont know how the CPU power is managed, is running the CPU at 75% more power consuming than lets say 30%? Intuitively it feels like it should...
Thank you!
I'm no expert. Im fact I am only starting to power profile a iphone today, and looked upon your question here in hope off learning.
So I will share with what I've found in meanwhile.
On IOS Developer Library I have found the following:
Connect the device to your development system.
Launch Xcode or Instruments.
On the device, choose Settings > Developer and turn on power logging.
Disconnect the device and perform the desired tests.
Reconnect the device.
In Instruments, open the Energy Diagnostics template.
Choose File > Import Energy Diagnostics from Device.
And you have a report of Cpu and energy during the time of the log.
You can find this steps and many more info on this section of the IOS Dev. lib.
I am still a bit fresh on this matter, so if you find anything that you think is meaningful please post that info here.
Edit: The apple dev lib suffered some changes. Updated link
Related
I am in the last phase of my iphone game development: optimization and performance tuning. My problem is, the game runs quite smooth on iphone 4 and iPad, but it often crashes on iPhone 2 with iOS 3.1.3 due to low memory.
I have gone through all the memory leak detection / clean up processes, and the Xcode instrument shows no leak except those from system library (see following screenshot). I also use "autorelease" rarely.
(bigger picture: click here)
I also profiled my application using "CPU Sampler" and "Allocations", but is a little confused by the result. This is the result from "Allocation" benchmark:
(bigger picture: click here)
This is the result after one game. As you can see, the "Live Bytes" is only 3.93MB, which shouldn't be a big deal (according to my understanding) -- but the game often crashes at this time on iPhone 2, ios 3.1.3 .
I also did a "CPU sampler" benchmark, following is the result:
(bigger picture: click here)
What confused me is, the real memory shows "22.32MB" and the virtual memory is more than 100MB, which is dramatically different from the result of "Allocation benchmark".
I am also confused by the fact that, my iPhone 3G, running iOS 4.1, even if it has almost exactly same hardware spec with iPhone 2, can run my game very well. It's slow and not as snappy, but it rarely crashs.
So my questions are:
What else I can do to identify the low memory issue on iphone 2?
Are the leaks from system libraries on the "Leaks" profiling result a problem?
Why "CPU sampler" and "Allocation" shows different memory foot print? Did I read them correctly?
Why iPhone 3G runs a lot more smoother than iPhone 2G? Is it because the newer iOS version (4.1 vs 3.1.3)?
1. What else I can do to identify the low memory issue on iphone 2?
Run your app in iOS simulator and use Hardware menu item "Simulate Memory Warning" item to trigger Out-Of-Memory events in places, which you suspect to crash.
Instrument your app in real device, but before launching it start as many other apps as possible to reduce amount of available memory. While running your app, switch every now and then back to app grid to (re)launch other apps. This way you will make system generate genuine Out-Of-Memory events, but you can't choose which app will receive them.
You could generate OOM events by yourself, but then you would be running a different application. Might be useful, while developing, but not recommended when close to release. Very annoying to debug bugs caused by debugging "helper" routines...
2. Are the leaks from system libraries on the "Leaks" profiling result a problem?
They could be side-effects of your code. Look around which part of your app might be starting that system service and whether you release / cancel / close everything.
3. Why "CPU sampler" and "Allocation" shows different memory foot print? Did I read them correctly?
No idea, but would like to know :)
4.Why iPhone 3G runs a lot more smoother than iPhone 2G? Is it because the newer iOS version (4.1 vs 3.1.3)?
iPhone 3G has better, faster and more hardware than iPhone2. As result, apps seem to run faster... which can be a problem, if your app runs too fast in faster hardware. Making sure your app runs "just right speed" regardless of hardware is a different question.
I'm currently testing the latest iOS4 Feature to put my location aware app in the background. Well, it does work! But on the other hand it's quite hart to handle the immense power usage.
The app consumed about 50% battery power in the last four hours. It read the entire official documentation by Apple on this topic but I'm still not sure which parts of my application are still running and which functionality is suspended (beside the UI Drawing, which should be clear).
I don't use any real boilerplate code but extended libraries like ASIHTTPRequest to talk to my webservice. Tests with a friends car did you show that the Network Connectivity and and the Location Services is still running when I'm using i.e.
[locationManager startMonitoringSignificantLocationChanges];
Apples Documentation on the different application states
Background: The application is in the background and executing code
[...]
Should I write a "bare metal" functions to receive and send this location data? Should I remove all other objects for the time the application resides in the background to reduce the memory footprint? It seems there isn't any best practice yet.
Any ideas? Maybe you guys can provide me with some of your insights. Thanks.
Edit:
There's a new Instruments tool called Energy Diagnostics Instruments to record any power usage (for iPhone 3GS and later) with an attached device. Also there's another service on the device in the Settings App -> Developer -> Power Usage. It's great to test your power usage in field. The created logs can be pulled later in instruments.
Reference: WWDC 2010 Session 309 - Advanced Performance Analysis with Instruments
Sounds like your app is transmitting location data over the cellular network. Turning on the cellular radio is one of the most rapid causes of power drain, especially if the user has a weak signal connection to the cell tower.
You might want to save and package up a bunch of location data, and send the data in a quick burst as seldom as possible (twice per day, when the user stops moving for 30 minutes, only after the user gets to one of their favorite restaurants, etc.) Turning on the radio less than half as often could get you close to doubling the battery life (unless the user is doing something else with the device as well).
I have an iPhone app (Objective C++). My beta testers - some of them, not all of them - are complaining of slow startup, 7 to 10 seconds. On my device (it's a 3GS), it loads in about 2 sec. On the device simulator - even faster. As things stand now, I cannot even isolate the bottleneck.
Can I somehow slow down the simulator or a fast device? Setting the simulated hardware version to 2.0 does not help.
As a last resort, I could try and borrow an old, slow device from a friend for a night or two. But I'd rather not...
If I were you I'd try profiling the startup with Shark - it's hard to profile startup on the device, one way is to put a 5-6 second sleep statement in ApplicationDidFinishLaunching so you have time to attach Shark and start recording, don't make it too long though or the app will be killed!
Also consider what you are doing on startup that might be a lot longer for some people - looking at address records, or things like that.
Aral Balkan links to some nice tools by Mike Shrag that allow you to get the old slow motion simulation mode on triple shift working in SDK 3. Speedlimit - which allows you to throttle network bandwidth might be useful.
This is an old question, but one option is to use a non-SSD iMac or MBP to test on a slow environment. The latest Xcode versions and simulators (XC version 7 for sure) run extremely slowly on non-SSD devices. More slowly than any actual phone...
I have tried Instruments and Shark to profile an iPhone app, but both use a data sampling approach, by regularly taking screenshots of thread stacks.
I would prefer to have a full coverage profiling tool, which would record every single function call and the time spent in functions and their subroutines. This seems intuitively better than getting samples. Something like AQtime on Windows would be great.
So my questions are:
Can sample-based profiling be trusted and be as useful as function-call-based profiling?
Can Instruments or Shark do this type of profiling?
Are there other tools available, which would be closer to what I want?
I've found that the time profiling used by Shark is very accurate for determining what your bottlenecks are in your code. You can adjust the sampling interval to be more fine-grained by showing the Mini Config editor using Config | Show Mini Config Editor and lowering the sample time.
Instruments in Xcode 3.2 also now has a nice Time Profiler instrument, although that's Mac-only. I've found that Instruments works well for profiling, but it can drop samples if the system is under heavy load. Generally, I start with Instruments, given how easy it is to use, then move on to Shark if I need a more detailed view of what's going on.
If you really want to do function-call-based profiling, I'd look at DTrace. I've written a couple of articles about tuning Cocoa applications using DTrace here and here. The latter one even shows an example of tuning the startup time of an iPhone application using a custom DTrace script.
Unfortunately, DTrace currently does not run on the iPhone itself, but you can still gather a lot of interesting information using it by running your application in the simulator. While the exact timing information will be nowhere near what it is on the device, knowing exactly what methods are executed how many times and in what order can give some clues as to where to optimize. I use DTrace to provide a different perspective on information gathered by Shark and Instruments, and to answer specific questions about my application.
Yes, stack sampling can be counterintuitive, and yes it can be trusted. Look at this link, and the first comment.
It's not about asking "How long did this take?"
It's about asking (in a doubtful voice) "Was that nanosecond necessary?"
I don't have an iPhone Developer Program Account yet and will be getting one in the next couple of days. Can instruments be used with the simulator to give a rough estimate on how well my app may perform? Using instruments I checked and fixed all the leaks it was detecting, and it appears that my memory usage maxes out at about 5.77mb. Is there any other tests I could perform with instruments to judge how well my app would perform? I realize there is no way other then the actual device to get a definite answer, it would be nice to get an estimate.
Keeping memory under control is a good first step. Also, make sure you're not allocating too many objects, as all those allocations can take time (use ObjAlloc to check this; it can show you things that Leaks cannot).
Comparing performance between the Sim and Device is pretty much pointless... you have effectively unlimited memory can CPU on the desktop. Best wait until you get your app installed on an actual device.
You could test with a jailbroken device while you're waiting for your developer account. By the time you get your account, you would have time to fix any potential problems, and only need to recompile with your new credentials and deploy.