What is the downside if using ContentProvider within the same process

Issue

I am wondering if there'll be an extra cost to query the content provider within the same process. I'm aware that the Content Provider is transacting data by the binder, and all the data transition between binder service and binder client will be passing by binder driver in kernel space.

I suspect if it still uses the same approach while we use the content provider in the same process and therefore causes extra overhead such as latency, extra computing...etc.

Here's the scenario - in the multi-process app, you will normally require your storage system to use the binder system to pass data between processes, but at the same time, you will also need to pass data within the same process.

What's the common approach if you have a multiprocess android app? For now, I know a third-party solution MMKV but I am not sure if there's an official solution to avoid this kind of overhead (if it even exists).

Solution

I am wondering if there'll be extra cost to query content provider within the same process

There definitely will be overhead incurred by using ContentProvider, compared with simply calling methods on an object. Inter-process communication (IPC) is not free. This is one of the reasons for the complaints about performance of the Storage Access Framework, which relies heavily on ContentProvider.

The fact that the ContentProvider is in the same process as the consumer should not eliminate this overhead.

Answered By - CommonsWare