Mobile Developer Summit 2012, Pune
-
Upload
bhuvan-khanna -
Category
Technology
-
view
218 -
download
0
description
Transcript of Mobile Developer Summit 2012, Pune
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!