I am running a background thread that runs all through out the life cycle of application. Do we need to interrupt this thread in onDestroy method? or is it handled by android system? If we don't interrupt manually, will it lead to memory leaks?
It's a good practice to finish your pending tasks when the activity is gone, since basically whatever the thread does will not have impact for the user as it won't modify the UI.
Regarding memory leaks, android apps run in a linux process, so the context of the threads is the application, not the activity, that is why, when an activity is gone, your thread will keep running and you may update a death object. It's a good practice to stop it to avoid a memory leak because you keep a reference to what you want to update (of course, unless you use a WeakReference).
Related
I have seen some postings on this subject, but none of them have satisfactory answers.
Assume that I start a worker thread from my main (one-and-only) Activity, in its onCreate() method. Then I call finish() to cause the Activity to terminate.
At that point, the task it belongs to gets destroyed (since there are no longer any Activity in it). The app (and the process running it) may continue to exist, however, in empty "skeleton" form, so that it can be restarted quickly if desired (although it would be highly susceptible to being killed by the system).
Assuming the above is correct -- when is the worker thread killed? Is it only killed when the system actively destroys the process?
In my case, my worker thread exists as a listener for a Bluetooth connection; when received, it will fire up the desired Activity again. In this situation there is no actively running component (Activity, Service, ContentProvider or BroadcastReceiver). It seems to me that this should work, except that something is killing my worker thread.
I am aware that I could do this (and with less pain) by using a background Service. However, I'm curious about why this isn't working.
Thanks,
Barry
when is the worker thread killed? Is it only killed when the system actively destroys the process?
-> the worker thread is skilled after all its code in run function executed. It still run even when your activity is destroyed.
In my case, my worker thread exists as a listener for a Bluetooth connection; when received, it will fire up the desired Activity again. In this situation there is no actively running component (Activity, Service, ContentProvider or BroadcastReceiver). It seems to me that this should work, except that something is killing my worker thread.
To make it works, You need to have a background service in this case and make a soft/weak reference to your service from your worker thread or more simple, using EventBus to start any component from your Service as:
EventBus.getDefault().post(new BlueToothEvent()); // call in your worker thread
// do something in your service
onBlueToothEventFired(BlueToothEvent e);
Android App lifecycle has a nice example that is very on topic:
A common example of a process life-cycle bug is a BroadcastReceiver
that starts a thread when it receives an Intent in its
BroadcastReceiver.onReceive() method, and then returns from the
function. Once it returns, the system considers the BroadcastReceiver
to be no longer active, and thus, its hosting process no longer needed
(unless other application components are active in it). So, the system
may kill the process at any time to reclaim memory, and in doing so,
it terminates the spawned thread running in the process.
In short, its really not very predictable if you thread would get a chance to run until termination or process will be killed beforehand, you should NOT definitely rely on any order/behavior.
Worth mentioning separately that its fairly easy to leak your activity along with thread even if you finish() it, but if its your last/only activity it does not change the picture
When you start a thread, it is independent of the parent that started it. In your case, it is your application activity. This means that until the Run method has been fully executed, your thread will live.
If you exit the application (and therefore call the activity's onStop method), the thread will still exist, and you will cause a memory leak. It will eventually get killed by the system if you run out of memory.
Since you mentioned that you created a listener to listen for a Bluetooth connection, your thread probably dies before it receives any event (It is impossible for me to know without any code snippet). It might also crash which would be ending the thread.
There is one main (also called UI) thread in Android. That is the only thread your app uses, unless it starts one explicitly via Thread.start(), AsyncTask.execute() etc. All Activities, Services, BroadcastReceivers, etc run all of their lifecycle methods on that main thread. Notice I included Services- a Service runs on the main thread unless it starts its own Thread (the exception to that is an IntentService, which does run on its own Thread).
A Thread you create continues until the Runnable its passed returns from its run function (or of course the process is terminated). This can live past the end of the Activity/Service it was created by. However such a Thread would still live in the original instance of the component, and would not be able to access variables of a new instance if one was restarted without a lot of special work (see Loader pattern).
Store application global data
Someone said that android will clear singleton instance when task bring to background.
Is it true?
I realize that when I try to kill a foreground task(by using DDMS),the application auto restart it.There must be some deamon,isn't it?
Ofcouse,restart foreground application is safe to me,because as process restart,I can reInitialize my app by call Application's onCreate.
But I'm confused about background task/application.Will android kill background task and restart it just the same way as foreground app?(I hava try to kill background application,it exit without restart).Or will dalvik clear and recycle static instance?
If dalvik really really clear singlton,how do I avoid it?
Each Android application is running in a process. When a task (no matter background or foreground) is killed, actually the process is killed. It's just like the case that Java application runs on JVM, each JVM instance is a process.
There is no magic in dalvik object management which is different to JVM. I don't think dalvik will clear singleton instance. Object instance without reference will be clear on GC, but singleton should not.
In an Android application the main thread is event dispatch thread. It runs in loop, dispatches events to appropriate activities, widgets or services. Writing an application is actually implementing event callbacks: there is no main() in the code you write, you never own the main thread, the underlay framework calls your code when event happens. When the task turns to background, that is without any activities visible, there is no UI event generated, so you see that the main thread is waiting on the event queue. The article Painless Threading discusses the threading model used by Android applications.
I am a little confused about AsyncTask and Thread life cycle.
What happens to a processes threads when the OS enters the OnStart/OnStop and onResume/onPause sequences.
Are the threads affected by this sequence.
I ask this question because I am using sockets in the threads and killing the threads will kill the tcpip connections as well (I assume).
If the thredas are not killed then how do I 'reconnect' to them especially as they may will be 'connected' to an activity via a Handler.
Threads are not automatically killed when the app goes to onStop or onPause, however, there is no guarantee it won't be killed. Android will keep it running until it needs the resources that the thread is using.
Generally, if you want a persistent connection when an Activity closes, then put that in a Service. You can run threads in it just like an Activity (to prevent blocking that usually occurs with connections), and it's far less likely Android will kill it.
Internally, AsyncTask uses fixed thread pool. (See http://developer.android.com/reference/java/util/concurrent/ThreadPoolExecutor.html )
So, even if AsyncTask finished, thread does not die. But thread in thread pool can be killed.
My application makes use of a HandlerThread for a few operations shared across components that need to run on a background thread. Most of the time this thread will be in its wait state.
Can I leave this HandlerThread running (waiting) in my application, sending messages to it whenever necessary, but never quitting it via HandlerThread.getLooper().quit()? This could mean that this HandlerThread would continue to exist in its wait state even after all of my application components have been destroyed.
Initially this seemed like a big no to me—something I definitely would not want to do—but I'm not sure now. When Android kills my process, like it will do when it needs to free up CPU time or memory, it'll end this thread along with my UI thread. Additionally, the thread will be waiting, so it wont be consuming any CPU time. And beyond that, my application makes use of many AsyncTasks, which I know utilize a thread pool. From my understanding, AsyncTask utilizes ThreadPoolExecutor, which does not adhere to any application lifecycle callbacks (the threads in the pool when not in use, just sit waiting).
So my question is, can I use a HandlerThread across multiple application components, never (or rarely) quitting it, and leaving it waiting when not in use, without suffering terrible ill effects?
My personal preference is to create a new thread whenever there is a need for it and clean it up when it's done. This way I don't have any problems with multiple components trying to use the same thread at the same time and I keep a "clean ship". Also Android has the nice AsyncTask which makes this easy for you.
That being said, I see no reason why you can't reuse your handlerthread for multiple components, provided you regulate access to the thread AND clean it up properly when your activities are destroyed. If I understand this post correctly, your thread may keep running even if all your activities are terminated because your process may keep on running. To solve this, you can set your thread as a daemon thread. Daemon threads are automatically destroyed when the last non-daemon thread in your application is finished.
BTW, alternatively you also might want to consider using a ThreadPoolExecutor
My application has a thread pool that creates 3 simultaneous threads. As I invoke runnables, they are added to my thread pool.
My problem happens when the application goes to the background for a while. Eventually, my threads stop executing the runnables in my pool and the pool just continues to grow. Even if I bring my application back to the foreground, my threads do not start running again.
My theory is that when my application goes to the background that my threads are being killed. I'm not sure by what and I'm also not sure of a good way of determining whether my threads are killed so that I can start them again.
Do you have any suggestions as to something I can look for to determine whether or not a thread has been killed?
You can't use a thread pool to execute code in the background because the Android activity lifecycle won't consider your app to be active, and will kill your process (including all threads) eventually after you lose UI focus. What you want is an Android Service which has a different lifecycle. To do things like this we use a local service with a Handler and a HandlerThread that we can post Runnables into. You'll probably want something similar.
Note: Every time I do this I feel like there must be an easier way, so it might be worth searching if someone has simplified this pattern.