1

I have been using multithreading in my softwares. However the thing that confuses me, how does multithreading increases performance of an app? In my knowledge, a process/app is assigned a single thread by the OS. If you create multiple threads inside that process, those threads aren't like a whole new batch of threads assigned to the process by OS. Instead one thread executes at a time while the other thread is waiting. I might be wrong about this, therefore I would like to clear this confusion.

Example regarding non UI threads & UI threads will be very helpful.

EDIT:

I take it, as long as I don't pass Mainthread in place of a runnable, instance of the Handler will create a new separate UI thread which is in no matter related to/puts load on mainUI thread at all, Right?

// executes code on mainUI thread thread?
new Handler(Looper.getMainLooper()).post(){
    ....
}
// creates a separate UI thread that isn't related to/executes code on mainUI thread at all, Correct?
new Handler(new Runnable()).post(){
    ....
}
user2498079
  • 2,872
  • 8
  • 32
  • 60

3 Answers3

5

how does multithreading increases performance of an app?

Generally speaking, it does not increase the performance of an app. It may solve specific problems in terms of UX, such as decreasing jank.

In my knowledge, a process/app is assigned a single thread by the OS.

No, an Android app will have several threads at the outset, created by the framework. These include the main application thread and a pool of binder threads.

If you create multiple threads inside that process, those threads aren't like a whole new batch of threads assigned to the process by OS.

Yes, they are.

Instead one thread executes at a time while the other thread is waiting.

On a multi-core CPU, multiple threads can truly execute in parallel. Even on single-core CPUs, the Linux scheduler (part of the Linux kernel at the heart of Android) will time-slice between threads.

Example regarding non UI threads & UI threads will be very helpful.

The main application thread (a.k.a., UI thread) is, at its core, just a thread. However, it is the thread that is responsible for dispatching key and touch events and otherwise applying UI updates. It is important not to block that thread, and so if you are running on that thread (e.g., onCreate() of activities and fragments, onClick() of a widget, getView() in a ListAdapter), you need to return very quickly, ideally in well under a millisecond. Otherwise, you have "jank", defined in Android as being a frozen UI, particularly while the UI should be animating (e.g., scrolling a ListView).

So, for example, let's suppose that we want to download a file, one big enough that it will take 10 seconds to download. Whether we download the file on the main application thread or on a background thread does not impact overall performance, as it will take 10 seconds either way. However, downloading on the main application thread would freeze our UI for 10 seconds, which will make users unhappy. Downloading the file on a background thread avoids this problem. Note that trying to do network I/O on the main application thread fails by default on Android 4.0+ (with a NetworkOnMainThreadException), specifically to avoid this particular problem.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Is the pool of binder threads also available for UI thread? OK. So how does Handler(UI) threads take the load off the Main UI thread, if its the only UI thread? In my exeperience, if my app needs to do some performance intensive UI task & if I do it on main UI thread, it will cause janks. However if I put that task inside a Handler thread, the app's performance isn't affected. Why? – user2498079 Apr 26 '15 at 15:23
  • @user2498079: "Is the pool of binder threads also available for UI thread?" -- I have no idea what you mean by this, sorry. "However if I put that task inside a Handler thread, the app's performance isn't affected. Why?" -- because a `HandlerThread` is a separate thread. You will notice that [`HandlerThread` is a subclass of `Thread`](http://developer.android.com/reference/android/os/HandlerThread.html). Work done properly on a separate thread will not block the main application thread and reduces the possibility of jank. – CommonsWare Apr 26 '15 at 15:26
  • I was talking about [Handler][1] [1]: http://developer.android.com/reference/android/os/Handler.html I take it, as long as I don't pass Mainthread in place of a runnable, instance of the Handler will create a new separate UI thread, Right? – user2498079 Apr 26 '15 at 15:30
1
  1. Thread and Process are not the same. (see links at the end)

  2. If your device have a single processes (single core), then threads will not run in parallel, but they will switch execution, repeatedly, which will be managed by OS/compiler.

  3. But if your device is multi-processor (multi-core), then threads will execute parallel on different cores. Here, programmer have to be very very careful about race condition / synchronization issues.


  1. So, in simple words, threads split the burden from one core to multiple cores, that's how threads improves performance.

  2. Other than threads, in general, It is compiler's job to identify independent sequence of code statements and run it on different cores in parallel, to get maximum performance (speed). So, It is also on developer to write code in such a way that it can be executed, in parallel, on multiple cores easily.

  3. If you are interested in threads and concurrency, see this book, it covers every aspect (Java and Clojure) Seven concurrency models in seven weeks


What is the difference between a process and a thread?

http://www.programmerinterview.com/index.php/operating-systems/thread-vs-process/

Community
  • 1
  • 1
0

You can run threads parallel using thread/pool exceuter in multi core, workers threads are use to do some work in background, which may or may not be sent data to main thread to update UX. For example in your listview you have thumb images for every row, if you will not use separate/worker thread(s) than main thread will block. While for thumbs for each row we use parallel threads to download images and display in respective row, now worker threads are responsible to download thumb which may take seconds, after downloading, that thread will return image to main thread and now set image to its specified location.

Haris Qurashi
  • 2,104
  • 1
  • 13
  • 28