Google Developer Day 2010 Japan: 高性能な Android アプリを作るには (ティムブレイ)

Developer DayGoogle 2010
Thursday, September 16, 2010

High-performance Android apps
Tim Bray

Outline
• Why care?
• What is an ANR? Why do we see them?
• Quantifying responsiveness and “jank”
• Android SDK features for performance
• Numbers to know
• Storage and network issues
• Tools
• What to do?

“Jank”
• Chrome team's term for stalling the event loop,
i.e. not instantly responsive to input
• Eliminate by:
• Reacting to events quickly
• Don't hog the event loop (“main” / UI) thread!
• Getting back into the select() / epoll_wait()
call ASAP, so...
• … you can react to future events quickly
(touches, drags)
• Else...

ANR: “App Not Responding”
• Happens when:
• UI thread”) doesn't respond to input event in
5 seconds, or
• a BroadcastReceiver doesn't finish in 10
seconds
• Typically due to network or storage
operations on main thread
• But users complain about delays much less
than 5 seconds!

Some Nexus One Numbers
• ~0.04 ms: writing a byte on pipe process A->B, B->A
or reading simple /proc files from Dalvik
• ~0.12 ms: void/void Binder RPC call A->B, B->A
• ~5-25 ms: uncached flash reading a byte
• ~5-200+(!) ms: uncached flash writing tiny amount
• 16 ms: one frame of 60 fps video
• 100-200 ms: human perception of slow action
• 108/350/500/800 ms: ping over 3G. varies!
• ~1-6+ seconds: TCP setup + HTTP fetch of 6k via 3G

Writing to flash (yaffs2)
Source: empirical samples over Google employee phones (Mar 2010)
• Create file, 512 byte write,
delete (ala sqlite .journal in
transaction)
• Flash is different than disks
you're likely used to: read,
write, erase, wear-leveling, GC
• Write performance is highly
variable!

Sqlite Performance
• There’s no such thing as a cheap write
• Use indexes (see EXPLAIN & EXPLAIN
QUERY PLAN)
• For logging, consider file-append rather than
database-write

Lessons
• Writing to storage is slow
• Using the network is slow
• Always assume the worst; performance is
guaranteed to produce bad reviews and Market
ratings

Tools: asyncTask
“AsyncTask enables proper
and easy use of the UI
thread. This class allows to
perform background
operations and publish
results on the UI thread
without having to manipulate
threads and/or handlers.”

Tool: asyncTask
private class DownloadFilesTask extends AsyncTask<URL, Integer, Long> {
protected Long doInBackground(URL... urls) { // on some background thread
int count = urls.length; long totalSize = 0;
for (int i = 0; i < count; i++) {
totalSize += Downloader.downloadFile(urls[i]);
publishProgress((int) ((i / (float) count) * 100));
}
return totalSize;
}
protected void onProgressUpdate(Integer... progress) { // on UI thread!
setProgressPercent(progress[0]);
}
protected void onPostExecute(Long result) { // on UI thread!
showDialog("Downloaded " + result + " bytes");
}
}
new DownloadFilesTask().execute(url1, url2, url3); // call from UI thread!

Tool: asyncTask
private boolean handleWebSearchRequest(final ContentResolver cr) {
...
new AsyncTask<Void, Void, Void>() {
protected Void doInBackground(Void... unused) {
Browser.updateVisitedHistory(cr, newUrl, false);
Browser.addSearchUrl(cr, newUrl);
return null;
}
}.execute()
...
return true;
}

asyncTask Details
• Must be called from a main thread
• rather, a thread with a Handler/Looper
• No nested calls!
• An activity process may exit before its
AsyncTask completes (user goes elsewhere,
low RAM, etc).
• If this is a problem, use IntentService

Tool: android.app.IntentService
• “IntentService is a base class for Services that
handle asynchronous requests (expressed as
Intents) on demand. Clients send requests
through startService(Intent) calls; the service is
started as needed, handles each Intent in turn
using a worker thread, and stops itself when it
runs out of work.”
• Intent happens in a Service, so Android tries
hard not to kill it
• Easy way to do use a Service

Calendar's use of IntentService
public class DismissAllAlarmsService extends IntentService {
@Override public void onHandleIntent(Intent unusedIntent) {
ContentResolver resolver = getContentResolver();
...
resolver.update(uri, values, selection, null);
}
}
In AlertReceiver extends BroadcastReceiver, onReceive() (main thread)
Intent intent = new Intent(context, DismissAllAlarmsService.class);
context.startService(intent);

UI Tips
• Disable UI elements immediately, before kicking off
your AsyncTask to finish the task
• Use an animation or ProgressDialog to show you’re
working
• One example strategy:
1. Immediately, disable UI elementes
2. Briefly, a spinner in the title bar
3. If more than 200msec, show a ProgressDialog
4. in AsyncTask onPostExecute, cancel alarm timer

What to do?
1. Design the simplest thing that could possible
work, where “could possibly work” excludes
doing network transactions on the UI thread.
Maybe it’ll be fast enough!
2. If it’s not fast enough, measure and find out
why.
3. Fix the biggest performance problems.
4. goto 2

Profiling Tools
• Traceview (for CPU-bound apps)
• dalvik.system.VMDebug#{start,stop}MethodTracing()
• adb shell am profile <PROCESS> start <FILE>
• adb shell am profile <PROCESS> stop
• Log.d() calls with a timestamp aren’t terrible
• Extreme profiling: Aggregate user profile data

Demo
• Profiling Tim’s “LifeSaver 2” application

Thank you!
Tim Bray, Developer Advocate
twbray@google.com android-developers.blogspot.com @AndroidDev

Google Developer Day 2010 Japan: 高性能な Android アプリを作るには (ティムブレイ)

More Related Content

Similar to Google Developer Day 2010 Japan: 高性能な Android アプリを作るには (ティムブレイ) (20)

More from Google Developer Relations Team (10)

Recently uploaded (20)