勞力越帶，責任越大

前言

作為 Android 的四大組件之一，ContentProvider 可以說是無處不在了。
但是對于我而言，開發(fā)過程中看似 ContentProvider 用得很嫻熟，卻一直沒能形成一個完整的體系。
也許大家也有著和我類似的煩惱，于是我特地花了幾天的時間，總結(jié)了我所知道的知識點，以及面試中可能遇到的問題。將本文分享給大家，希望能幫助大家重新梳理下我們的這個老朋友 ContentProvider 。

希望大家閱讀愉快！

文章目錄

ContentProvider 應用程序間非常通用的共享數(shù)據(jù)的一種方式，也是 Android 官方推薦的方式。
Android 中許多系統(tǒng)應用都使用該方式實現(xiàn)數(shù)據(jù)共享，比如通訊錄、短信等。

ContentProvider

方便大家學習，我在 GitHub 上建立個倉庫

倉庫內(nèi)容與博客同步更新。由于我在 稀土掘金 簡書 CSDN 博客園 等站點，都有新內(nèi)容發(fā)布。所以大家可以直接關注該倉庫，以免錯過精彩內(nèi)容！
倉庫地址：
超級干貨！精心歸納 Android 、JVM 、算法等，各位帥氣的老鐵支持一下！給個 Star ！

1.1 Android 為什么要設計 ContentProvider 這個組件？

為什么要設計 ContentProvider

很多做 Android 開發(fā)的人都不怎么使用它，覺得直接讀取數(shù)據(jù)庫會更簡單方便。
那么 Android 搞一個內(nèi)容提供者在數(shù)據(jù)和應用之間，只是為了裝高大上，故弄玄虛？我認為其設計用意在于：

封裝。對數(shù)據(jù)進行封裝，提供統(tǒng)一的接口，使用者完全不必關心這些數(shù)據(jù)是在 DB ，XML 、Preferences 或者網(wǎng)絡請求來的。當項目需求要改變數(shù)據(jù)來源時，使用我們的地方完全不需要修改。
提供一種跨進程數(shù)據(jù)共享的方式。
應用程序間的數(shù)據(jù)共享還有另外的一個重要話題，就是數(shù)據(jù)更新通知機制了。因為數(shù)據(jù)是在多個應用程序中共享的，當其中一個應用程序改變了這些共享數(shù)據(jù)的時候，它有責任通知其它應用程序，讓它們知道共享數(shù)據(jù)被修改了，這樣它們就可以作相應的處理。

1.2 如何訪問自定義 ContentProvider

如何訪問自定義 ContentProvider

ContentResolver 接口的 notifyChange 函數(shù)來通知那些注冊了監(jiān)控特定 URI的ContentObserver 對象，使得它們可以相應地執(zhí)行一些處理。
ContentObserver 可以通過 registerContentObserver 進行注冊。
通過 ContentProvider 的 Uri 訪問開放的數(shù)據(jù)。

ContenResolver 對象通過 Context 提供的方法 getContenResolver() 來獲得。
ContenResolver 提供了以下方法來操作：insert delete update query 這些方法分別會調(diào)用 ContenProvider 中與之對應的方法并得到返回的結(jié)果。

1.3 通過 ContentResolver 獲取 ContentProvider 內(nèi)容的基本步驟

ContentResolver 獲取 ContentProvider 內(nèi)容的基本步驟

得到 ContentResolver 類對象：ContentResolver cr = getContentResolver ( )。
定義要查詢的字段 String 數(shù)組。
使用 cr.query() ; 返回一個 Cursor 對象。
使用 while 循環(huán)得到 Cursor 里面的內(nèi)容。

1.4 ContentProvider 是如何實現(xiàn)數(shù)據(jù)共享的：

ContentProvider 是如何實現(xiàn)數(shù)據(jù)共享的

