使用ContentProviderClient VS ContentResolver的访问内容提供商 [英] using ContentProviderClient vs ContentResolver to access content provider
问题描述
在Android上的内容提供商的文档描述了使用 ContentResolver的，从 getContentResolver获得（），访问内容。
The documentation on Android content providers describes using a ContentResolver, obtained from getContentResolver(), to access the content.
不过也有一个 ContentProviderClient ，它可以从 getContentResolver（）。acquireContentProviderClient（机构）获得。它似乎提供或多或少的相同方法在 ContentResolver的用于从提供者访问内容。
However there is also a ContentProviderClient, which can be obtained from getContentResolver().acquireContentProviderClient(authority). It seems to provide more or less the same methods available in the ContentResolver for accessing content from the provider.
当我应该用 ContentProviderClient 的而不是仅仅使用 ContentResolver的直接？有什么好处？
When should I use a ContentProviderClient instead of just using the ContentResolver directly? What are the benefits?
推荐答案
您的Android设备有多个数据库，每个由唯一的内容授权标识。这是域名相当于部分内容：// URI - 第一个斜线之前的一切
Your android device has many databases, each of which is identified by a unique Content Authority. This is the "domain name" equivalent part in the content:// uri -- everything before the first slash.
ContentResolver的将数据存储提供了一个映射，从字符串contentAuthority 到的ContentProvider 。当你调用 ContentResolver.query（）或更新（）或你有什么话，该URI被解析分离成其元件，contentAuthority串被识别，并ContentResolver的必须搜索该地图为匹配的字符串，而直接将查询到合适的供应商。发生的每一个呼叫期间，这些昂贵的搜索，因为URI可能会有所不同，从电话呼叫，使用不同的contentAuthority为好。此外，可能会有一些成本参与建立和拆除该特定供应商的连接 - 它不能在调用重用。我不知道有参与的开销，这是一些pretty的深OS级别code。
ContentResolver stores data providing a mapping from String contentAuthority to ContentProvider. When you call ContentResolver.query() or update() or what have you, the URI is parsed apart into its components, the contentAuthority string is identified, and contentResolver has to search that map for a matching string, and direct the query to the right provider. This expensive search occurs during every single call, because the URI might be different from call to call, with a different contentAuthority as well. Additionally, there may be some costs involved in setting up and tearing down a connection to that specific provider -- It can't be reused across calls. I'm not sure of the overhead involved there, that's some pretty deep OS level code.
相反，当你调用 acquireContentProviderClient（权威），说：什么提供商，我需要？查找完成一次，您将得到一个 ContentProviderClient 基本上是一个直接链接到的ContentProvider 。 （有一点你和涉及跨线程通信和并发锁定的供应商之间的胶）。但是，当您使用 ContentProviderClient ，你将直接与提供者为您所要求的权限。这消除了浪费不断地重新计算，它提供我想要什么？
By contrast, when you call acquireContentProviderClient(authority), that "what-provider do I need?" lookup is done once, and you are given a ContentProviderClient which is essentially a direct link to the ContentProvider. (There's a bit of glue between you and the provider that involves cross-thread communication and concurrency locking). However, when you use ContentProviderClient, you will talk directly to the Provider for the authority you requested. This removes the waste of constantly re-computing "which provider do I want?"
注意：每<一href="http://developer.android.com/reference/android/content/ContentResolver.html#acquireContentProviderClient%28android.net.Uri%29">acquireContentProviderClient()文档：如果你获得ContentProviderClient，调用方必须表明通过调用<一个，他们正在与供应商进行href="http://developer.android.com/reference/android/content/ContentProviderClient.html#release%28%29">ContentProviderClient.release()这将允许系统释放提供它它确定没有其他原因使其保持活跃。的所以基本上，留下一个陈旧的客户端开放将迫使供应商保持运行在后台的服务。所以，请记住，清理！
NOTE: Per acquireContentProviderClient() documentation: If you obtain a ContentProviderClient, "The caller must indicate that they are done with the provider by calling ContentProviderClient.release() which will allow the system to release the provider it it determines that there is no other reason for keeping it active." So essentially, leaving a stale Client open will force the Provider to keep running as a service in the background. So, remember to clean up!
摘要：
多次调用不同contentAuthorities：使用 ContentResolver的
重复调用同一个机构：获取并使用 ContentProviderClient 。记住要释放（）它时，你就大功告成了。
Repeated calls to the same Authority: Obtain and use ContentProviderClient. Remember to release() it when you're done.
这篇关于使用ContentProviderClient VS ContentResolver的访问内容提供商的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
