Android: Looper, Handler, HandlerThread. Part I

What do you know about threads in Android? You may say "I've used

AsyncTask

to
run tasks in background". Nice, but what else? "Oh, I heard something about

Handlers

,
because I used them to show toasts from background thread or to post tasks with delay". That's definitely better, but in this post I'll show what's under the hood.
Let's start from looking at the well-known

AsyncTask

class,
I bet every Android developer has faced it. First of all, I would like to say that you can find a good overview of

AsyncTask

class
at the official documentation. It's a nice and handy class for running tasks in background if you don't want to waste your time on learning how to manage
Android threads. The only important thing you should know here is that only one method of this class is running on another thread -

doInBackground

.
The other methods are running on UI thread. Here is a typical use of

AsyncTask

:

//MyActivity.java
public class MyActivity extends Activity {

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
MyAsyncTask myTask = new MyAsyncTask(this);
myTask.execute("http://developer.android.com");
}
}

//MyAsyncTask.java
public class MyAsyncTask extends AsyncTask<String, Void, Integer> {

private Context mContext;

public MyAsyncTask(Context context) {
mContext = context.getApplicationContext();
}

@Override
protected void onPreExecute() {
Toast.makeText(mContext, "Let's start!", Toast.LENGTH_LONG).show();
}

@Override
protected Integer doInBackground(String... params) {
HttpURLConnection connection;
try {
connection = (HttpURLConnection) new URL(params[0])
.openConnection();
return connection.getResponseCode();
} catch (IOException e) {
e.printStackTrace();
}
return -1;
}

@Override
protected void onPostExecute(Integer integer) {
if (integer != -1) {
Toast.makeText(mContext, "Got the following code: " + integer,
Toast.LENGTH_LONG).show();
}
}
}

We will use the following straightforward

main

layout with
progress bar for our test:

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:gravity="center">
<ProgressBar
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:id="@+id/progressBar"/>
</LinearLayout>

If progress bar freezes, we are doing heavy job on the UI thread.
We are using

AsyncTask

here, because it takes some time to
get a response from server and we don't want our UI to be blocked while waiting this response, so we delegate this network task to another thread. There are a lot of posts on why using

AsyncTask

is
bad (if it is an inner class of your

Activity

/

Fragment

,
it holds an implicit reference to it, which is bad practice, because

Activity

/

Fragment

can
be destroyed on configuration change, but they will be kept in memory while worker thread is alive; if it is declared as standalone or static inner class and you are using reference to a

Context

to
update views, you should always check whether it is

null

or not). All
tasks on UI thread (which drives the user interface event loop) are executed in sequential manner, because it makes code more predictable - you are not falling into pitfall of concurrent changes from multiple threads, so if some task is running too long, you'll
get

ANR

(Application Not Responding) warning.

AsyncTask

is
one-shot task, so it cannot be reused by calling

execute

method on the
same instance once again - you should create another instance for a new job.
The interesting part here is that if you try to show a toast from

doInBackground

method
you'll get an error, something like this:

java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()
at android.os.Handler.<init>(Handler.java:121)
at android.widget.Toast$TN.<init>(Toast.java:322)
at android.widget.Toast.<init>(Toast.java:91)
at android.widget.Toast.makeText(Toast.java:238)
at com.example.testapp.MyActivity$MyAsyncTask.doInBackground(MyActivity.java:25)
at com.example.testapp.MyActivity$MyAsyncTask.doInBackground(MyActivity.java:21)

Why did we face this error? The simple answer: because

Toast

can
be shown only from UI thread, the correct answer: because it can be shown only from thread with

Looper

.
You may ask "What is a

Looper

?". Ok, it's time to dig deeper.

AsyncTask

is
a nice class, but what if the functionality it has is not enough for your needs? If we take a look under the hood of

AsyncTask

,
we will find, that actually it is a box with tightly coupled components:

Handler

,

Runnable

,

Thread

.
Let's work with this zoo. Each of you is familiar with threads in

Java

,
but in

Android

you may find one more class HandlerThread derived
from

Thread

. The only significant difference between

HandlerThread

and

Thread

you
should turn your attention to is that the first one incorporates Looper,

Thread

andMessageQueue.

Looper

is
a worker, that serves a

MessageQueue

for a current thread.

MessageQueue

is
a queue that has tasks called messages which should be processed.

Looper

loops
through this queue and sends messages to corresponding handlers to process. Any thread can have only one unique

Looper

,
this constraint is achieved by using a concept of ThreadLocal storage. The bundle of

Looper

+

MessageQueue

is
like a pipeline with boxes.



You may ask "What's the need in all this complexity, if tasks will be processed by their creators -

Handlers

?".
There are at least 2 advantages:

As mentioned above, it helps you to avoid race conditions, when concurrent threads can make changes and when sequential execution is desired.

Thread

cannot be reused after the job is
completed while thread with

Looper

is kept alive by

Looper

until
you call

quit

method, so you don't need to create a new instance each
time you want to run a job in background.

You can make a

Thread

with

Looper

on
your own if you want, but I recommend you to use

HandlerThread

(Google
decided to call it

HandlerThread

instead of

LooperThread

):
it already has built-in

