AndEngine - Battery drain & device heating

0
votes

I've developed my game using AndEngine and have one serious problem. Users report me that game heat device too much and drains battery. I don't understand why it's happen because game is just simple puzzle and I don't use complex animations or physics. Also, I disabled updates for major part of sprites and set wakelock options:

engineOptions.setWakeLockOptions(WakeLockOptions.SCREEN_ON);

but this not helps. You can see game here: https://play.google.com/store/apps/details?id=com.icecat.hex

I'll be happy to ask any questions about code. Please, write what do you think about possible problems or engine settings that can cause this problem.

1
androidandenginebatteryoverheating
"on my machine it works fine" ( meaning: one user? really? this should be device specific ) – Najzero
Unfortunately, I have many reports about this problem, so I think it's not device-specific – Dimmerg
having an old S2, cant see any unusual heat ( level 1 running ). As I am not doing anything, maybe user interaction causing the heat – Najzero

1 Answers

1
votes

SUMMARY:

• Never poll for user input

• Check for user input at best >250 msec

• Polling will kill your power efficiency

• Checking for user input <250 msec won’t give a faster response time and will negatively impact your power efficiency

DETAILS:

Something to check is how you are waiting for user input. I believe the ARM Cortext A8 processor architecture (the basis for S2 I think) has advanced power management features. By this I mean it has processor idle power states, meaning the processor will go to sleep when not doing anything like waiting for user input.

A mistake that is very common is to either poll or to check for input too much. We say to ourselves that "I need to respond to user events as fast as possible," and then poll or interrupt to check for input at <10msec periods.

There are two problems with this. The fastest human response is >.25sec. When we include any thinking on the part of the user, this becomes >.5sec.

There are a few big issues with this, one of which may be contributing to your problem:

  • Best user response is >.25sec

  • Add in the computation of your program, the lower bound of your app's response may be >>.25sec

  • Most importantly, doing excessive checking prevents the processor from going to sleep, and going to sleep is how the processor saves most of its power. Going to sleep and waking up has no almost no impact upon performance since the processor isn’t doing anything by definition and waking up introduces no significant latencies (<<500usec and likely closer to 100usec).

If you want to know more, check out "List of Useful Power and Power Management Articles, Blogs and References". The later work references HPC (High Performance Computing) and Intel architectures but the principles and techniques apply to all modern processors including tablets and phones.