What are the practical differences between putting a service in a separate process or keeping it in the app's main process? What would each scenario be used for?
Asked
Active
Viewed 9,675 times
5 Answers
11
When a service is running in the main process it will be stopped in case your application crashes for whatever reason. Put a service into it's own process is reasonable for some services which can be used from different applications or services which should run independently from your main app.
Denys Nikolayenko
- 578
- 8
- 14
7
The only reasons I see for putting a service in another process is
- The application is resource heavy and likely going to be killed quickly by the OS. Putting the service in a separate process will distribute the resources and if you application dies your service won't.
- JUST in case your application has errors and dies your service will keep going.
However if you create a good application and use good programming you should not run into either of these issues. By having your service in a separate process it causes trouble with things like SharedPreferences and concurrent DB access... I would recommend not doing it.
Not to mention... another process means another DVM. This will take more resources than running in one DVM and slow things down.
jjNford
- 5,170
- 7
- 40
- 64
2
Also putting service in another process makes your changes of static variables invisible for main process. You can get situation, when you assign a variable with some value, and it is not changed!! I spent whole day for this issue!
insomniac
- 379
- 5
- 7
-
-
@William what you suggest to use ? put my variables in APPLICATION class ? – mhdjazmati Mar 08 '17 at 13:11
-
Yes. Place them in an Object that you understand the lifecycle of. I generally use the Application class. – William Mar 08 '17 at 22:11
1
Following is a quote from Android Developer's web site.
Note that services, like other application objects, run in the main thread of their hosting process. This means that, if your service is going to do any CPU intensive (such as MP3 playback) or blocking (such as networking) operations, it should spawn its own thread in which to do that work.
Jake points out that you can, thru manifest, control the Name of the process it is running. But following findings from Documentatioin:
Most confusion about the Service class actually revolves around what it is not:
- A Service is not a separate process. The Service object itself does not imply it is running in its own process; unless otherwise specified, it runs in the same process as the application it is part of.
This is interesting, what is said Here is:
The name of the process where the service is to run. Normally, all components of an application run in the default process created for the application. It has the same name as the application package. The element's process attribute can set a different default for all components. But component can override the default with its own process attribute, allowing you to spread your application across multiple processes.
But anyway, if you need Service to be exposed to other applications, for example, you need to provide content (like phonebook) to other applications, setting service to run in different process is the reason.
-
3Actually you have very specific control over process. See http://developer.android.com/guide/topics/manifest/service-element.html [the android:process tag] – Jake Nov 03 '10 at 02:38
-
-1
Using the process attribute of a service is rejected by the manifest parser so it is rather misleading!
warrell
- 1
-
1Eureka... this link http://www.androidsoftwaredeveloper.com/2009/03/20/how-to-start-on-boot/ shows that the process name MUST start with android.process e.g. android:process="android.process.myservice" – warrell Dec 02 '10 at 10:26
-
2Any broadcast receiver that it communicates with must also be in that process so it should have the same name e.g. android:process="android.process.myservice" – warrell Dec 02 '10 at 10:28
-