views:

197

answers:

4

As my app matures, I find myself finding more and more uses for threads. By now I must have about 25 threads, all doing important things and working together in symphony.

I notice however that my app is sitting around 15.5MB resident. Compared to the browser (+/-35MB) I feel pretty safe, but I do notice the resident size of my app ever increasing.

The question is, how much overhead is involved with adding a thread?

I'm also wondering if the synchronized keyword encounters more and more latency with each new thread that is present?

Thanks!

A: 

Uncontrollable number of Threads can be overhead to application. Your APP already seems to have higher number of Threads for mobile app.

synchronized does involve maintenance for locks on objects.

Checkout if you can use ThreadPoolExecutor. This will help limiting threads in system , also reduce little overhead of creating and destroying threads.

YoK
+1  A: 

Threads are very useful but at the same time they can be a menace. I am working on a project to check threats presented by an application. If you run top via the adb shell, it specifically tells you how many threads an application may be running.

You will see processor usage is directly proportional to the number of threads. That pretty much means more the number of threads higher is the overhead. Though they seem to keep your activity free from getting stuck at time it may become a real pain to synchronize their actions and then you may have deadlock, not very pretty. Also multiple no of threads raise suspicion about the behaviour of an application. Hence they should be utilized in the spirit they are meant to be. =)

Shouvik
Interesting thought: "more threads ~= unscrupulous activity"... All of my threads are on the up and up, but I'll take that under consideration :) Thank you for the adb advice, I didn't realize the top utility showed threads!
Brad Hein
Er there is nothing suspicious from a security perspective about an app that has a lot of threads.
hackbod
@hackbod you maybe right, but I have found threads to be a nuisance. Some applications who's activities I don't care about once I quit somehow happen to keep the process alive by using threads. Now that I would call suspicious activity1
Shouvik
Threads can't keep a process alive. They can certainly keep running while an app is in the background, if the app is poorly written, which is not desirable. (Though perhaps not has horrible as you might thing on Android, due to things like the background scheduling class and wake locks.) And of course unless you are good at multithreading (most developers aren't) you want to stay away from the raw Thread class and locking and use higher-level facilities like AsyncTask. That said, AsyncTask's pool is potentially like 8 threads and Binder's is 16 so those can generate a lot of threads. :)
hackbod
A: 

If you're creating and destroying threads over and over again then yes it will be taxing and cause overhead. You can eliminate that by utilizing the ThreadPool, which keeps a cache of threads available for execution. Otherwise, threads are the way to go over processes.

You may want to think of practical adjustments to the architecture. For example, if you're keeping multiple threads alive for the sake of having a responsive UI, (i.e. waiting for input) even if a particular thread would only be used after five menu jumps then maybe its not necessary to keep the threads alive all the time. I have rarely used 15 distinct threads in a single application, even when that application ran a massive machine tool....(I had repeat worker threads going though). Don't forget that threads still have to be scheduled so don't keep them around needlessly.

Lastly, make sure that you're not running into the same old problems with parallel program; avoid deadlocks etc....

Ayubinator
Almost all threads are created just once for the life of the app. Thank you for the note about the machine tool, that helps put it into perspective. Yes I have used so many in order to keep the app very responsive to the user. I have also found that the many application layers work well together in the asynchronous multi-threaded environment. I like the threadPool idea, thank you.
Brad Hein
+2  A: 

For some perspective here, a freshly launched Browser app has about 20 threads running. Having 25 threads is not utterly unreasonable. It really depends on what you are doing with them.

app_1     17309 67    182452 27944 ffffffff 00000000 S com.android.browser
app_1     17310 17309 182452 27944 ffffffff 00000000 S HeapWorker
app_1     17311 17309 182452 27944 ffffffff 00000000 S Signal Catcher
app_1     17312 17309 182452 27944 ffffffff 00000000 S JDWP
app_1     17313 17309 182452 27944 ffffffff 00000000 S Compiler
app_1     17314 17309 182452 27944 ffffffff 00000000 S Binder Thread #
app_1     17315 17309 182452 27944 ffffffff 00000000 S Binder Thread #
app_1     17317 17309 182452 27944 ffffffff 00000000 S CookieSyncManag
app_1     17319 17309 182452 27944 ffffffff 00000000 S WebViewCoreThre
app_1     17321 17309 182452 27944 ffffffff 00000000 S AsyncTask #1
app_1     17322 17309 182452 27944 ffffffff 00000000 S AsyncTask #2
app_1     17323 17309 182452 27944 ffffffff 00000000 S WebViewCoreThre
app_1     17324 17309 182452 27944 ffffffff 00000000 S http0
app_1     17325 17309 182452 27944 ffffffff 00000000 S http1
app_1     17326 17309 182452 27944 ffffffff 00000000 S http2
app_1     17327 17309 182452 27944 ffffffff 00000000 S http3
app_1     17328 17309 182452 27944 ffffffff 00000000 S WebViewWorkerTh
app_1     17329 17309 182452 27944 ffffffff 00000000 S AsyncTask #3
app_1     17330 17309 182452 27944 ffffffff 00000000 S AsyncTask #4
app_1     17332 17309 182452 27944 ffffffff 00000000 S AsyncTask #5
hackbod