是DB活动体系结构和/或上下文泄漏的ContentProvider解决方案吗？

Question

当使用大型数据库时，在我的例子中大约有20个DataSource定义(每个DS有2-5个表，存储在同一个SQLiteDatabase中)，很少会出现问题。

例如：

• 线程同步(ReentrantLock，同步锁)
• 用于1子类的Singleton (1，2)模式
• 针对SQLiteOpenHelper和/或DataSources 的单例可能的DataSources
  • 如果使用应用程序的上下文(Context.getApplicationContext())，则使用大内存堆

​

尽管我知道，当不向其他服务/应用程序(1、2)公开应用程序的数据时，不必使用1，我认为它解决了上述大多数问题，并允许/推送实现有趣的特性，如广播或使用游标访问数据。

这仅仅是对ContentProvider模式的误解，还是真的很复杂地解决了可能的问题，而不仅仅是提到的问题？

Answer 1

ContentProvider实现可以编写大量的样板代码，这就是我开发机器DB的原因。如果您计划实现一个由sqlite支持的内容提供商，它可能会使您的生活变得更容易。

http://robotoworks.com/mechanoid-plugin/mechanoid-db/

http://robotoworks.com/2013/01/using-sqlite-in-android-with-mechanoid-db-part-1-tables/

Answer 2

考虑到startmanagingcursor的最近遭到反对，以及您可以从文档以及几本书(包括reto meyer's one)中读到的内容，contentprovider似乎是克服一系列问题的建议方法，包括您正在列出的问题。

即使正式文件声明如果不打算与其他应用程序共享数据，也不需要开发自己的提供程序，但显然基于加载器的方法是强有力的宣传，可以减轻您对刚才提到的问题的担忧，更不要说加载程序可以在数据更改时自动得到通知。

请注意，您可以将内容提供者隐藏到外部世界，并添加

android:exported="false"

线程同步在任何情况下都不应该担心，因为sqllite调用是线程安全的(据我所记得)。

我也同意，编写内容提供者包含大量样板代码，这就是为什么我编写了一个脚本来为我编写该代码:-)。如果您感兴趣，您可以检查它的这里，但也考虑到，寻找“内容提供商生成器”谷歌将返回一些体面的，如果不是更好的选择。