2. There are two basic rules
for writing efficient code:
Don't do work that you don't need to do.
Don't allocate memory if you can avoid it.
3. Caution!
Using the right data structures and algorithms will make more
difference than any of the advice here
4. "Object" is Money
Object creation is never free.
If you allocate objects in a user interface loop, you will force a periodic
garbage collection, creating little "hiccups" in the user experience.
Avoid creating short-term temporary objects if you can.
5. Virtual method calls are expensive
Avoid Internal Getters/Setters
Direct field access is about 7x faster than invoking a trivial getter. In native
languages like C++ it's common practice to use getters
(e.g. i = getCount()) instead of accessing the field directly (i = mCount). This is an
excellent habit for C++, because the compiler can usually inline the access. But not
in a JIT.
6. Really! for > Enhanced for? Bummer!
Declare constants static final
Use the enhanced for loop by default, but consider a hand-written counted loop for performance-critical
ArrayList iteration.
public void one() {
int sum = 0;
Foo[] localArray = mArray;
int len = localArray.length;
for (int i = 0; i < len; ++i) {
sum += localArray[i].mSplat;
}
}
public void two() {
int sum = 0;
for (Foo a : mArray) {
sum += a.mSplat;
}
}
7. Inside Information
The Java language allows an inner class to access an outer class' private
members. The compiler generates a couple of synthetic getter methods. In effect
you end up accessing member fields through accessory methods, resulting in an
"invisible" performance hit.
If you're using code like this in a performance hotspot, you can avoid the
overhead by declaring fields and methods accessed by inner classes to have
package access, rather than private access.
8. Hidden Treasures
Use Floating-Point Judiciously – operations on it are 2x slower than integers.
Know And Use The Libraries - The System.arraycopy method is about 9x
faster than a hand-coded loop
9. Love your UI Thread
Do less on the UI tread!
Activities should do as little as possible in key life-cycle methods such as on
Create() and on Resume() Potentially long running operations such as
1. network or database operations
2. computationally expensive calculations such as resizing bitmaps
3. databases operations
should be done in a child thread.
10. That's how you do it!
Generally, 100 to 200ms is the threshold beyond which users will perceive lag
(or lack of "snappiness," if you will) in an application.
Use Strict Mode to find your sins!
11. Responsiveness is Everything
Splash screen or rendering the main view as
quickly as possible.
For games specifically, do calculations for
moves in a child thread.
Show that progress is being made (Progress
Bar and Progress Dialog etc.)
12. Optimizing Layouts.. what?
Each widget and layout you add to your application requires initialization, layout,
and drawing.
For eg, nested instances of Linear Layout
Nesting several instances of Linear Layout that use the layout weight parameter
can be especially expensive as each child needs to be measured twice.
15. Smarter Caching!
What to cache at the start?
What to cache on the go?
What not to cache?
How to update the cache?
When to update the cache?
How much to cache?
Where to store cache data?
