如何以及何时使用通过AcquisitionUnstableContentProviderClient获得的ContentProviderClient? [英] How and when to use a ContentProviderClient obtained using acquireUnstableContentProviderClient?

问题描述

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

How is using a ContentProviderClient obtained with ContentResolver#acquireContentProviderClient(...) any different from ContentResolver#acquireUnstableContentProviderClient(...)?

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

It seems like I would write the same code regardless of which method I used. Is there going to be some kind of leak in my app if the ContentProvider acquired goes away and I used the non-unstable method to acquire the client?

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

So I guess that if the ContentProvider you want to use is running in the same process or if it is running in system_server then you can go ahead and acquire the client using the stable method, otherwise you should use the unstable method in case the other process crashes or the app hosting the ContentProvider is uninstalled/reinstalled while you are using it. But that leads me to ask is there some kind of advantage to using the stable version of the acquire method, why not just always use the unstable version of the method just in case?

当他们说以下话时，它们又是什么意思?

Also what exactly do they mean when they say the following?

这将关闭平台清理过程中的机制如果内容提供商的流程取决于该内容提供商消失.

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.

推荐答案

如果您使用 acquireContentProviderClient ，则如果内容提供者死亡，您的进程将被终止.

If you use acquireContentProviderClient then your process will be killed if the Content provider dies.

如果您使用 acquireUnstableContentProviderClient ，那么如果内容提供者去世，您的进程将不会被杀死-相反，您将得到一个 DeadObjectException -您需要在代码中进行处理.

If you use acquireUnstableContentProviderClient then your process will not be killed if the content provider dies - instead you will get a DeadObjectException - which you need to handle in your code.

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

You would need to write extra code with the unstable version to deal with recovery when you get a DeadObjectException. You can see default android implementation of query method in ContentResolver.java

据我了解，使用不稳定版本不会导致应用程序泄漏.

As far as I understood there would be no leak in your application caused by use of the unstable version.

关于为什么不选择始终使用不稳定版本的原因-我认为反之亦然.很少有应用程序需要处理内容提供​​商崩溃并从中恢复.最简单的方法是让您的应用程序终止并重新启动.内容提供器崩溃应该是极为罕见的-内存损坏，磁盘损坏等.除非您有自己的提供程序，由于某些特定/奇怪的原因，该提供程序可能会崩溃，否则您将不需要使用不稳定的版本.

As to why not chose to use the unstable version always - I believe its the other way round. Very few applications would need to handle and recover from a content provider crash. The easiest approach is to let your application die and restart. A content provider crash is supposed to be extremely rare - memory corruption , disk corruption etc . Unless you have your own provider which is expected to crash for some specific/weird reason you would not need to use the unstable version.

这将关闭平台清理过程中的机制如果内容提供商的流程取决于该内容提供商消失.

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.

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

This is the platform logic to kill all processes that use the content provider. This means your application will not be killed if you use the unstable version

这篇关于如何以及何时使用通过AcquisitionUnstableContentProviderClient获得的ContentProviderClient?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！