android - 如何以及何时使用通过 acquireUnstableContentProviderClient 获得的 ContentProviderClient？

Question

使用通过 ContentResolver#acquireContentProviderClient(...) 获得的 ContentProviderClient 与 ContentResolver#acquireUnstableContentProviderClient(...) 有何不同？

似乎无论使用哪种方法，我都会编写相同的代码。如果获取的 ContentProvider 消失并且我使用非不稳定方法获取客户端，我的应用程序是否会出现某种泄漏？

所以我猜想如果您要使用的 ContentProvider 正在同一进程中运行，或者如果它正在 system_server 中运行，那么您可以继续使用稳定方法获取客户端，否则您应该使用不稳定的方法，以防其他进程崩溃或托管 ContentProvider 的应用程序在您使用它时被卸载/重新安装。但这让我想问，使用稳定版本的 acquire 方法是否有某种优势，为什么不总是使用该方法的不稳定版本以防万一？

另外，当他们说以下内容时，他们到底是什么意思？

This turns off the mechanism in the platform clean up processes that are dependent on a content provider if that content provider's process goes away.

Answer 1

如果您使用 acquireContentProviderClient，那么您的进程将在 Content provider 终止时终止。

如果您使用 acquireUnstableContentProviderClient，那么您的进程不会在内容提供者死亡时终止 - 相反您会得到一个 DeadObjectException - 您需要在您的代码中进行处理。

当您遇到 DeadObjectException 时，您需要使用不稳定版本编写额外的代码来处理恢复。您可以在 ContentResolver.java

中看到 query 方法的默认 android 实现

据我所知，您的应用程序不会因使用不稳定版本而导致泄漏。

至于为什么不选择始终使用不稳定版本 - 我认为恰恰相反。很少有应用程序需要处理内容提供​​商崩溃并从中恢复。最简单的方法是让您的应用程序死掉并重新启动。内容提供商崩溃应该是极其罕见的——内存损坏、磁盘损坏等。除非您有自己的提供商，但由于某些特定/奇怪的原因预计会崩溃，否则您不需要使用不稳定版本。

This turns off the mechanism in the platform clean up processes that are dependent on a content provider if that content provider's process goes away.

这是杀死所有使用内容提供者的进程的平台逻辑。这意味着如果您使用不稳定版本，您的应用程序将不会被杀死