What are pros and cons of using multiple processes within android application

Question

I am writing this question not as part of any specific application, but as part of potential use for future applications. I know that the answers to this question can be very application specific, but I hope you will bear with me. I will convey my understanding as is, and hopefully you can help me by extending it. Surprisingly in vain, I have searched the web for a 'complete' overview and have not been able to find it. Any links to relevant pages are welcome obviously.

An android application by default runs in a single process. Each Activity or Service that you start will by default even run in the main thread. All actions by the user are queued by the Looper of the main thread, and the respective callbacks are handled in the main thread.

In order to provide concurrency, threads can be started in lots of different ways, single or in pools. There is not explicit need in this regard for multiple processes. Using multiple processes to allow the multiple cores of your device to work in parallel is not necessary since Threads can be run in parallel as well, maybe even your main thread? But perhaps it will be easier to actually achieve?

In order to let an Activity or Service work in a specific (potentially different) process you only set the android:process attribute in the Manifest file. So easy to implement?

The Android framework is specifically built for mobile devices, which typically have limited memory to go around with. Therefore processes can be killed under a variety of circumstances, clearly stated here. As long as you implement the lifecycle callbacks of Activities and Services, such as onStop or onDestroy, this should not give any real problems. But obviously compartmentalizing pieces of your application, by using multiple processes, could potentially keep more important things alive. For instance a background download Service could be kept alive (level 3 in importance), while the process with the initial Activity that started this Service, now in the background (level 4) could be freed for its resources. Furthermore the fact that you are isolating core features of your application might allow your device to make better use of its resources?

The Binder framework makes IPC fairly easy to handle, and is something you will use generally, regardless of actually using multiple processes. I think the main cost of having multiple processes to the application is the access to shared resources, or the sending of those resources between processes, excluding the additional resources required for forking a process from the Zygote. I wonder whether using multiple processes will actually force you to implement your application differently?

I think that conceptually the use of multiple processes will not increase ease of implementation?

To summarize the pros of multiple processes:

• Isolation potentially gives more lifetime protection.
• Compartmentalization gives the device more manoeuvrability in regaining resources.
• Parallelization performance boost?

Cons:

• A new process must be forked from the Zygote using resources
• Within an application resources will need to be shared over multiple processes, which strain both the device and the perhaps application performance.

The main use case I can think of:

• Use a foreground activity for any user interactions and run a continuously used bound Service to do useful synchronization that might outlive the session that the user has with your activity and/or application.

If you have any remarks on my understanding please state so (Note several question marks in my explanation). If you have any pros and/or cons to add please reply as well, I will add them to the list.

Answer 1

Using multiple processes to allow the multiple cores of your device to work in parallel is not necessary since Threads can be run in parallel as well, maybe even your main thread?

Live (non-blocked) threads will be run in parallel across multiple cores automatically.

But perhaps it will be easier to actually achieve?

I would consider threads easier than processes, but "easier" is generally an opinion.

For instance a background download Service could be kept alive (level 3 in importance), while the process with the initial Activity that started this Service, now in the background (level 4) could be freed for its resources.

Except that you wasted more resources by having the two processes in the first place, and keeping a service running for long periods of time is generally an anti-pattern.

The Binder framework makes IPC fairly easy to handle, and is something you will use generally, regardless of actually using multiple processes

Developers do not normally use Binder directly. Only those implementing bound services need it, and that is a fairly small percentage of Android apps.

I wonder whether using multiple processes will actually force you to implement your application differently?

Yes.

Isolation potentially gives more lifetime protection

IMHO, this is not a valid excuse for wasting RAM, CPU, and battery on multiple processes.

Parallelization performance boost?

Threads cover this.

The main use case I can think of

While there may be scenarios in which your use case actually is a net benefit to the user, it is far from certain. Given that you have to implement your app differently to handle multiple processes, using multiple processes is a last resort approach, not the sort of thing that you do routinely, IMHO.