OOP design and performance on smartphones
I recommend this book: Getting Started Android 4 Game Development by Mario Zechner and Robert Green for beginners in android games.
Book listed on page 192:
Method calls have a larger associated cost in Dalvik than in other VMs. Use
static methods if you can, as those perform best. Static methods are generally
regarded as evil, much like static variables, as they promote bad design, so try
to keep your design as clean as possible. Perhaps you should avoid getters and
setters as well. Direct field access is about three times faster than method
invocations without the JIT, and about seven times faster with the JIT.
Nevertheless, think of your design before removing all your getters and setters.
Now, does this have a huge impact these days? What's really best between performance and design? Since if im going to have static variables and methods, it will be in RAM until the application exits, it will be bad if my application is too big and Android 2.3 becomes part of the market.
source to share
Performance is a great factor to consider when developing on Android enabled devices, as we also need to consider low configuration devices.
As far as the use of static variables and methods is concerned, it entirely depends on which specific devices the application is targeting.
You are absolutely right - static variables and methods will stay in RAM until the application exits , but you can see that this is not a problem, if your Android device is running with 1GB of RAM and trust me, if you set up 2.3 the application will have many ANRs since the memory required by variable objects will not be available.
The best shot for you is to focus more on:
- Modular design, preferably MVC with singelton or factory pattern.
- Use proper high-level optimizations (by code or using third party libraries, for example: use jackson for parsing instead of the traditional way, or use Volley for network connections).
- Perform proper profiling using tools like MAT, DDM.
- free memory when the user interface is hidden
Post development: check how much memory your application is using. Each Android device has a different amount of RAM available to the system and thus provides a different heap limit for each application.
You can call getMemoryClass () to get an estimate of the app's available heap in megabytes.
source to share
One thing that developers often forget when doing micro-optimizations is optimizations that need to be done without breaking the design. Whether the field needs to be static or non-static is just a design choice. Likewise, whether it makes sense to have getters and setters also depends on whether you want to make the field private or public.
So, once you are done with your design phase and move into the implementation phase, look at the optimization, for example using a StringBuilder over String # concat. When you enter the implementation phase, you would have already decided whether the field should be private, whether it should be static, etc.
Now, on to the technical side - in fact, static method calls always provide compile-time binding. Therefore, calls to them are cheaper.
Generally, direct field access is faster than using a getter / setter (JIT can inline getters / setters, but it's still expensive than direct access).
So the book is correct about performance. But you don't have to compromise on design to improve performance.
source to share