“内容提供者”和“SQLite数据库”之间的确切区别
我已经完成了Android的SQLite数据库编程，但是我不知道Content-Provider的任何内容，除了这个：“正如我已经提到的Android开发者页面 ，Android SDK解释关于”内容提供者“，因为它用于存储和检索数据。
但是之后，
- “内容提供者”和“SQLite数据库”之间的确切区别是什么？
- 什么时候最好存储数据？
任何例子或帮助！
我发现一个主要区别如下：
将数据存储在数据库中是保存数据的一种好方法 ，但是在Android中创build的数据库只有创build它们的应用程序才能看到。 也就是说，一个应用程序在Android上创build的SQLite数据库只能被该应用程序使用，而不能被其他应用程序使用。
因此，如果您need to share data between applications, you need to use the content provider model as recommended in Android. 本文将介绍内容提供者的基本知识以及如何实现内容提供者。
我在这个链接find这篇文章
真的很好提供的信息。
“内容提供者”和“SQLite数据库”之间的确切区别是什么？
ContentProvider是一个外观 – 一个可以将数据库公开给其他进程的API。 它可以以数据存储在SQLite数据库中的方式实现，但不一定是。
什么时候最好存储数据？
这是不可能的。 一般来说，除非需要使用ContentProvider ，否则只需使用数据库即可。
我已经用数以千计的用户使用它们简单地使用SQLite方法做了很多好的应用程序。 但是那是前一阵子，我不得不手动编写很多代码，现在很容易被ContentProvider处理。 那时候我并不赞成使用内容提供者，因为它似乎只增加了代码的复杂性。
然而在过去的几年里，随着Android的发展，我已经转移到了ContentProvider，因为它节省了时间，并允许您做更多。 我现在广泛使用它。 一旦你写了一个Content Provider类，你的生活就变得容易了。 有了ContentProvider，我可以轻松地处理光标加载器，加载器callback和批量插入，我不得不手动编写所有的东西，而且效率不高。 特别是在更新列表视图时，由于只有一个notifychange（）方法，现在自动更新列表视图。 这意味着现在我不必键入我自己的侦听器，并手动更新列表视图和适配器中的内容。 另外，我不需要担心数据库的打开和closures，或者担心内存泄漏。 这一切都由内容提供商处理。 我偶尔遇到的唯一问题就是你无法在ContentProviders中做一些复杂的查询。 在这种情况下，您仍然可以使用原始查询并使用与sqlite的旧式手动交互。
如果您之前已经编写了自己的DbAdapter，Helper和Observer，那么您可以安全地将它们带到新的应用程序，而无需花费时间将所有内容转换为ContentProvider。 但基于我的经验，我强烈build议转移到ContentProvider。 要习惯它需要一些时间，但一旦你有了它的经验，你会留下来。
更新2017我现在已经切换到Realm ，在任何平台上使用数据库的好方法。 花几个小时学习它，并在您的应用程序开发生涯中保存无数个小时。
1.内容提供者不是线程安全的
默认情况下内容提供者不是线程安全的。 如果您有多个使用内容提供程序的线程，则可以看到抛出许多不同的exception以及其他数据不一致。 解决这个问题的最简单方法是在内容提供者公开的每个公共方法上使用synchronized关键字。
这样，一次只能有一个线程访问这些方法。
2.做大量的写作时玩得很好
我需要在新的Serval Maps应用程序中将数据从二进制文件导入到应用程序内部使用的数据库中。 为了做到这一点，并与其他应用程序打好，最好是：
产生一个新的线程来进行导入，使其他线程不会受到负面影响，特别是负责更新UI的线程; 并在每次导入结束时暂停一下，以使其他线程需要使用更多同步方法的机会。
3.内容提供者有时会迫使你侧重思考
Android内容提供者的工作方式是在代码的其余部分和底层数据库之间提供一个抽象层。 这主要是因为，据我所知，内容提供者可以从数据库以外的地方访问数据。
这意味着您不能在底层数据库上执行原始SQL查询，并且需要使用传递给各种方法（如查询方法）的variables来指定SQL查询的各个组件。 如果您的任务不符合内容提供者处理SQL的方式，那么您有两个select：
从侧面考虑查询，也许可以通过备选查询获取所需的数据，并从游标访问结果; 以及使用URI来正常访问数据，并使用与特定查询相匹配的特殊URI来处理那些没有替代方法的任务。
内容提供者被用来当你想跨应用程序共享你的数据。
如果您的数据库附带了应用程序，并且您希望另一个应用程序使用某些数据，则可以实现公开数据的内容提供程序
考虑先进的内容pipe理系统。 每个对象（页面，图像，新闻文章，事件项目等）都有一个内容，一个地址，用户权限以及与系统不同部分交互的方式。 内容提供商为Android做到这一点。 您现在可以共享您的应用程序中可能存储的文件或图像。 您还可以创build自定义可共享的对象，如商务联系人，可编辑笔记等。并指定安全性和默认应用程序来处理这样的对象，当你从任何其他应用程序打开它们。
主要区别在于：当您的应用程序需要将信息共享到其他应用程序时，请使用Content-Provider。 SQLite只为创build它的应用程序存储数据
我在阅读这个答案的同时也寻找同样的疑问，所以想到分享它。 它指出 –
为您的数据提供额外的抽象级别以便更容易地在内部进行更改是一种很好的做法。 如果您决定稍后更改基础数据库结构呢？ 如果使用ContentProvider，则可以包含其中的所有结构更改，就像不使用ContentProvider一样，您将被迫更改受结构更改影响的代码的所有区域。 此外，能够重复使用相同的标准API来访问数据，而不是通过对数据库的低级访问来乱抛垃圾的代码是很好的。
所以，使用内容提供商将是一个好主意。
一个区别是内容提供者对内容观察者有平台支持。 你将需要为SQLite数据库实现自己的Observable模式。
如何使用LoaderManager自动重新查询
ContentObserver for SQLite？
