如何使用与ContentProviderClient获得ContentResolver#acquireContentProviderClient(...)的{{1}}与ContentResolver#acquireUnstableContentProviderClient(...)有什么不同？
无论我使用哪种方法，似乎都会编写相同的代码。如果获取的ContentProvider消失并且我使用非不稳定的方法来获取客户端，我的应用程序中是否会出现某种泄漏？
所以我想如果您要使用的ContentProvider在同一个进程中运行，或者它在system_server中运行，那么您可以继续使用stable方法获取客户端，否则您应该使用不安全的方法，以防其他进程崩溃或在您使用它时卸载/重新安装托管ContentProvider的应用程序。但这导致我要问使用稳定版本的获取方法是否有某种优势，为什么不总是使用方法的不稳定版本以防万一呢？
当他们说出以下内容时，他们究竟是什么意思？
这关闭了平台清理过程中的机制 如果该内容提供商处理，则依赖于内容提供商 走了。
答案 0 :(得分：4)
如果您使用acquireContentProviderClient，那么如果内容提供商死亡，您的流程将被终止。
如果您使用acquireUnstableContentProviderClient，那么如果内容提供商死亡，您的流程就不会被杀死 - 相反，您将获得DeadObjectException - 您需要在代码中处理。
当您获得DeadObjectException时，您需要使用不稳定版本编写额外代码来处理恢复。您可以在query
ContentResolver.java方法的默认android实现
据我所知，使用不稳定版本会导致应用程序无泄漏。
至于为什么不总是选择使用不稳定的版本 - 我相信它反过来。很少有应用程序需要处理内容提供程序崩溃并从中恢复。最简单的方法是让你的应用程序死掉并重新启动。内容提供商崩溃应该是非常罕见的 - 内存损坏，磁盘损坏等。除非您有自己的提供程序，由于某些特定/奇怪的原因预计会崩溃，否则您将不需要使用不稳定版本。
这关闭了平台清理过程中的机制 如果该内容提供商的进程依赖于内容提供商 走了。
这是杀死使用内容提供程序的所有进程的平台逻辑。这意味着如果您使用不稳定版本
，您的应用程序将不会被杀死