Performance Aspects/ Improvements

Bhuvan Khanna Code Critique & Business Head

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.

Caution! Using the right data structures and algorithms will make more

difference than any of the advice here

"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.

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.

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;

}

}

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.

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

Hidden Treasures

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.

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!

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.)

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.

Re-using Layouts with <include/>

Create a Re-usable Layout

Use the <include> Tag

Use the <merge> Tag

Layout Optimizations.. How??

In web service calls

In 3rd party API usage

Bad coding logic

Race conditions!

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?

Smarter Caching!

Strict Mode

HierarchyViewer

Lint

Measure before optimize!

Questions

Thank you!