Optimising Android application before release

Question

I'm in a "special" situation about efficiency of my program. Now I'm at a phase where I need to improve the performance of the application and reduce battery consumption.

Before the question:

• First of all, my application work. It runs fine - no errors whatsoever.
• Secondly, I have read Optimizing Battery Life on Android developers website and I have optimised small things they've requested. No problems whatsoever.

Now, I'm curious to know about other developers' special fixes which they have used to optimise their own applications. Stuff that users may never recognise or pay attention to. However, the fixes will either increase the battery life or help improve maintenance of the application.

So, what's your unique optimizing trick(s)?

I'm in a particular situation where I'm really looking for knowledge and I think this will be a great opportunity to share developers knowledge about a situation they've all been in.

Please, vote up great answers as that will encourage great developers to share their knowledge.

Solution 1

At some point you are going to get to the point where using known tricks will hit their limits. The best thing to do at this point is profile your code and see what areas are the bottle-necks based on your specific requirements.

Investigating RAM usage using MAT and Using Traceview: an article on how to use the tools to profile your application.

Solution 2

Track and squash allocations. The more you allocate, the more often the garbage collector will need to run, stopping your process from doing anything else for relatively long periods of time, such as 100ms or so.

The best tool I know for this is the Allocation Tracker included in DDMS.

Not only GC can have an impact on the user experience, but superfluous allocations and GC do consume some computing resources.

Here's an example and a small trick. In my app, I have a clock which shows the current (audio) time, including tenth of seconds. This is updated often. And TextView performs allocations internally whenever you call setText() with a CharSequence. But it doesn't allocate anything with the setText(char[] text, int start, int len) variant. This isn't documented, and no one answered when I asked about it.

There are many ones like this. And this is one of the reasons why my app contains 50% native code (but there are other reasons).

Apart from this, I can recommend that you experiment with ProGuard. It performs several optimization passes, and logs such informations as unused methods within the project, which can help you removing leftovers in your code.

Solution 3

If your app will have a lot of screen time, use black wherever you can. That will reduce the battery consumption of the worst part of the device: the screen, specially in the AMOLED phones and tablets.

Solution 4

For applications with multiple activities, check you are not restarting activities that just need to be brought to the front by using the appropriate Intent flags. Check that your heap is under control, and that unnecessary views, bindings and contexts aren't being created.

I find the best tool for showing you all these as the app runs is:

adb shell dumpsys meminfo 'your apps package name'

Solution 5

When using SQLlite, put special attention on indexes. Don't assume anything. I got tremendous speedups in Zwitscher, when I put indexes on columns commonly used for search.

View more solutions

Comments

[Wroclai]

Thanks! I really like answers with resources. :-)

[Wroclai]

Great answer! Concrete tricks are appreciated.

[Wroclai]

Oh, that was new. Thanks for sharing!

[Wesley Wiser]

I remember reading that somewhere, could you provide a link?

[Alistair Collins]

Not so sure that is true for final variables, but can be for static final variables - see stackoverflow.com/questions/3117770/…

[Wroclai]

Thanks for insight! I have never heard about this!

[Stan]

Can't provide the link but i met a notice about it in "Beginners guide to android" by Reto Meier (may 19 2010)/Google IO. It's short, it's free to download and it has good advises on how to build a good app.

[Robert Massaioli]

Judicious use of dark colours means a win for the battery.

[Robert Massaioli]

Final variables could make code more efficient because it will mean that all of the objects will be GC'd in the same run. Not at different times based on when you set them to null.

[Sparky]

On the other hand, black draws more power than white on LCD screens, because the light (sourced by the backlight) starts out white and has to be actively blocked to produce black. [ scientificamerican.com/article.cfm?id=fact-or-fiction-black-‌​is ] Bottom line: Don't count too much on this color optimization.

[Yousha Aleayoub]

"recycle complex java objects such..." How? while Java has GC

[Yousha Aleayoub]

Reason? can you explain why?

[Pawan]

Question: Doesn't the compiler explicitly do it for you? I think it should do it in its code analysis phase.

[Developine]

Read this blogpost. medium.com/@hammad_tariq/…