AFAIK, android uses Single thread architecture, where all UI components event are dispatched,i.e. main thread or UI thread.
But why we cannot perform UI operations on separate thread other than main thread?
The main problem is related to the context. In a background thread you could update some UI stuff which is not in the current context. This is one of the reason.
UPDATE:
From the Android developer guide:
Additionally, the Andoid UI toolkit is not thread-safe. So, you must
not manipulate your UI from a worker thread—you must do all
manipulation to your user interface from the UI thread. Thus, there
are simply two rules to Android's single thread model:
Do not block the UI thread
Do not access the Android UI toolkit from outside the UI thread
You can read more on thread safety from [1] [2] and you can read even [3] with a small exmaple and explenation!
Hope that now it is more clear sorry for the short and quick answer before :)
Well, first of all I need to state that this is a design level problem that has been discussed by many generations of programmers :)
Now technical details:
A GUI framework is a very complex thing. A GUI framework needs to display (draw) certain views (or windows) and route external (mostly user) inputs to the view that the input is targeted to. Now, to manage the screen with views with proper event dispatch to each view, all views shall be part of a graph and the simplest form of such a graph is a tree. So, you essentially have a tree of views to manage - where information should be fed to a root view from where your whole event routing takes place to child views.
Naturally, one dedicated thread to do manage this view hierarchy and event routing by monitoring a message queue to which all these drawing and input events are posted - by itself or any other threads - is a neat and simple solution. Any other solution that involves more than a thread will make the already complex view management and event routing code prone to dead/live locks.
Along with these technical details, you need to keep it in mind that you are trying to do business with a framework which is going to be used by other people who usually don't have faintest idea about the inner details of your architecture. Introduce threading support in such a framework is an open invitation for synchronization bugs (read: deadlocks, grumpy end users who are programmers AND ultimately bad business).
Android (and 99% other GUI toolkits) adopts this method. Simply because it makes things simpler and less error prone to have one main thread to deal with all error prone processing. All other threads are free to request it to do things by posting messages to the main thread's message queue. It is a balance between complexity and stability.
The only drawback of this approach is smooth updates of views - if you have many views to update simultaneously, OR your view hierarchy itself is really nested and complex. This drawback of this single threaded architecture manifest itself in pretty obvious forms in Android like:
Animating multiple views simultaneously is never smooth - unlike iOS where they have taken the pains to move certain parts of this operation to more than one threads of execution.
Android documentation need to remind the programmer all the time not to do lengthy operations in main thread AND to avoid deeply nested view hierarchies.
Related
Recently, I try to use MVP Pattern in my android project.
I know that I can't do bussiness logic job in View layer. View must deliver all works to Presenter layer then wait for the result from Presenter.
View should do anything in UI thread. But Presenter may do something in Sub-Thread.
How do I control MultiThreading in View layout and Preseneter layer?
Any help will be highly appreciated.
You have two directions you need to communicate:
a) non-UI to UI thread
and
b) UI thread to non-UI thread.
For the first case, a popular way these days is to use runOnUiThread()
Here's a nice survey of this technique and other popular options:
http://www.intertech.com/Blog/android-non-ui-to-ui-thread-communications-part-1-of-5/
As for the other direction, it is not typically necessary unless you have slow blocking operations. It is more a question of clean organization of your source code. A modern technique for sending results back from View to Presenter is using custom interfaces in Fragments like this in the "Communicating with the Activity" section:
http://developer.android.com/guide/components/fragments.html
Note that you should not put long running operations on the UI thread because it will make your app feel sluggish. Try to run them on a different thread if they will take more than 50 milliseconds or so.
Android already separates the functionality of the UI and the controller (or Presenter). It's really your job to separate it even more to make it follow the MVP pattern stronger. The view is on its own thread separate from your presenters. You won't need to do anymore threading for that unless you'd like to for whatever reason.
When I say separating it farther I just mean implementing a structure that abstracts the handling of data to be able to be reused or changed easily.
As we know, when we update the UI from the non-ui-thread, we use Handler or AsyncTask. We can find a lot of articles on how to use these methods on the Internet. But I cannot find an explanation on why a UI element cannot be operated from the non-ui thread? Can anyone help me?
I believe this decision was made by the Android team (and many other UI frameworks for that matter) because of the following reasons
Synchronization
Security
Performance
Synchronization
The simplest reason for following a single threaded model for UI is that it is the easiest way to ensure that the User Interface is not being updated by multiple sources at once and therefore, corrupted. If you imagine that multiple threads can modify the UI, it would take each thread its own amount of time to execute a portion of its code, and with the different execution speeds generate a bad user experience.
Security
Ensuring that one thread can access the UI is also a security measure, preventing any slave threads that accidentally (or purposefully) try to corrupt the UI from doing so, simply by not allowing it.
Performance
The core fact of the matter here is that UI operations, and re-rendering and re-drawing visual layers and elements is an expensive process. It can affect the performance of the framework and cause leaks or lags with the deadlocks and synchronisation in-between. So I believe this was done for the sake of performance too :)
I suspect it's because a UI is a state machine, having multiple threads operate on a single state machine makes it difficult or impossible to reason about the current state of the UI and what transitions are available at any given time. There would be unpredictable results, so it's best to keep it separated from code executing in an AsyncTask.
Short verson
Is it allowed, or do I need to use the UI thread?
EDIT: A reference to a place in the official android docs would be ideal.
Long version
Android docs make it clear that it's not allowed to "access the Android UI toolkit from outside the UI thread".
On the other hand, creating Bitmap objects from worker threads seems to be allowed, at least it's being done in sample code:
http://developer.android.com/guide/topics/fundamentals/processes-and-threads.html
Apparently, the Bitmap class is not considered part of the "UI toolkit" as far as threading is concerned.
I've got a piece of code that seems to work when invoked from a non-ui thread. It involves using Bitmap.createBitmap(int,int,Bitmap.Config), new Canvas(bitmap), Typeface.create() and text drawing. My code does not refer to any View object.
Can someone point me to a piece of documentation that says that I may do these things from a background thread? Or will doing this lead to random crashes?
UI toolkit means UIs such as buttons, labels, listview, and so on provided by Google. You can't access them from non-ui thread mainly because they are not thread-safe.
What you are doing is not on UI toolkit but on low-level Canvas which is allowed (actually should be allowed) to access from non-ui threads. This mechanism is used in game development all the time. So I believe you are safe.
Updating views has to be made on UI thread, or from remote thread with post function (which basiclly tells UI thread that remote thread wants something to be done), which is part of View class.
It should be legal as bitmaps just sit in memory all by themselves before you draw them.
I am looking into game development, in it seems there are some threads updating the UI ther too (using a similar technique of doing in-memory rendering)
I'm trying to develop a game. It's a simple whack-a-mole type of game where something pops-up the screen and you click on it to kill it. I was thinking of giving the "moles" their own thread so that they can do their own animation, event handling, etc. in their own lifecycle until eventually killing themselves.
Will this kind of "each object has its own thread" implementation be good for an Android game?
Definitely not. Do not give each mole its own thread. This would be too much use of threads while it is needless to say that in this type of game you do not need such a number of threads. Just keep everything in the main thread and use some listeners to kill moles. (=make invisible)
Yes, it is a performance issue and a matter of developer's decision. Why should you create a thread for each mole? This is the right question because doing so is a far more unrealistic decision. Will each mole access a database? communicate with a server? I don't think so.
Anyway, since it is a mole on the screen, you will only need one instance of it that you can render/move it around/disable/etc in the main thread.
This could work, if there aren't a ton of objects, and a ton of activity for each object.
I would suggest thread pooling. Pull out inactive objects out of threads and put in active threads.
Stay single threaded until you actual need to change - especially for a simple game, you won't have the kinds of performance problems that need threading.
At any rate the general approach is not to thread out individual entities, but entire steps of algorithms performed across 100s or 1000s, or even entire systems (e.g. audio, physics etc.) - and perhaps the most extreme but common case is to split your rendering submission into its own thread for all rendering, with animation, physics, gameplay logic etc on another thread, in exchange for single frame latency on everything.
Not to mention that the overhead of having very many threads often becomes limiting - if you have 2 or 3 moles it might be fine, but if you have many more you will quickly reach the point of diminishing returns - not to mention the difficulties inherent in keeping many threads in sync and avoiding deadlocks, race conditions etc.
Curious to know the reason behind not allowing updating UI elements from background thread in Android.
Will main thread does something more (probably interacting with framework) after updating the UI elements so that changes can be seen on the screen.?
Is it the same case with other GUI tool kits?
If all threads were permitted to update the GUI objects, they'd have to be designed for thread safety (since the GUI must track its underlying state), introducing locks or critical sections around member variables and other shared resources. This would
slow the GUI down
complicate the code,
not be 100% safe anyway.
Concurrency is hard, and any framework designer has to compromise. Now the burden is on you to ensure things happen in the right thread. You should isolate worker and communications tasks from the UI anyway, so it doesn't really add all that much of an onus.