How is thread priority managed in Android? (Or what is the threading policy in Android?) GUI threads would be assigned higher priority, right?
I've seen applications that create separate thread to clean up (native) resources since finalize() is discouraged. However, there is still memory leak (or memory inefficiency) since the cleanup thread is not running frequently enough.
Some other apps, those ignoring the advice on not to use finalize(), rely on the finalizer to clean up resources. So I'm wondering how is the finalizer thread scheduled? Is it a reliable way to release resources, either managed or native?
I would strongly recommend you to use AsyncTask for doing something in different thread. AsyncTask is very easy to use and I would say that it is one of the biggest advantages of java. I really miss it in obj-c.
Async task got method
onPostExecute(){}
in which you can clean whatever you want after thread done it's job.
http://labs.makemachine.net/2010/05/android-asynctask-example/
http://marakana.com/s/video_tutorial_android_application_development_asynctask_preferences_and_options_menu,257/index.html
Links with tuts about AsyncTask.
About priority: threads in android are threads in java, and they have priority from 0 to 10.
You can set them for each thread as you would like.
And about
finalize();
you should avoid using this method. As I already said u should better use AsyncTask class instead of Thread.
Related
At the moment I'm writing tests and think about to export all File-I/O-Operations into separate threads within my GUI-App, because I fear that a large file can block the main-thread. This wouldn't be user-friendly.
Its common to export File-I/O-Operations into separate worker-threads?
Well, it depends, but generally it is a very good idea. If your main thread is your event pump, then yes; it is highly recommended to execute lengthy operations in separate threads. Particularly if the app is using a slow GPRS/3G connection, you typically don't want the app to block when using the network. Local file operations can occasionally be quite slow as well, depending on how busy the device is.
The Java Swing Worker model is an example of how to do this in a modular and thread-safe way. I suggest you study it for inspiration as it is well documented. Then again, I am sure Android has similar facilities for executing code outside the main thread.
If you are writing (unit) tests for it, I suggest establishing a pattern where you can inject your worker code as part of the test and keeping your I/O code strictly outside of context from the main thread. That way, you can simulate how the app behaves during slow connection without actually having to use the network at all.
Android documentation, tutorials, videos and the like are filled with best practice on how to avoid non-essential processing on the UI thread. However, when creating a big app or using external components it can be hard to remember which methods block the UI thread and which do not. I've often seen threading mentioned in comments, but that seems error prone for lazy/rushed situations, and not everything gets an ideal code review.
What naming, annotation, or other conventions exist to help developers quickly determine if the methods they are considering are UI thread optimized or not?
Why does a service not run in it's own thread under Android? And what were the design considerations?
It is all about Flexibility: I assume you are familiar with so many Frameworks like for example e.g. Volley, Retrofit etc. These Frameworks has their own Thread implementation behind scene so if Service by default is executed in a separate Thread then it is overkill. Why? because the threading is handled by the framework already so why the need to have another thread?
See also Why is creating a Thread said to be expensive?. And put also into consideration that you are doing Threading in an Android device and not into a powerful Desktop.
Take a look at IntentService I think this is that you are looking for.
It gives you more flexibility. For example you could run each request in a seperate thread with special priorities or you could store the requests in a queue and only start the next thread if the previous one has finished. A IntentService provides a default configuration that in the most cases fits your needs from scratch.(http://developer.android.com/guide/components/services.html). Such decisions depend on your use case.
The Andoid UI toolkit is not thread-safe, when you try to modify the UI from a worker thread you get the CalledFrowWrongThreadException (or something like that).
Moreover, the dev guide say:
[Manipulating the UI from a worker thread] can result in undefined and
unexpected behavior, which can be
difficult and time-consuming to track
down.
But it does not seem to me very difficult to understand what a CalledFrowWrongThreadException mean.
Does the documentation was written before the introduction of CalledFrowWrongThreadException or are there still cases where the exception is not thrown? (or where the error is indeed difficult and time-consuming to track down)
The main issue here is that checking what thread is calling a given function incurs a processing overhead; there are almost certainly calls that don't check for precisely this reason - it would slow down the UI rendering.
By extension, the reason UI functions aren't thread-safe is that if you through mutex code into the equation, the performance hit becomes even greater.
Just like Swing in Java, and WinForms in .NET, there may be cases where the method in question does not check to determine that you are calling from the proper thread, and therefore does not necessarily throw the expected exception.
Providing the above documentation is a way to cover themselves and explain a simple idea that actually requires a lot of effort to work around if you do not know it, or understand it, before the wrong thread exception is ever thrown by offending code, which may be much later down the road.
I'm looking into writing simple graphics code in Android and I've noticed some synchronized() blocks.
What is the reasoning behind this and how do I know when I should be "synchronizing" my code?
synchronized statement blocks are commonly used in concurrent programming (multithreaded applications), where your application utilizes many threads. As an example for an Android game, you could have one thread with client processing, other for the server, one to spawn other processes, etc.
The keyword itself ensures that your methods will be accessed one thread at a time, which makes them thread-safe. If your application were to share resources without using synchronized statements, you run the risk of deadlock occurring.
Deadlock will result in a hang-up, i.e. the process hangs up. Deadlock should be avoided at all cost especially dealing with the size of processor of a mobile phone.