CODEWITHSUNDEEP
android
Che Jami
Che Jami

Reputation: 5151

Android: Separate Thread vs Separate Application

Suppose you have an application that spawns a local HTTP server on an Android device.

Will there be any advantage to running it in a separate application instead of spawning a separate thread?

Since the heap size is capped per application, I'm assuming that there is more breathing space for memory when running a separate application.

Apart from this, in terms of performance are there any other benefits (or disadvantages) such as a bigger chunk of CPU time?

Upvotes: 2

Views: 495

Answers (5)

Nav
Nav

Reputation: 10422

In most cases you will get a boost in the performance of you app if you run your server in a separate process via service but not always. NOTE: service can run in a separate process of its own but for that you have to provide android:service tag in the xml.

One big flaw in this type of design which I think you already know is that , in android each process runs in its own virtual machine.So if you spawn a new process it will get its own VM. Now you yourself consider which is better.Running one VM for the whole application or running two of them. (In most cases I have heard of at least in android 1 VM is more than sufficient to handle everything you need)

Apart from that another flaw is that when you separate the process from the main process of your app e.x you are running your server service in a separate process then it may not shutdown even though your app comes across an exception or error as its a separate process from that of the main process and is not tied to the life cycle of your app anymore.So it can lead to some unexpected behavior and can cause your app to malfunction.

If you are OK to take the risk than go with it otherwise go with threads(I would recommend Asynctask within a service) for the purpose you are seeking as it will provide you with almost the same functionality while being safe inside the application scope/lifecycle.

hope this helps.

Upvotes: 0

Ilya Gazman
Ilya Gazman

Reputation: 32221

First, you don't need separate application for that, you define another process for your own application. In most cases doing such thing will boost your performance because there is bigger chance that your process will actually run on separated physical process. How ever the Android OS does not support this yet, not event in Android 4.03.

So the only benefit you will get from this is memory, witch in my opinion should not be a reason for opening another process.

Upvotes: 0

hackbod
hackbod

Reputation: 91331

Using separate processes can significantly increase the memory footprint of your app. Not only do you get a multiple of the core Dalvik overhead (figure 2-3MB per process), but none of the RAM used by your app can be shared (such as static symbols and such in your code).

Plus you have more CPU overhead because you now need to do IPC for any interaction between those different parts of your app that cross boundaries. And you have a lot more complexity in implementation because you actually need to implement that IPC and figure out how to correctly manage these different parts of the app that are running in isolated address spaces.

For the vast majority of situations, I don't think it is good to use multiple processes.

Upvotes: 1

jjNford
jjNford

Reputation: 5270

The one big disadvantage I see that happens when running application components in different threads is that the two parts will be in different DVMs. This can make sharing Preference changes, Listeners, Observers, ect, not work as you would expect, you would also have to make sure all DB access is synchronized.

To counter this point if you synchronization correctly and don't need preferences you can use bundles or AIDL to communicate back and forth from the 2 applications. The best bet is AIDL for 2-way continuous communication, but be aware AIDL can be expensive. The other option for communication is a socket... but this goes against the SDK that is provided. A trick I have learned when doing this is to create an API jar file to include in both applications that will handle all communications (by way of intent or AIDL - blackbox approach).

Personally I think application components that are similar should stay in the same DVM and application unless they can run as stand alone then you have to be the judge of that.

Have you though about running the HTTP server as on ongoing foreground service? This would uncouple your design as well as make things easy and lighter.

Upvotes: 1

user942821
user942821

Reputation:

There is a remote service example in SDK.

If you go with two apps, you will absolutely need remote service. And that is only way to communicate among apps, as my experience.

From my viewpoint, it is not good with the concept "server" to be used on a cell phone. But perhaps you have your reason...

Upvotes: 0

Related Questions