I have 5 IntentServices that run at different times and in a separate process than the main UI. When the services complete they send the data via an intent to the main process. I am wondering if having 5 services is using too much memory for my application. Are services completely cleaned from memory when they shutdown or are they still allocating memory.
Thanks
It seems each service consumes some memory. Here is good discussion on this topic. Android service components facts
An IntentService automatically shuts down when there is no more work to do. After that, it should be eligible for garbage collection, assuming you have not done something to introduce a memory leak.
That being said, I would think it makes more sense to have one IntentService that performs all five functions, examining the incoming Intent to determine which thing to do.
You got nothing to be worry about, Android OS running dozens of services at the same time, it is completely safety.
Related
I want to have various asynchronous threads in app like around 5-10 threads for background tasks which can be long running (like streaming) and I am also updating the UI to post some results if necessary.
From what I have heard that AsyncTask has problems with:
Long running tasks,
Having poorly being tied to Activity life cycle,
Device orientation problems, and
Memory leaks and so on.
So, I am looking an alternative (possibly without using any third party libraries) which doesn't have these above problems.
Should I be better off with using Simple Java Threads? I don't mind using them given that they won't give any problems that are with AsynTask.
In most scenarios AsyncTask should suffice the requirement. However there are scenarios where AsyncTask can't be used. ie AsyncTask manages a thread pool, from which it pulls the threads to be used by task instances. Now the thread pools assume that they'll get their threads back after a reasonable period of time. So in a scenario where you do not know how long you'll need the thread you can't use an AsyncTask. And as of Android 4.4 , the size of thread pool can grow only to : (no of CPU cores * 2) + 1. So on a dual core processor, the maximum number of threads you can create is limited to 5.
So, I am looking an alternative (possibly without using any third party libraries) which doesn't have these above problems.
Coming to the alternatives to AsyncTask, these are the available options:
Handler
Runnable
Now there are cons to all background threads no matter how beautifully illustrated they are, few include:
The possibility of user's interaction while the background thread is processing. If the work that the background thread performing is altered, you'd need to communicate it back to the background thread. java.util.concurrent has many classes to help in these scenarios
The possibility of the process itself being killed while the thread is performing tasks. So in these cases instead of using an AsyncTask or the simpler Thread a Service or IntentService would be an ideal option.
The possibility of an error occuring inside the background thread, such as retrieving data from server while connectivity is lost, you'd need to manually shut down the background thread.
In short: Whichever option you choose, you'd need to manually handle
all corner cases for the efficient and splendid working of the app.
PS:
[Citation] : The busy coder's guide to Android development v5.8 by #Commonsware which is released under the Creative Commons Attribution Non-Commercial Share Alike 4.0 License
Long running tasks,
Having poorly being tied to Activity life cycle,
Device orientation problems, and
Memory leaks and so on.
Simple java threads are not going to solve any of these problems. Specially, memory leaks.
If you just want to load data in background, you can think about Loaders. They cache the data application wide and fit nicely with activity/fragment life cycle.
Alternately, you can go through this article to know about services (if you don't know already) and see if they are suitable in your scenario.
I would first suggest to use the above mentioned components,
Handlers
Runnables
If the operation is long running then you can go for service as it runs continuously. You said
which can be long running (like streaming)
If you are streaming over some audio or video then it is best to use a service either a normal Service or an Intent Service depending on your requirements.
You can destroy the service when ever needed or let the Android system do it when required.
Hence I would suggest you to use a Service in such a scenario.
We have a server application with java IO operations. When running the application, we have observed CPU usage for CompilerThread0 and CompilerThread1 taking 45% and 41% CPU. The application is serving IO to the clients at this time like connect, receive and send. As far as I explored related to this I found that the compilerthread is for JIT and for increasing performance.
My question is first, why it is taking much CPU for the compilerthreads and how to minimize this so that we can give CPU to other threads.
Thanks in advance!
My question is first, why it is taking much CPU for the compiler threads
Under normal circumstances, the JIT compiler should kick in after your application has been running for a bit to (progressively) compile the classes / methods that are called frequently. Compilation activity should die down ... once all code that needs to be compiled has been compiled.
If the compilation activity doesn't die down, then something strange is happening. It could be one of the following:
Your application is making a lot of use of dynamic proxies, and you keep generating new proxy classes.
Your application is dynamically loading (and unloading) lots of classes.
You've encountered a JVM bug of some sort. (But I couldn't spot a Bug Database entry that matches these symptoms. So I'd call this "unlikely".)
and how to minimize this so that we can give CPU to other threads.
There are potentially JVM options that might help, but I think you'd be better off figuring out what is causing this.
I'm new here and I'm not that very good in CPU consumption and Multi Threading. But I was wondering why my web app is consuming too much of the CPU process? What my program does is update values in the background so that users don't have to wait for the processing of the data and will only need to fetch it upon request. The updating processes are scheduled tasks using executor library that fires off 8 threads every 5 seconds to update my data.
Now I'm wondering why my application is consuming too much of the CPU. Is it because of bad code or is it because of a low spec server? (2 cores with 2 database and 1 major application running with my web app)
Thank you very much for your help.
You need to profile your application to find out where the CPU is actually being consumed. Java has some basic profiling methods built in, or if your environment permits it, you could run the built in "hprof" compiler:
java -Xrunhprof ...
(In reality, you probably want to set some extra options: Google "hprof" for more details.)
The latter is easier in principle, but I mention the possibility of adding your own profiling routine because it's more flexible and you can do it e.g. in a Servlet environment where running another profiler is more cumbersome.
Paulo,
It is not possible for someone here to say whether the problem is that your code is inefficient or the server is under spec. It could be either or both of those, or something else.
You are going to need to do some research of your own:
Profile the code. This will allow you to identify where your webapp is spending most of its time.
Look at the OS-level stats that are available to you. This might tell you that the real problem is memory usage or disk I/O.
Look at the performance of the back-end database. Is it using a lot of CPU?
Once you have identified the area(s) where the CPU is being used, you need to figure out the real cause of the problem is and work out how to fix it. And once you've got a potential fix implemented, you can rerun your profiling, etc to see it has helped.
I'm wondering what you can do programmatically to minimize the footprint that your service will have on a device? Are there any particular tricks to the way that you write a service so that it doesn't take up much system memory? I guess low memory footprint is my main concern so that a user does not want to turn the service off and is willing to have it always running.
***EDIT***
Okay so reading the answers I"m thinking that I must be doing this wrong. I am using the AlarmManager to periodically wake the service up but I am not ever stopping the service unless the user indicates via the main activity. So should I include at the end of my onStartCommand after my service performs what it needs to should I call stopService? Doesn't stop service call onDestroy because if it does I was deregistering my AlarmManager in onDestroy.
The way that it runs right now when I go to running services on my phone it has the service running but it is not actually doing anything until the AlarmManager goes off at which point it performs it's small function and that's it.
I guess low memory footprint is my main concern so that a user does not want to turn the service off and is willing to have it always running.
Theres a huge one for optimization. Androids services are not meant to run all the time (like Windows services or unix daemons).
They are more like a task solver, e.g. download a file. After finished with their task, they should call Service.stopSelf().
If your app needs the service again, it should restart it then for the appropriate task.
It really depends on what your service is doing so there's really no right or wrong answer. The important thing that I try to stay mindful of is not to keep the service alive for any longer than is required. If your service spends most of its time in an idle state, then consider waking it periodically with an alarm, and stopping the service once its periodic work is complete. This has the added benefit of preventing many task killers from destroying your service if it doesn't stay running for very long.
I also try and use inexact alarm as these are generally kinder on batteries, and battery life is also something that you should be mindful of.
In terms of memory footprint, it is always worth freeing up any unused resources, and keeping your code as lean and mean as possible, whether it is in a Service, Activity, Receiver, or anywhere else. Although current smart phones have considerably more memory than feature phones, Android is increasingly being run on comparatively lower spec hardware, so it's worth being mindful of lower end devices.
Reto Meier has recently written some articles which cover these sorts of topics on his blog.
I have a webservice created with CXF. In my service I run an application witch is very time consuming.
My application takes about 30 minutes to be executed but inside the webservice it takes about 1 1/2 hours.
Is there something I can do that my service gets faster?
There isn't any good reason for such a difference (assuming your doing the same work). You are going to have to work out what is different about enviroment or the input parameters you are using.
Try turning on -Xverbose:gc it may be that you have just about maxed out the heap on the servlet container and the JVM is speading it's whole life running the garabage collector over and over again.
Note you can also see using jvisualvm which comes with the JDK for free.
I would have a look at the application with jvisualvm in the Sun JDK.
My guess is that you have too little memory in your web service container, and that all the time is spent garbage collecting.
There really isn't enough information here to solve the issue, you need to figure out what is going on use some sort of tracing/profiling mechanism. It could be a memory issue. I don't know how you're actually launching the app, but it could be that its getting assigned a very low priority thread, vs a more user (high) priority thread when being launched by JUnit. The webservice itself would long time out before half an hour passed, let alone 1.5 hours, so are you using an ASync service or launching your own thread and/or process from the service? If its a separate process, how much memory is being allocated to that?
Once you've gathered this information, you're probably well on your way to really getting your answer.
YMMV