How to check processes and services consuming lots of battery

987 views Asked by At

I have created an app which consuming 48 percent of battery in some device which is highest in power management task, but in some device its 5-6 %, i am running a service in background all the time which fetches the latitude and longitude and send it on server if user is logged in. but i have checked also check by logging out from app it still consumes 48 percent.

to fetch latitude and longitude o am using fused location api.

So please tell me how to resolve this issue of battery consumption in some phone and how to check which process and service is draining battery.

2

There are 2 answers

0
Taylor Kidd On BEST ANSWER

I agree with Lonni that the issue is the lat/long fetch. Given the scale of the power consumed, 48%, it's unlikely to be the GPS circuitry itself. I figure it's the CPU. Mobile processors are very power efficient unless they are kept active. Let me explain. An active proessor is the most power hungry device on a mobile device. So how can a processor be the biggest power hog while also being "power efficient"? By the processor being "power efficient", I mean that when the processor isn't doing anything, it goes into a very efficient lower power state where its power consumption can be over an order of magnitude less than when in the active state.

My guess is that you are keeping the processor in an active state. What you want is to keep the processor as idle as possible.

Here are my recommendations:

  • Use the longest interval possible between lat/long fetch. A common mistake is that more checks mean better response, but unnecessary checks generally don't improve response and just keep the processor active and consuming power for no good reason.
  • Never poll! Polling keeps the processor active which consumes power for no good reason. Put the processor to sleep.
  • Use interrupts to processes events. System libraries, such as sleep(), put the processor in an inactive state, and uses an interrupt to wake the processor back up.
  • Don't write your own routine if a library routine already exists. The OS/library writers are very aware of the importance of power efficiency and have written their code to be as efficient as possible.
  • Make your code run as fast as possible. Fast means more idle time, which drops the processor into a more efficient power state. For example, if you can get along with a lat/long check every 60 sec, and you can get your processing done in 10 sec instead of 30, you have 50 sec of idle vs 30 sec.
  • Use a good optimizing compiler and good optimized mobile libraries if possible. Good compilers create more efficient, faster running code. Good libraries not only run faster, they use power efficient techniques.
  • Use a thread pool if you are using a lot of threads. Creating and tearing down threads is costly.
  • Make sure you check your API specs on your devices. I can imagine that some OSs/drivers, e.g. GPS, will require the device to be explicitly turned off, while others will do so implicitly.

Here's some more information: Battery-safe coding

Aside: I already see the thought bubble: "Why are some devices using less power than others?" Some libraries are really smart, and anticipate bad programming practices and do workarounds. Others are dumb. The same with the OS, system libraries and thread scheduling.

2
LBes On

My best guess is that the constant fetching of long and lat is draining the battery. If i remember correctly what I did a few years ago with positioning that was the case.

I would say that you should try and see the refresh-rate you want to have of your coordinates. Maybe it doesn't need to be refreshed more than 5 times per minutes. In that case you would save a lot of calls to the fetching of the coordinates and surely save your battery.

As for why it is different on some devices, I'm afraid I have no idea. Maybe the version of android used?

Edit: I don't know if Eclipse can do that and I don't think it can. However, you may want to check this paper: http://www.usenix.org/event/usenix10/tech/full_papers/Carroll.pdf