在 Android 中如果想將自己應用的數(shù)據(jù) ( 一般多為數(shù)據(jù)庫中的數(shù)據(jù) ) 提供給第三發(fā)應用, 那么我們只能通過 ContentProvider 來實現(xiàn)了。 ContentProvider 是應用程序之間共享數(shù)據(jù)的接口。
使用的時候首先自定義一個類繼承 ContentProvider , 然后覆寫 query 、insert 、update 、delete 等方法。
因為其是四大組件之一因此必須在 AndroidManifest 文件中進行注冊。
把自己的數(shù)據(jù)通過 uri 的形式共享出去 android 系統(tǒng)下不同程序數(shù)據(jù)默認是不能共享訪問需要去實現(xiàn)一個類去繼承 ContentProvider。

public class PersonContentProvider extends ContentProvider{

   public boolean onCreate(){ }
   query(Url, String[], String, String[], String);
   insert(Uri,ContentValues);
   update(Uri,ContentValues,String[]);
   delete(Uri,String,String[]);
   
}

1.5 為什么要用 ContentProvider ?它和 sql 的實現(xiàn)上有什么差別?

為什么要用 ContentProvider ?它和 sql 的實現(xiàn)上有什么差別

ContentProvider 屏蔽了數(shù)據(jù)存儲的細節(jié) , 內(nèi)部實現(xiàn)對用戶完全透明 , 用戶只需要關心操作數(shù)據(jù)的 uri 就可以了, ContentProvider 可以實現(xiàn)不同 app之間共享。
Sql 也有增刪改查的方法, 但是 sql 只能查詢本應用下的數(shù)據(jù)庫。
而 ContentProvider 還可以去增刪改查本地文件. xml 文件的讀取等。

1.6 Uri 介紹

Uri 介紹

為系統(tǒng)的每一個資源給其一個名字，比方說通話記錄。

每一個 ContentProvider 都擁有一個公共的 URI ，這個 URI 用于表示這個 ContentProvider 所提供的數(shù)據(jù)。
Android 所提供的 ContentProvider 都存放在 android.provider 包中。

將其分為 A，B，C，D 4個部分：
A：標準前綴，用來說明一個 Content Provider 控制這些數(shù)據(jù)，無法改變的；"content://"；
B：URI 的標識，用于唯一標識這個 ContentProvider ，外部調(diào)用者可以根據(jù)這個標識來找到它。它定義了是哪個 ContentProvider 提供這些數(shù)據(jù)。對于第三方應用程序，為了保證 URI 標識的唯一性，它必須是一個完整的、小寫的類名。這個標識在元素的 authorities 屬性中說明：一般是定義該 ContentProvider 的包類的名稱；
C：路徑（ path ），通俗的講就是你要操作的數(shù)據(jù)庫中表的名字，或者你也可以自己定義，記得在使用的時候保持一致就可以了；"content://com.bing.provider.myprovider/tablename"。
D：如果URI中包含表示需要獲取的記錄的 ID；則就返回該id對應的數(shù)據(jù)，如果沒有 ID，就表示返回全部； "content://com.bing.provider.myprovider/tablename/#" # 表示數(shù)據(jù) id 。

1.7 如何訪問 asserts 資源目錄下的數(shù)據(jù)庫?

訪問 asserts 資源目錄下的數(shù)據(jù)庫

把數(shù)據(jù)庫 db 復制到 /data/data/packagename/databases/ 目錄下, 然后直接就能訪問了。

1.8 多個進程同時調(diào)用一個 ContentProvider 的 query 獲取數(shù)據(jù)，ContentPrvoider 是如何反應的呢？

調(diào)用一個 ContentProvider 的 query 獲取數(shù)據(jù)，ContentPrvoider 是如何反應的

一個 ContentProvider 可以接受來自另外一個進程的數(shù)據(jù)請求。
盡管 ContentResolver 與 ContentProvider 類隱藏了實現(xiàn)細節(jié)，但是 ContentProvider 所提供的 query()，insert()，delete()，update() 都是在 ContentProvider 進程的線程池中被調(diào)用執(zhí)行的，而不是進程的主線程中。
這個線程池是有 Binder 創(chuàng)建和維護的，其實使用的就是每個應用進程中的 Binder 線程池。

