4

I'm confused by what I read about the AsyncTask. On one hand, the android document states that "AsyncTasks should ideally be used for short operations (a few seconds at the most.)". The document does not give an explanation as to why this is so.

On the other hand, I've read at least one article that explicitly or implicitly suggests that AsyncTasks be used for long-running operations, such as this one.

Could any android guru give a more convincing reason why or why not an AsyncTask should be used for long-running operations? Or point me to the documents that explain this. I haven't been able to find the answer.

Ah, someone else asked a similar question. Let me see if the answers make sense to me.

Community
  • 1
  • 1
hubeir
  • 1,279
  • 2
  • 13
  • 24

2 Answers2

2

the interface exposed by AsyncTask defines a setup, a background operation, and an "on done" callback that can update the UI. this implies that it's intended use is for operations that have a clearly defined finish that results in feedback to the user.

if you need an ongoing background thread, use an Executor to execute an instance of Runnable that hosts your ongoing operations. use this with care however, since when your app leaves the foreground, the thread will continue to run. carefully craft your Runnable such that it can be aborted (the run() method can be caused to return cleanly).

it's worth it to note that AsyncTask just forces you into a well-defined pattern for performing an asynchronous operation then updating the UI. IMHO it's overly complicated and makes a lot of assumptions, like a single-or limited size thread pool. for example, if one part of your app was blocking in AsyncTasks, would you assume that it would prevent an AsyncTask from running in another part of your app? it will.

Jeffrey Blattman
  • 22,176
  • 9
  • 79
  • 134
  • In my planned app, the background thread is tightly controlled by the UI thread. The UI thread starts and kills the background thread, and displays information fed from it. That's why I'm tempted by the async task, not an Executor. The problem is that the app needs to run for hours. – hubeir Apr 26 '13 at 23:46
  • @hubeir: "The problem is that the app needs to run for hours" -- then you need to be using a `Service` with some sort of `Executor`, and a messaging mechanism to let the UI know (if it exists) about work that was done. – CommonsWare Apr 27 '13 at 00:15
1

Definitely not. Async tasks are queued up, and one cannot start until the previous one completes.

Use regular threads for long-running tasks.

Edward Falk
  • 9,991
  • 11
  • 77
  • 112
  • 2
    (Note: depending on Android OS version and target API, it's possible for async tasks to run in parallel, but in general you should not depend on that behavior, and should consider async tasks to be run sequentially.) – Edward Falk Apr 26 '13 at 23:17
  • If the main activity only uses one Async task, and manages it carefully (only start the async task when the main activity is visible, and end it in any other status), does that prevent the queue-up? – hubeir Apr 26 '13 at 23:30
  • Probably, but that's a lot of work to do to avoid using threads. And you're screwed if some library you call from the main activity wants to use AsyncTask and you didn't know about it. – Edward Falk Apr 26 '13 at 23:32
  • @EdwardFalk the Android 4.2.2 `AsyncTask` has a thread pool size of 5. so yes, `AsyncTasks`s can run in parallel. – Jeffrey Blattman Apr 26 '13 at 23:32
  • 1
    @JeffreyBlattman: "the Android 4.2.2 AsyncTask has a thread pool size of 5" -- not by default for apps with `android:targetSdkVersion` of 13 or higher. `AsyncTask` is serialized for such apps, running on Android 3.2 and higher. – CommonsWare Apr 27 '13 at 00:17
  • According to my notes, AsyncTask runs in parallel in 1.5, in series in 1.6 through 2.3. In 3.0 and above, the behavior is controlled by the targetSDKVersion; if the target sdk is API 11 (3.0) or above, AsyncTask runs in series. – Edward Falk Apr 27 '13 at 00:34