是ContentProvider解决方案的DB-Activity架构和/或上下文泄漏

Question

当使用大型数据库时，在我的情况下，大约有20个数据源定义(每个DS 2-5个表，存储在同一个sqliteddatabase中)，很少出现问题

例如:

• 线程同步(ReentrantLock，同步锁)
• SQLiteOpenHelper子类的单例模式
• SQLiteOpenHelper和/或数据源的单例可能的上下文泄漏
  • 或大内存堆如果使用应用程序的上下文(Context.getApplicationContext())

尽管我知道，当不将应用程序的数据暴露给其他服务/应用程序(1,2)时，使用ContentProviders是不必要的，我认为它解决了上面提到的大多数问题，并允许/推送实现有趣的功能，如广播或使用游标来访问数据。

这只是对ContentProvider模式的误解，还是它真的是可能的复杂解决方案，而不仅仅是提到的问题?

Answer 1

ContentProvider实现可以编写很多样板代码，这就是我开发Mechanoid 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的一本书)中读取的内容，contentprovider似乎是克服一堆问题的建议方法，包括您列出的问题。

即使官方文档声明如果您不打算与其他应用程序共享您的数据，则不需要开发自己的提供者，但似乎很明显，基于加载器的方法得到了大力宣传，并且使您不必担心刚才提到的问题，更不用说加载器可以在数据更改时自动通知。

另请注意，您可以向外部隐藏您的内容提供程序，添加

android:exported="false"

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

我也同意写一个内容提供程序包括很多样板代码，这就是为什么我写了一个脚本来为我写:-)。如果你感兴趣，你可以在这里检查，但也要考虑在谷歌上寻找"内容提供商生成器"将返回一些体面的，如果不是更好的选择。