1.9 Android 設計 ContentProvider 的目的是什么呢？

設計 ContentProvider 的目的

隱藏數(shù)據(jù)的實現(xiàn)方式，對外提供統(tǒng)一的數(shù)據(jù)訪問接口；
更好的數(shù)據(jù)訪問權(quán)限管理。ContentProvider 可以對開發(fā)的數(shù)據(jù)進行權(quán)限設置，不同的 URI 可以對應不同的權(quán)限，只有符合權(quán)限要求的組件才能訪問到 ContentProvider 的具體操作。
ContentProvider 封裝了跨進程共享的邏輯，我們只需要 Uri 即可訪問數(shù)據(jù)。由系統(tǒng)來管理 ContentProvider 的創(chuàng)建、生命周期及訪問的線程分配，簡化我們在應用間共享數(shù)據(jù)（進程間通信）的方式。我們只管通過 ContentResolver 訪問 ContentProvider 所提示的數(shù)據(jù)接口，而不需要擔心它所在進程是啟動還是未啟動。

1.10 運行在主線程的 ContentProvider 為什么不會影響主線程的UI操作?

ContentProvider 為什么不會影響主線程的UI操作

ContentProvider 的 onCreate() 是運行在 UI 線程的，而 query() ，insert() ，delete() ，update() 是運行在線程池中的工作線程的
所以調(diào)用這向個方法并不會阻塞 ContentProvider 所在進程的主線程，但可能會阻塞調(diào)用者所在的進程的 UI 線程！
所以，調(diào)用 ContentProvider 的操作仍然要放在子線程中去做。
雖然直接的 CRUD 的操作是在工作線程的，但系統(tǒng)會讓你的調(diào)用線程等待這個異步的操作完成，你才可以繼續(xù)線程之前的工作。

1.11 外提供數(shù)據(jù)共享，那么如何限制對方的使用呢？

如何限制對方的使用

android:exported 屬性非常重要。這個屬性用于指示該服務是否能夠被其他應用程序組件調(diào)用或跟它交互。
如果設置為 true，則能夠被調(diào)用或交互，否則不能。
設置為 false 時，只有同一個應用程序的組件或帶有相同用戶 ID 的應用程序才能啟動或綁定該服務。
對于需要開放的組件應設置合理的權(quán)限，如果只需要對同一個簽名的其它應用開放 ContentProvider ，則可以設置 signature 級別的權(quán)限。
大家可以參考一下系統(tǒng)自帶應用的代碼，自定義了 signature 級別的 permission ：

<permission android:name="com.android.gallery3d.filtershow.permission.READ"
            android:protectionLevel="signature" />

<permission android:name="com.android.gallery3d.filtershow.permission.WRITE"
            android:protectionLevel="signature" />

<provider
    android:name="com.android.gallery3d.filtershow.provider.SharedImageProvider"
    android:authorities="com.android.gallery3d.filtershow.provider.SharedImageProvider"
    android:grantUriPermissions="true"
    android:readPermission="com.android.gallery3d.filtershow.permission.READ"
    android:writePermission="com.android.gallery3d.filtershow.permission.WRITE" />

1.11.1 如果我們只需要開放部份的 `URI` 給其他的應用訪問呢？

如果我們只需要開放部份的 URI 給其他的應用訪問呢

可以參考 Provider 的 URI 權(quán)限設置，只允許訪問部份 URI ，可以參考原生 ContactsProvider2 的相關代碼（注意 path-permission 這個選項）：

