在同一进程中使用 Content Provider 的缺点是啥

Posted 2023-02-16

【中文标题】在同一进程中使用 Content Provider 的缺点是啥

【英文标题】：What is the downside if using ContentProvider within the same process在同一进程中使用 Content Provider 的缺点是什么

【发布时间】：2017-06-06 23:58:55

【问题描述】：

我想知道在同一进程中查询内容提供者是否会产生额外费用。我知道 Content Provider 正在通过 binder 处理数据，并且 binder service 和 binder client 之间的所有数据转换都将通过 binder driver 在内核空间中传递。

我怀疑当我们在同一个进程中使用内容提供者时它是否仍然使用相同的方法，因此会导致额外的开销，例如延迟、额外的计算......等等。

这是场景 - 在多进程应用程序中，您通常会要求您的存储系统使用 binder 系统在进程之间传递数据，但同时，您还需要在同一进程内传递数据。

如果您有一个多进程 android 应用程序，常见的方法是什么？目前，我知道一个第三方解决方案MMKV，但我不确定是否有官方解决方案可以避免这种开销（如果它存在的话）。

【参考方案1】：

我想知道在同一进程中查询内容提供者是否会产生额外费用

与简单地在对象上调用方法相比，使用ContentProvider 肯定会产生开销。进程间通信（IPC）不是免费的。这也是存储访问框架性能受到投诉的原因之一，该框架严重依赖ContentProvider。

ContentProvider 与消费者在同一进程中这一事实不应消除此开销。

【讨论】：

“这是对严重依赖于 ContentProvider 的存储访问框架性能的抱怨的原因之一。” - 好吧，不，这与 IPC 几乎没有任何关系，更多的是通过 Android 的FUSE 层，它提供虚拟文件系统访问您在 SELinux 级别上无法访问的文件（如在每个现代版本的 Android 中，每个应用程序确实在存储层中彼此完全独立地进行沙盒处理）。

非常感谢您回答我的问题。你能提供一些解决这个开销的解决方案吗？ （我也更新了问题描述，谢谢！）

@ianhanniballake：“这与 IPC 几乎没有任何关系，更多的是与通过 Android 的 FUSE 层有关”——FWIW，我不是指通过文件系统 API 访问内容。我指的是所有涉及ContentResolver 和DocumentsContract 的操作，您需要使用它们来使用存储访问框架。

@shanwu：你原来的问题是关于一个进程的，现在你编辑的问题是关于多个进程的。与进程内的通信相比，多个进程之间的通信将涉及额外的开销。要消除开销，您需要消除多个进程。否则，请少关注开销，多关注哪种 IPC 形式最适合您需要执行的通信类型（AIDL？ContentProvider？广播？共享内存？）。

@shanwu：一旦你选择了那个，然后试着设计你的 API 来最小化你需要执行的 IPC 操作的数量。这可能需要对您设计该 API 的方式进行一些更改。例如，Google 的DocumentFile 试图围绕存储访问框架提供类似于File 的API。这是一个崇高的目标。但是，这意味着基本操作（例如获取树中所有文档的名称）可以轻松进行成百上千的 IPC 调用，而不仅仅是一个。