3

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).

shanwu
  • 1,493
  • 6
  • 35
  • 45

1 Answers1

2

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.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • "This is one of the reasons for the complaints about performance of the Storage Access Framework, which relies heavily on ContentProvider." - well, no, that has barely anything to do with IPC and much more to do with going through Android's [FUSE](https://en.wikipedia.org/wiki/Filesystem_in_Userspace) layer, which provides the virtual file system access to files you wouldn't otherwise have access to at the SELinux level (as every app is indeed sandboxed entirely separately from one another at the storage layer in ~every modern version of Android). – ianhanniballake Mar 04 '22 at 02:47
  • Thank you very much for answering my question. Could you provide some solution which solves this overhead? (I also updated the question description, thanks!) – shanwu Mar 04 '22 at 02:53
  • @ianhanniballake: "that has barely anything to do with IPC and much more to do with going through Android's FUSE layer" -- FWIW, I was not referring to accessing content via filesystem APIs. I was referring to all the operations involving `ContentResolver` and `DocumentsContract` that you need to use to consume the Storage Access Framework. – CommonsWare Mar 04 '22 at 11:52
  • @shanwu: Your original question was about one process, and now your edited question is about multiple processes. Communications between multiple processes will involve additional overhead when compared with communication within a process. To eliminate the overhead, you need to eliminate the multiple processes. Otherwise, focus less on the overhead and more on what form of IPC is best for the type of communication that you need to do (AIDL? `ContentProvider`? broadcasts? shared memory?). – CommonsWare Mar 04 '22 at 11:55
  • @shanwu: Once you choose that, then try to design your API to minimize the number of IPC operations that you need to perform. That may require some changes to how you might design that API. For example, Google's `DocumentFile` tries to provide an API around the Storage Access Framework that resembles `File`. This is a noble goal. However, it means that basic operations, like getting the names of all the documents in a tree, can easily take hundreds or thousands of IPC calls, rather than just one. – CommonsWare Mar 04 '22 at 11:58
  • @CommonsWare Yes, 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. It will be really nice of u to update your answer, so your answer will help more people with the same question, thank you very much! – shanwu Mar 04 '22 at 16:09