<provider android:name="ContactsProvider2"
    android:authorities="contacts;com.android.contacts"
    android:label="@string/provider_label"
    android:multiprocess="false"
    android:exported="true"
    android:grantUriPermissions="true"
    android:readPermission="android.permission.READ_CONTACTS"
    android:writePermission="android.permission.WRITE_CONTACTS">
    <path-permission
            android:pathPrefix="/search_suggest_query"
            android:readPermission="android.permission.GLOBAL_SEARCH" />
    <path-permission
            android:pathPrefix="/search_suggest_shortcut"
            android:readPermission="android.permission.GLOBAL_SEARCH" />
    <path-permission
            android:pathPattern="/contacts/.*/photo"
            android:readPermission="android.permission.GLOBAL_SEARCH" />
    <grant-uri-permission android:pathPattern=".*" />
</provider>

1.12 ContentProvider 接口方法運行在哪個線程中呢？

ContentProvider 接口方法運行在哪個線程中

ContentProvider 可以在 AndroidManifest.xml 中配置一個叫做 android:multiprocess 的屬性，默認值是 false ，表示 ContentProvider 是單例的
無論哪個客戶端應用的訪問都將是同一個 ContentProvider 對象，如果設為 true ，系統(tǒng)會為每一個訪問該 ContentProvider 的進程創(chuàng)建一個實例。

1.12.1 這點還是比較好理解的，那如果我要問每個 ContentProvider 的操作是在哪個線程中運行的呢?（其實我們關心的是 UI 線程和工作線程）

每個 ContentProvider 的操作是在哪個線程中運行的

比如我們在UI線程調(diào)用getContentResolver().query查詢數(shù)據(jù)，而當數(shù)據(jù)量很大時（或者需要進行較長時間的計算）會不會阻塞UI線程呢？
要分兩種情況回答這個問題：

ContentProvider 和調(diào)用者在同一個進程，ContentProvider 的方法（ query/insert/update/delete 等）和調(diào)用者在同一線程中；
ContentProvider 和調(diào)用者在不同的進程，ContentProvider 的方法會運行在它自身所在進程的一個 Binder 線程中。
但是，注意這兩種方式在 ContentProvider 的方法沒有執(zhí)行完成前都會 blocked 調(diào)用者。所以你應該知道這個上面這個問題的答案了吧。
也可以看看 CursorLoader 這個類的源碼，看 Google 自己是怎么使用 getContentResolver().query 的。

1.13 ContentProvider 是如何在不同應用程序之間傳輸數(shù)據(jù)的？

ContentProvider 是如何在不同應用程序之間傳輸數(shù)據(jù)

一個應用進程有 16 個 Binder 線程去和遠程服務進行交互，而每個線程可占用的緩存空間是 128KB 這樣，超過會報異常。
ContentResolver 雖然是通過 Binder 進程間通信機制打通了應用程序之間共享數(shù)據(jù)的通道，但 ContentProvider 組件在不同應用程序之間傳輸數(shù)據(jù)是基于匿名共享內(nèi)存機制來實現(xiàn)的。
有興趣的可以查看一下老羅的文章Android系統(tǒng)匿名共享內(nèi)存Ashmem（Anonymous Shared Memory）簡要介紹和學習計劃。

ContentProvider

總結(jié)

在這篇文章中，我對我所知道的 BroadcastReceiver 知識總進行了詳細的總結(jié)，希望大家通過本次閱讀都能有所收獲。
重點：學 Android 有一段時間了，我打算好好的梳理一下所學知識，到現(xiàn)在為止，我才總結(jié)完 Activity 、Service 、BroadcastRecevier 等，有關事件分發(fā)、滑動沖突、新能優(yōu)化等重要模塊，我后面也將詳盡的總結(jié)，歡迎大家關注 _yuanhao 的簡書~ ，方便及時接收更新，方便及時接收更新
如果有可以補充的知識點，歡迎大家在評論區(qū)指出。

碼字不易，你的點贊是我總結(jié)的最大動力！

由于我在「稀土掘金」「簡書」「CSDN」「博客園」等站點，都有新內(nèi)容發(fā)布。所以大家可以直接關注我的 GitHub 倉庫，以免錯過精彩內(nèi)容！
倉庫地址：
超級干貨！精心歸納 Android 、JVM 、算法等，各位帥氣的老鐵支持一下！給個 Star ！
一萬多字長文，加上精美思維導圖，記得點贊哦，歡迎關注 _yuanhao 的簡書~ ，方便及時接收更新 ，我們下篇文章見！

