android使用一种称为contentprovider的概念来将数据抽象为服务。

    这种内容提供给程序的理念看起来像是启用了REST的数据提供程序。REST(REpresentational State Transfer具象状态传输)，它是一种设计风格，通常基于使用HTTP,URI和XML以及HTML这些现有的广泛流行的协议和标准。资源由URI指定，对资源的操作包括获取，创建，修改和删除资源；这些操作正好对应HTTP协议提供的GET,POST和DELETE方法。

    要从ContentProvider检索数据或将数据保存到Contentprovider，需要使用一组类似REST的URI。

例如，如果要从封装 图书数据库 的contentprovider获取一组图书，需要使用类似以下形式的URI：

content://com.android.book.BookProvider/books

要从 图书数据库 获得指定图书（如23号图书），需要使用类似以下形似的URI：

content://com.android.book.BookProvider/books/23

    设备上的任何应用程序都可以利用这些URI来访问或操作数据。所以，在应用程序之间的数据共享上，ContentProvider扮演着重要角色。

    只有在希望与外部或在应用程序之间 共享数据时，才需要使用contentprovider.

    对于内部数据访问，应用程序可以使用它认为适合的任何数据存储/访问机制，例如：

        首选项，一组键/值对，可以用来存储应用程序首选项。

        文件，应用程序内部的文件，可以存储在可移动存储媒体上。

        SQLite，SQLite数据库，每个SQL数据库对于创建它的包是私有的。

        网络，一种机制，支持通过互联网获取或存储外部的数据。

    Android中内置的contentprovider，记录在android.provider Java包中。可在官网查看这些contentprovider的列表，链接为。这些sqlite数据库通常具有扩展名.db，仅能从实现包访问。任何来自该包外部的访问都需要通过contentprovider接口。

总体而言， contentprovider方法类似于以下业内抽象机制：（网站，REST，web服务, 存储过程？？）

与网站一样，设备上每个contentprovider都会使用字符串注册自身，这个字符串类似于 域名，但称为授权（authority）。

授权就像contentprovider的域名。在进行授权注册之后，这些contentprovider就拥有一个基础域名，这个基础域名是一个起始URL。

在androidManifest.xml中注册授权：

获得了由授权开头的URL：

content://com.your-company.SomeProvider/

注意：android提供的contentprovider可能没有完全限定的授权名，只有在使用第三方contentprovider时才建议使用完全限定的授权名（如：comgoogle.android.comtacts）。

contentprovider还提供了一种类似REST的URL来获取或操作数据。对于前面的注册，标识NotePadProvider数据库中的笔记目录或集合的URI为：

content：//com.google.provider.Notepad/Notes

标识具体笔记的URI为：

content://com.google.provider.notepd/Notes/#

一些非第三方提供程序，由android控制的，非完全限定的结构：

content://media/internal/imaescontent://media/external/images content://contacts/people content://contacts/people/23

ContenProvider具有web服务的特征。ContenProvider通过其URI将内部数据公开为服务。但是，contentprovider的URL的输出不是具有特定类型的数据，这与基于SOAP的web服务一样。此输出更像来自JDBC语句的结果集。尽管contentprovider在概念上与JDBC相似，但此输出与ResultSet不完全相同。

调用方希望知道返回的行和列的结构。contentprovider提供了一种内置机制，来确定此URI所表示的数据的MIME