Detailed explanation and example of Android single thread model

Detailed explanation and example of Android single thread model

We will introduce the Android single thread model in detail in this article today. I hope beginners can have a full understanding of this concept through the content introduced in this paper, and have a deep understanding of this system.

When an Android program is started for the first time, Android will automatically create a thread called "main" main thread. This main thread (also known as UI thread) is very important because it is responsible for dispatching events to corresponding controls, including screen drawing events. It is also the thread for users to interact with Android controls. For example, when you press a button on the screen, the UI thread will distribute the event to the button just pressed, and then the button sets itself to the pressed state and sends an invalid request to the event queue. The UI thread moves the request out of the event queue and notifies the button to redraw itself on the screen.

Android single thread model will cause low performance of Android applications without considering its impact, because all tasks are executed in the same thread. If some time-consuming operations are performed, such as accessing the network or querying the database, the whole user interface will be blocked. When performing some time-consuming operations, events cannot be distributed in time, including user interface redrawing events. From the user's point of view, the application looks like it's hanging up. Worse, if the application is blocked for a long time (now about 5 seconds), Android will prompt the user with some information, that is, open a dialog box "application not responding".

If you want to know how bad this is, write a simple program containing one button, register a click event for the button, and call the code Thread.sleep (2000) in the event handler. After pressing this button, it will remain pressed for about 2 seconds before returning to the normal state of the button. If this happens in the application you write, the first reaction of users is that your program runs very slowly.

Now you know that you should avoid performing time-consuming operations in the UI thread. You are likely to perform these time-consuming tasks in the background thread or worker thread. Is this correct? Let's take a look at an example. In this example, the click event of a button downloads a picture from the network and uses ImageView to display the picture.

The code is as follows:

This code seems to solve your problem well, because it won't block the UI thread. Unfortunately, it violates the Android single threaded model: Android UI operations are not thread safe and must be performed in the UI thread. In this code snippet, using the ImageView method in a worker thread causes some strange problems. It will be difficult and time-consuming to investigate the problem and fix the bug.

Android provides several ways to access UI threads in other threads. You may be familiar with some of these ways, but here is a more comprehensive list:

Any of the above classes or methods can fix the problems in our previous code.

Unfortunately, these classes or methods will also make your code very complex and difficult to understand. However, this gets worse when you need to implement some very complex operations and need to update the UI frequently. To solve this problem, Android 1.5 provides a tool class: asynctask, which makes it easier to create long-running tasks that need to interact with the user interface.

Usertask class with the same function as asynctask in Android 1.0 and 1.1. It provides exactly the same API. All you need to do is copy its code into your program.

The goal of asynctask is to manage your threads for you. The previous code can be easily rewritten using asynctask.

As you can see, using asynctask must inherit it. It is very important to use asynctask: an instance of asynctask must be created in the UI thread and can only be used once. You can use the pre read asynctask documentation to learn how to use this class. Here's an overview of how it works:

You can use generic parameters to specify task parameters, intermediate values, and any final execution results

The doinbackground () method is automatically executed in the worker thread

The onpreexecute(), onpostexecute() and onprogressupdate() methods are called in the UI thread

The return value of the doinbackground () method is passed to the onpostexecute () method

In the doinbackground () method, you can call the publishprogress () method. Each call will cause the UI thread to execute the onprogressupdate () method once

You can cancel this task at any time in any thread

In addition to the official documentation, you can read several complex examples in the source code of shelves and photostream. I strongly recommend reading the source code of shelves, which will let you know how to persist tasks between configuration changes and cancel tasks correctly when the activity is destroyed.

Whether you use asynctask or not, always remember the following two guidelines for the Android single threaded model: do not block the UI thread and all Android UI operations are executed in the UI thread. Asynctask simply makes it easier for you to follow these two guidelines.

Thank you for reading, hope to help you, thank you for your support to this site!