Android

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频

Android 這 13 道 ContentProvider 面試題，你都會了嗎？

Android 這 13 道 ContentProvider 面試題，你都會了嗎？

前言

文章目錄

方便大家學習，我在 GitHub 上建立個倉庫

1.1 Android 為什么要設計 ContentProvider 這個組件？

1.2 如何訪問自定義 ContentProvider

1.3 通過 ContentResolver 獲取 ContentProvider 內(nèi)容的基本步驟

1.4 ContentProvider 是如何實現(xiàn)數(shù)據(jù)共享的：

1.5 為什么要用 ContentProvider ?它和 sql 的實現(xiàn)上有什么差別?

1.6 Uri 介紹

1.7 如何訪問 asserts 資源目錄下的數(shù)據(jù)庫?

1.8 多個進程同時調(diào)用一個 ContentProvider 的 query 獲取數(shù)據(jù)，ContentPrvoider 是如何反應的呢？

1.9 Android 設計 ContentProvider 的目的是什么呢？

1.10 運行在主線程的 ContentProvider 為什么不會影響主線程的UI操作?

1.11 外提供數(shù)據(jù)共享，那么如何限制對方的使用呢？

1.11.1 如果我們只需要開放部份的 `URI` 給其他的應用訪問呢？

1.12 ContentProvider 接口方法運行在哪個線程中呢？

1.12.1 這點還是比較好理解的，那如果我要問每個 ContentProvider 的操作是在哪個線程中運行的呢?（其實我們關心的是 UI 線程和工作線程）

1.13 ContentProvider 是如何在不同應用程序之間傳輸數(shù)據(jù)的？

總結(jié)

碼字不易，你的點贊是我總結(jié)的最大動力！

推薦閱讀更多精彩內(nèi)容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美 国产 综合 欧美 视频

Android 這 13 道 ContentProvider 面試題，你都會了嗎？

前言

文章目錄

方便大家學習，我在 GitHub 上建立個 倉庫

1.1 Android 為什么要設計 ContentProvider 這個組件？

1.2 如何訪問自定義 ContentProvider

1.3 通過 ContentResolver 獲取 ContentProvider 內(nèi)容的基本步驟

1.4 ContentProvider 是如何實現(xiàn)數(shù)據(jù)共享的：

1.5 為什么要用 ContentProvider ?它和 sql 的實現(xiàn)上有什么差別?

1.6 Uri 介紹

1.7 如何訪問 asserts 資源目錄下的數(shù)據(jù)庫?

1.8 多個進程同時調(diào)用一個 ContentProvider 的 query 獲取數(shù)據(jù)，ContentPrvoider 是如何反應的呢？

1.9 Android 設計 ContentProvider 的目的是什么呢？

1.10 運行在主線程的 ContentProvider 為什么不會影響主線程的UI操作?

1.11 外提供數(shù)據(jù)共享，那么如何限制對方的使用呢？

1.11.1 如果我們只需要開放部份的 URI 給其他的應用訪問呢？

1.12 ContentProvider 接口方法運行在哪個線程中呢？

1.12.1 這點還是比較好理解的，那如果我要問每個 ContentProvider 的操作是在哪個線程中運行的呢?（ 其實我們關心的是 UI 線程和工作線程 ）

1.13 ContentProvider 是如何在不同應用程序之間傳輸數(shù)據(jù)的？

總結(jié)

碼字不易，你的點贊是我總結(jié)的最大動力！

推薦閱讀更多精彩內(nèi)容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频

方便大家學習，我在 GitHub 上建立個倉庫

1.11.1 如果我們只需要開放部份的 `URI` 給其他的應用訪問呢？

1.12.1 這點還是比較好理解的，那如果我要問每個 ContentProvider 的操作是在哪個線程中運行的呢?（其實我們關心的是 UI 線程和工作線程）