Looper

and all pre-setup job will be done for
you. And what's about

Handler

? It is a class with 2 basic functions:
post tasks to the

MessageQueue

and process them. By default,

Handler

is
implicitly associated with thread it was instantiated from via

Looper

,
but you can tie it to another thread by explicitly providing its

Looper

at
the constructor call as well. Now it's time to put all pieces of theory together and look on real
example. Let's imagine we have an

Activity

and we want to post tasks
(in this article tasks are represented by the

Runnable

interface, what
they actually are will be shown in next part) to its

MessageQueue

(all

Activities

and

Fragments

are
living on UI thread), but they should be executed with some delay:

public class MyActivity extends Activity {

private Handler mUiHandler = new Handler();

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);

Thread myThread = new Thread(new Runnable() {
@Override
public void run() {
for (int i = 0; i < 4; i++) {
try {
TimeUnit.SECONDS.sleep(2);
} catch (InterruptedException e) {
e.printStackTrace();
}
if (i == 2) {
mUiHandler.post(new Runnable() {
@Override
public void run() {
Toast.makeText(MyActivity.this,
"I am at the middle of background task",
Toast.LENGTH_LONG)
.show();
}
});
}
}
mUiHandler.post(new Runnable() {
@Override
public void run() {
Toast.makeText(MyActivity.this,
"Background task is completed",
Toast.LENGTH_LONG)
.show();
}
});
}
});
myThread.start();
}
}

Since

mUiHandler

is tied up to UI thread (it gets UI thread

Looper

at
the default constructor call) and it is a class member, we have an access to it from inner anonymous classes, and therefore can post tasks to UI thread. We are using

Thread

in
example above and its instance cannot be reused if we want to post a new task, we should create a new one. Is there another solution? Yes, we can use a thread with

Looper

.
Here is a slightly modified previous example with

HandlerThread

instead
of

Thread

, which demonstrates its ability to be reused:

//MyActivity.java
public class MyActivity extends Activity {

private Handler mUiHandler = new Handler();
private MyWorkerThread mWorkerThread;

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);

mWorkerThread = new MyWorkerThread("myWorkerThread");
Runnable task = new Runnable() {
@Override
public void run() {
for (int i = 0; i < 4; i++) {
try {
TimeUnit.SECONDS.sleep(2);
} catch (InterruptedException e) {
e.printStackTrace();
}
if (i == 2) {
mUiHandler.post(new Runnable() {
@Override
public void run() {
Toast.makeText(MyActivity.this,
"I am at the middle of background task",
Toast.LENGTH_LONG)
.show();
}
});
}
}
mUiHandler.post(new Runnable() {
@Override
public void run() {
Toast.makeText(MyActivity.this,
"Background task is completed",
Toast.LENGTH_LONG)
.show();
}
});
}
};
mWorkerThread.start();
mWorkerThread.prepareHandler();
mWorkerThread.postTask(task);
mWorkerThread.postTask(task);
}

@Override
protected void onDestroy() {
mWorkerThread.quit();
super.onDestroy();
}
}

//MyWorkerThread.java
public class MyWorkerThread extends HandlerThread {

private Handler mWorkerHandler;

public MyWorkerThread(String name) {
super(name);
}

public void postTask(Runnable task){
mWorkerHandler.post(task);
}

public void prepareHandler(){
mWorkerHandler = new Handler(getLooper());
}
}

I used

HandlerThread

in this example, because I don't want
to manage

Looper

by myself,

HandlerThread

takes
care of it. Once we started

HandlerThread

we can post tasks to it at
any time, but remember to call

quit

when you want to stop

HandlerThread

.

mWorkerHandler

is
tied to

MyWorkerThread

by specifying its

Looper

.
You cannot initialize

mWorkerHandler

at the

HandlerThread

constructor
call, because

getLooper

will return

null

since
thread is not alive yet. Sometimes you can find the following handler initialization technique:

private class MyWorkerThread extends HandlerThread {

private Handler mWorkerHandler;

public MyWorkerThread(String name) {
super(name);
}

@Override
protected void onLooperPrepared() {
mWorkerHandler = new Handler(getLooper());
}

public void postTask(Runnable task){
mWorkerHandler.post(task);
}
}

Sometimes it will work fine, but sometimes you'll get

NPE

at
the

postTask

call stating, that

mWorkerHandler

is

null

.
Surpise!



Why does it happen? The trick here is in native call needed for new thread creation. If we take a loop on piece of code, where

onLooperPrepared

is
called, we will find the following fragment in the

HandlerThread

class:

public void run() {
mTid = Process.myTid();
Looper.prepare();
synchronized (this) {
mLooper = Looper.myLooper();
notifyAll();
}
Process.setThreadPriority(mPriority);
onLooperPrepared();
Looper.loop();
mTid = -1;
}

The trick here is that

run

method will be called only after
new thread is created and started. And this call can sometimes happen after your call to the

postTask

method
(you can check it by yourself, just place breakpoints inside

postTask

and

onLooperPrepared

methods
and take a look which one will be hit first), so you can be a victim of race conditions between two threads (main and background). In the next part what these tasks really are inside

MessageQueue

will
be shown.