Android Enthusiasts Stack Exchange is a question and answer site for enthusiasts and power users of the Android operating system. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I read a statement on that said:

When an application is launched, the system creates a thread of execution for the application, called "main." This thread is very important because it is in charge of dispatching events to the appropriate user interface widgets, including drawing events. It is also the thread in which your application interacts with components from the Android UI toolkit. The system does not create a separate thread for each instance of a component. All components that run in the same process are instantiated in the UI thread, and system calls to each component are dispatched from that thread.

I just wanted to know why Android has opted for this single threaded model architecture and not gone for multi-threaded. What are the advantages that they are getting out of this?

share|improve this question
As your question suggests a "more threads the better" philosophy: be aware that having more threads than cores carries an ever increasing performance penalty. So if you have a dual core phone/tablet(or PC) you only really want 2 threads that are actually doing significant work (and probably a third that is handling user interaction). Applications where everything has its own thread are generally painfully slow – Richard Tingle Jun 6 '14 at 8:51
up vote 18 down vote accepted

Android apps aren't single-threaded. Although there's one main thread as described in the documentation you quoted, apps can start as many other threads as they need.

The advantage of all GUI interactions being on one thread is that the GUI code can be simpler, faster, and more predictable, because GUI state isn't being changed concurrently from different threads. It also makes thread-safety easier for app developers by providing a message queue, similar to those found in other OSes' GUI frameworks. The app author just needs to make sure all long operations are performed in background threads, sending messages back to the main thread to update the GUI, and that way the GUI remains responsive all the time.

share|improve this answer
My first "big app" when learning fell into this trap. A big database lookup on the same thread as the UI, so you can't interract at all or use a 'cancel' button as the GUI thread is tied up. It teaches you fast to use threads / asychronous tasks. "main" is usually the point of execution in programming and the initial or 'main' thread of an application like int main() in C or public static void main(String[] args) in Java and so on. It runs as the main bit of your appliction, as something has to be the starting point. – RossC Jun 5 '14 at 14:35
+1. NetworkOnMainThreadException just proves that an Android app supports (and sometime, needs) multiple threads to work functionally. – Andrew T. Jun 6 '14 at 7:40

The Android docs are just saying the main thread should compute all UI related functions. It's the job of the developer to create additional threads when getting data from local SQLite database or from the network, or even if you're creating a compute heavy custom View with alot of display logic.

For a really comprehensive look into Concurrency in Android and mutli-threading, check out

Asynchronous Android from Steve Liles

Awesome awesome book.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.