Bad asynctask in Android

Asynctask is a very common API, especially when processing data asynchronously and applying data to views. In fact, asynctask is not so good, even a little bad. In this article, I will talk about the problems caused by asynctask, how to fix them, and some alternatives to asynctask.

AsyncTask

Starting with Android API 3 (1.5 Cupcake), asynctask was introduced to help developers manage threads more easily. In fact, there is a similar implementation in Android 1.0 and 1.1, that is, usertask. Usertask and asynctask have the same API and implementation, but because the device share of 1.0 and 1.1 is very small, the concept here will not involve usertask.

life cycle

There is a widespread misunderstanding about asynctask. Many people think that an asynctask in an activity will be destroyed with the destruction of the activity. And that's not the case. Asynctask will execute the doinbackground () method until the end of the method execution. Once the above method is completed, different operations will be carried out according to the situation.

If cancel (Boolean) is called, the oncancelled (result) method is executed

If cancel (Boolean) is not called, the onpostexecute (result) method is executed

The cancel method of asynctask requires a Boolean parameter named mayinterruptifrunning, which means whether the execution can be interrupted. If this value is set to true, it means that the task can be interrupted. Otherwise, the executing program will continue to execute until it is completed. If there is a loop operation in the doinbackground () method, we should use iscancelled () in the loop to judge. If the return is true, we should avoid performing subsequent useless loop operations.

In conclusion, we need to ensure that asynctask is cancelled correctly when using asynctask.

Cancel ()

In short, the answer sometimes works.

If you call cancel (false) of asynctask, doinbackground () will still execute to the end of the method, but you won't call onpostexecute () method. But in fact, this makes the application perform meaningless operations. Can we solve the problem before calling cancel (true)? and be not so. If mayinterruptifrunning is set to true, the task will end as soon as possible, but if doinbackground() has non interruptible methods, such as bitmapfactory Decodestream() IO operation. However, you can close the IO stream in advance and catch the exceptions thrown by this operation. But this makes the cancel () method meaningless.

Memory leak

Another common situation is that the non static anonymous internal asynctask class is used in the activity. Due to the characteristics of Java internal classes, the internal asynctask class will hold an implicit reference to the external class. For details, please refer to the private modifier of Java: "invalid". Because the life cycle of asynctask may be longer than that of activity, when the activity is destroyed and asynctask is still executing, the activity object cannot be recycled because asynctask holds the reference of activity, resulting in memory leakage.

Result loss

Another problem is the loss of asynctask data when the activity is re created due to screen rotation. After the activity is destroyed and created, the running asynctask will hold an illegal reference to the activity, that is, the previous activity instance. Causes onpostexecute() to have no effect.

Serial or parallel

There are many questions about whether asynctask is serial or parallel, which is normal because it has been modified many times. If you don't know what is serial or parallel, you can understand it through the following examples. Suppose we have the following two lines of code in a method body

new AsyncTask1(). execute(); new AsyncTask2(). execute();

Are the above two tasks executed at the same time, or can asynctask 2 be executed after asynctask 1 is executed? In fact, the results vary according to the API.

Before 1.6 (donut):

In the first version of asynctask, tasks were scheduled serially. One task cannot be executed until another is completed. Using multiple asynctasks may cause some problems due to the serial execution of tasks. So this is not a good way to handle asynchronous operations, especially when the results need to be applied to the UI.

From 1.6 to 2.3 (Gingerbread)

Later, the Android team decided to let asynctask solve the problem caused before 1.6 in parallel. This problem was solved and new problems appeared again. Many developers actually rely on sequential behavior. So many concurrent problems swarmed in.

3.0 (honeycomb) up to now

Well, developers may not like to make asynctask parallel, so the Android team changed asynctask to serial. Of course, this modification does not completely prohibit asynctask parallelism. You can set executeonexecutor (executor) to implement multiple asynctasks in parallel. The API documentation is described below

If we want to make sure we have control over the execution,whether it will run serially or parallel,we can check at runtime with this code to make sure it runs parallel:

Do you really need asynctask

Not so. Although asynctask can be used to implement asynchronous operations in short code, as mentioned in this article, you need to pay attention to many rules and regulations if you need to make asynctask work normally. A recommended technique for asynchronous operations is to use loaders. This method was introduced from Android 3.0 (honeycomb) and is also included in the Android support package. You can learn more about loaders by viewing the official documentation.

There are a few deletions and modifications to the original text in this translation.

The above is the data sorting of Android asynctsak, and then continue to supplement relevant data. Thank you for your support to this site!