Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

My development on Android is based on scientific programs and while I'm building these most of the code is in one or two long classes. When I come to deploy these programs I try to decouple everything and use classes and objects like I would on a Java desktop application.

However reading guide Designing for Performance | Android Developers about Internal Getters/Setters it seems OO is not a good approach.

My question is what is best approach when designed Android applications, should I still use lots of classes with getters/setters and lots of object passing around. This seems counter intuitive thinking about the architecture of Android, but it also does not seem right to have lots of code in long classes.

I have looked at source codes from other projects and these seem to follow the OO approach.

My applications involve heavy image processing and time and performance is important.

I am more of a science researcher than a programmer so thanks in advance for any help.

share|improve this question
2  
I'd like to quote an eternal truth on optimization from the document you linked to (specifically the closing notes): "One last thing: always measure. Before you start optimizing, make sure you have a problem." –  Joachim Sauer Jul 23 '12 at 14:57

3 Answers 3

up vote 8 down vote accepted

Write dumb code

"Often, the way to write fast code in Java applications is to write dumb code -- code that is straightforward, clean, and follows the most obvious object-oriented principles." -- Brian Goetz

Don't get me wrong - there is a chance that particular object design may have substantial performance impact in some particular case on specific execution path in some application on some device - why not, everything is possible given the variety of Android devices. Know what? there is even a chance of it having an opposite impact on some other device, why not.

If (if) that happens, if (if) you'll somehow get a clear, solid, tested and proven justification of specific performance impact - then (then), go ahead, implement whatever tricks necessary to reach required performance, no matter how perverse they may be (BTDTGTTS). Until then, though, drop any baseless assumptions that just may come to your mind.

Until then... Just. Drop. It.

Developers love to optimize code and with good reason. It is so satisfying and fun. But knowing when to optimize is far more important. Unfortunately, developers generally have horrible intuition about where the performance problems in an application will actually be... Most performance tuning reminds me of the old joke about the guy who's looking for his keys in the kitchen even though he lost them in the street, because the light's better in the kitchen... (Brian Goetz)

share|improve this answer
    
I personally hate optimizing and do it only for noticeably slow code. ^^ –  Paul Jul 23 '12 at 15:28

Write in C++ and do it just like you would for any other platform.

Development for Android can be done in C++ (look for Native Development Kit (NDK)) and if you need raw performance, I would definitely suggest taking a look at it, but depends on which languages and libraries you know well.

The Dalvik virtual machine is far less optimized than the Oracle JVM or IBM HotSpot and even these well tuned JVMs generally need a lot more memory than corresponding program in C++. In fact, Java (or any other language targeting JVM) typically needs much more memory than equivalent C# or even Python or Ruby application. If you are going to do image processing, being memory efficient is an advantage.

You can also start coding in Java and rewrite the most critical bits in C++ when you find, by testing a prototype, which ones they are (see gnat's answer, it is good).

share|improve this answer

This is kinda nonsense. If, for example, you want 10-15% better performance, sure go NDK or drop OO design principes. But it if you want easy to write, maintainable, and easy to understand code, then ignore the performance hype.

Bottom line is performance tweaking is a job done after you build an app, not during. Droid is usually fast enough to use the standard SKD as is.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.