Android Threads Tutorial for Beginners

Threading in Android

In Android, you can categorize all threading components into two basic categories:

1. Threads that are attached to an activity/fragment: These threads are tied to the lifecycle of the activity/fragment and are terminated as soon as the activity/fragment is destroyed.
2. Threads that are not attached to any activity/fragment: These threads can continue to run beyond the lifetime of the activity/fragment (if any) from which they were spawned.

1. Threading Components that Attach to an Activity/Fragment

AsyncTask

Loaders

2. Threading Components that Don’t Attach to an Activity/Fragment

Service

Intent Service

For the above two threading components,There are five types of thread are using in Android Mobile Development which areas:-

Main thread

UI thread

Worker thread

Any thread

Binder thread

Now Let’s discuss for threads one by one:-

1. Main thread:

When an application is launched in Android, it creates the first thread of execution, known as the “main” thread. The main thread is responsible for dispatching events to the appropriate user interface widgets as well as communicating with components from the Android UI toolkit.

To keep your application responsive, it is essential to avoid using the main thread to perform any operation that may end up keeping it blocked.

Network operations and database calls, as well as loading of certain components, are common examples of operations that one should avoid in the main thread. When they are called in the main thread, they are called synchronously, which means that the UI will remain completely unresponsive until the operation completes. For this reason, they are usually performed in separate threads, which thereby avoids blocking the UI while they are being performed (i.e., they have performed asynchronously from the UI).

2. UI thread:

Definition 1:

The UIThread is the main thread of execution for your application. This is where most of your application code is run. All of your application components (Activities, Services, ContentProviders, BroadcastReceivers) are created in this thread, and any system calls to those components are performed in this thread.

For instance, let’s say your application is a single Activity class. Then all of the lifecycle methods and most of your event handling code is run in this UIThread. These are methods like onCreate, onPause, onDestroy, onClick, etc. Additionally, this is where all of the updates to the UI are made. Anything that causes the UI to be updated or changed HAS to happen on the UI thread.

When you explicitly spawn a new thread to do work in the background, this code is not run on the UIThread. So what happens if this background thread needs to do something that changes the UI? This is what the runOnUiThread is for. Actually you're supposed to use a Handler. It provides these background threads the ability to execute code that can modify the UI. They do this by putting the UI-modifying code in a Runnable object and passing it to the runOnUiThread method.

Definition 2:

UI Thread allows your tasks to do background work and then move the results to UI elements such as bitmaps.

Every app has its own special thread that runs UI objects such as View objects, This thread is called the UI thread. Only objects running on the UI thread have access to other objects on that thread. Because tasks that you run on a thread from a thread pool aren't running on your UI thread, they don't have access to UI objects. To move data from a background thread to the UI thread, use a Handler that's running on the UI thread.

3. Worker thread:

Worker threads are background threads. They are the threads that are created separately, other than the UI thread. Since blocking the UI thread is restricted according to the rule, the user should run the child processes and tasks in worker threads.

An example of the creation and working of worker thread is given below:-

Public void onClick(View v) { new Thread(new Runnable() {

public void run() {

Bitmap b = loadImageFromNetwork(“http://example.com/image.png");

mImageView.setImageBitmap(b);}

}).start(); }

In the above example code, the download operation is handled by a second thread other than the UI thread. But the program violates the second rule. The imageView from UI thread is manipulating from this worker thread.

According to the second rule, UI could not be accessed from outside the UI thread. The solution for such a restriction is runOnUiThread(Runnable) method. The main or UI thread can be accessed from other threads using runOnUiThread(Runnable) method.

As a result, the specified runnable action passed through this method will run on the UI thread. The action will execute immediately if the current thread is in the UI itself. Else the action will be posted to the event queue.

4. Any thread:

@Target([AnnotationTarget.FUNCTION, AnnotationTarget.PROPERTY_GETTER, AnnotationTarget.PROPERTY_SETTER, AnnotationTarget.CONSTRUCTOR, AnnotationTarget.CLASS, AnnotationTarget.FILE, AnnotationTarget.VALUE_PARAMETER]) class AnyThread

Denotes that the annotated method can be called from any thread (e.g. it is “thread-safe”.) If the annotated element is a class, then all methods in the class can be called from any thread.

The main purpose of this method is to indicate that you believe a method can be called from any thread; static tools can then check that nothing you call from within this method or class has more strict threading requirements.

Example:

<code>
   @AnyThread
   public void deliverResult(D data) { ... }
  </code>

5. Binder thread:

Definition 1:

Binder thread represents a separate thread of your service. Binder is a mechanism that provides Inter-Process Communication.

Let’s consider an example. Imagine that you have service Process B (see picture). And you have several applications that communicate with this service B (one of this application is, for instance, Process A). Thus, one service B should provide different results simultaneously to different applications. Thus, you need to run several replicas of Service B for different applications. Android runs these replicas in different threads of Process B and these threads are called “Binder Thread #N”.

Definition 2:

Binder Thread is used in Android Service Binding with Interprocess Communication. Most of the time you will encounter this concept in Service calls with interfaces defined by Android Interface Definition Language (AIDL).

In the AIDL case, Service calls are executed by threads maintained by a default Thread Pool created with your application. Those threads are called Binder Threads. This grants the Service the ability to work on multiple calls happening at the same time.

Usually, Service calls with the interface defined by “Extending the Binder class” and “Using a Messenger” are executed sequentially in one thread.

A detailed discussion about “Service Binding and Threads” can be found here.

In short:

Calls made from the local process are executed in the same thread that is making the call.

Calls from a remote process are dispatched from a thread pool the platform maintains inside of your own process.

You must be prepared for incoming calls from unknown threads, with multiple calls happening at the same time. In other words, an implementation of an AIDL interface must be completely thread-safe.

Hope it will help the developer to understand for all type of threads and their uses.