Not Quite As Painful Threading

Copyright © 2013 CommonsWare, LLC
Painless
Threading
Apps World Europe 2013

Painless
Threading
Apps World Europe 2013
Not Quite As Painful

Problem #1: Jank
● Sluggish UI Response to User Input
– Example: hiccups while scrolling a list
● Reason:Too MuchTime Spent on Main
ApplicationThread
– 60 fps UI updates 16 ms/frame need to→ →
spend < 1ms per callback method
● Limitation: Cannot Modify UI from
BackgroundThread

Problem #2: Changes
● Configuration Changes
– Example: rotate the device
● Default Behavior = Destroy/Recreate UI
– Activities and (most) fragments
● WhatWe Do NotWant: Lost Results
– Spin off a thread, which updates the former UI,
not the current UI

Problem #3: Sleep
● Devices Fall Asleep After Inactivity
– Screen goes dark, CPU powers down
– Can be in as little as 15 seconds
● Less if user presses POWER button directly
● WhatWe Do NotWant: IncompleteWork
– Spin off thread to do network I/O, fall asleep
mid-conversation, with messed up results

Problem #4: Cores
● Good News!We Have Multiple Cores Now!
– Better responsiveness from CPU-intensive apps,
such as games
● Bad News!We Have Multiple Cores Now!
– Thread safety now a bigger problem than before
– Can have results ranging from outright crashes
to subtle inconsistencies

Timing Is Everything
● GeneralTransactional Recipe
– 1 ms to 1 s use→ AsyncTask and retained
fragment
– 1-15 s use→ IntentService and event bus
– 15+ s use wakeful pattern and event bus→
● Also if the work is triggered outside the UI, such as
via a push message

AsyncTask
● QuickWork
– Disk and database I/O
– Trivial network I/O (e.g., downloading
thumbnails)
● Android SuppliesThread Pool
● Android GivesYou Hook to Send Results to
Main ApplicationThread

SimpleAsyncTask
● https://gist.github.com/commonsguy/6900714
● AsyncTask Subclass, Simpler API
– Override doInBackground() and do the work that will
take a moment
● Called on a framework-supplied background thread
– Override onPostExecute() and update the UI based
on the background work
● Called on main application thread once doInBackground()
completes
– Create instance, call execute()

AsyncTask
● What AsyncTask Itself GivesYou
– Optional parameters from execute() to
doInBackground()
– Optional results from doInBackground()
passed to onPostExecute()
– Additional hooks, like onPublishProgress()
– Thread pool choices
● Cost: a bit of complexity

Retained Fragment
● setRetainInstance(true)
● Effects
– Fragment not destroyed and recreated on
configuration change
– onPostExecute() can work with fragment to
update UI, will affect the appropriate widgets
depending on timing

Limits of AsyncTask
● Does Not Keep Device Awake
● Does Not Keep Process Alive
● Still Must Deal withThread Safety

IntentService
● Use Case
– Work that needs to be completed even if user
leaves your UI (e.g., presses HOME)...
– ...but not so long that the device is likely to fall
asleep while you are doing that work
● Benefits
– Lets Android know that you are doing work
– Immune to configuration changes

IntentService Recipe
● Extend IntentService
– Override onHandleIntent(), where you do
work on framework-supplied background thread
● Add <service> to Manifest
● Call startService() toTriggerWork
– Takes Intent to identify the service
– Package extras on Intent for work details
– Intent supplied to onHandleIntent()

Event Bus
● Loose Coupling for Result Delivery
– LocalBroadcastManager
● Part of Android Support package
– greenrobot's EventBus
– Square's Otto
● Not as thread-savvy and so may not be suitable

Event Bus Recipe
● UI Layer Receives Events
– Register in onResume(), unregister in
onPause()
● IntentService Sends Events
– Picked up by UI layer if in foreground, to do
what's needed
– If not picked up, detect and raise a
Notification, if appropriate

Limits of IntentService
● No Direct UI Access
– Message-based for work requests and results
● Does Not Keep Device Awake
– IntentService itself is single-threaded, so multiple
commands are not a problem
– ...but may still have other code accessing same data on
main application thread, other threads

WakefulIntentService
● http://github.com/commonsguy/cwac-wakeful
● Keeps Device Awake DuringWork
● Recipe
– Download JAR
– Extend WakefulIntentService instead of
IntentService
– Override doWakefulWork() instead of
onHandleIntent()
– Trigger work via sendWakefulWork()

WakefulBroadcastReceiver
● Alternative to WakefulIntentService
– Ships with Android Support package
● Recipe
– Have work be triggered by broadcast to a subclass of
WakefulBroadcastReceiver
– Use startWakefulService() in onReceive()
– IntentService calls completeWakefulIntent()
when work done

Limits ofWakeful Approaches
● No Direct UI Access
– Still using event bus for delivering results
● Power Consumption
– Require WAKE_LOCK permission
– You may appear in “battery blame screen” in
Settings

Recap
● GeneralTransactional Recipe
– 1 ms to 1 s use→ AsyncTask and retained
fragment
– 1-15 s use→ IntentService and event bus
– 15+ s use wakeful pattern and event bus→
● Also if the work is triggered outside the UI, such as
via a push message

Code!
● https://github.com/commonsguy/cw-omnibus
● SimpleAsyncTask/Retained Fragment
– /Threads/SimpleAsyncTask
● AsyncTask/Retained Fragment
– /Threads/AsyncTask
● WakefulIntentService/Event Bus
– /EventBus

Not Quite As Painful Threading

Recommended

Recommended

More Related Content

What's hot

What's hot (9)

Similar to Not Quite As Painful Threading

Similar to Not Quite As Painful Threading (20)

More from CommonsWare

More from CommonsWare (20)

Recently uploaded

Recently uploaded (20)

Not Quite As Painful Threading