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 and MessageQueue. 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.
Threadcannot be reused after the job is completed while thread withLooperis kept alive byLooperuntil you callquitmethod, 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.