在Android系統(tǒng)中，Content Provider作為應(yīng)用程序四大組件之一，它起到在應(yīng)用程序之間共享數(shù)據(jù)的作用，同時，它還是標(biāo)準(zhǔn)的數(shù)據(jù)訪問接口。前面的一系列文章已經(jīng)分析過Android應(yīng)用程序的其它三大組件（Activity、Service和Broadcast Receiver）了，本文將簡要介紹Content Provider組件在Android應(yīng)用程序設(shè)計中的地位，為進(jìn)一步學(xué)習(xí)打好基礎(chǔ)。

        我們知道，在Android系統(tǒng)上，每一個應(yīng)用程序都有一個獨立的用戶ID。為什么要給每一個應(yīng)用程序分配一個獨立的用戶ID呢？這是為了保護(hù)各個應(yīng)用程序的數(shù)據(jù)不被其它應(yīng)用程序惡意破壞而設(shè)計的。Android系統(tǒng)是基于Linux內(nèi)核來開發(fā)的，而在Linux系統(tǒng)中，每一個文件除了文件本身的數(shù)據(jù)之外，還具有一定的屬性，其中最重要的就是文件權(quán)限了。所謂的文件權(quán)限，就是指對文件的讀、寫和執(zhí)行權(quán)限。此外，Linux還是一個多用戶的操作系統(tǒng)，因此，Linux將系統(tǒng)中的每一個文件都與一個用戶以及用戶組關(guān)聯(lián)起來，基于不同的用戶而賦予不同的文件權(quán)限。只有當(dāng)一個用戶對某個文件擁有相應(yīng)的權(quán)限時，才能執(zhí)行相應(yīng)的操作，例如，只有當(dāng)一個用戶對某個文件擁有讀權(quán)限時，這個用戶才可以調(diào)用read系統(tǒng)調(diào)用來讀取這個文件的內(nèi)容。Android系統(tǒng)繼承了Linux系統(tǒng)管理文件的方法，為每一個應(yīng)用程序分配一個獨立的用戶ID和用戶組ID，而由這個應(yīng)用程序創(chuàng)建出來的數(shù)據(jù)文件就賦予相應(yīng)的用戶以及用戶組讀寫的權(quán)限，其余用戶則無權(quán)對該文件進(jìn)行讀寫。

        如果我們通過adb shell命令連上模擬器，切換到/data/data目錄下，就可以看到很多以應(yīng)用程序包（package）命名的文件夾，這些文件夾里面存放的就是各個應(yīng)用程序的數(shù)據(jù)文件，例如，如果我們進(jìn)入到Android系統(tǒng)日歷應(yīng)用程序數(shù)據(jù)目錄com.android.providers.calendar下的databases文件中，會看到一個用來保存日歷數(shù)據(jù)的數(shù)據(jù)庫文件calendar.db，它的權(quán)限設(shè)置如下所示：

root@android:/data/data/com.android.providers.calendar/databases # ls -l
-rw-rw---- app_17   app_17      33792 2011-11-07 15:50 calendar.db

 

        在前面的十字符-rw-rw----中，最前面的符號-表示這是一個普通文件，接下來的三個字符rw-表示這個文件的所有者對這個文件可讀可寫不可執(zhí)行，再接下來的三個字符rw-表示這個文件的所有者所在的用戶組的用戶對這個文件可讀可寫不可執(zhí)行，而最后的三個字符---表示其它的用戶對這個文件不可讀寫也不可執(zhí)行，因為這是一個數(shù)據(jù)文件，所認(rèn)所有用戶都不可以執(zhí)行它是正確的。在接下來的兩個app_17字符串表示這個文件的所有者和這個所有者所在的用戶組的名稱均為app_17，這是應(yīng)用程序在安裝的時候系統(tǒng)分配的，在不同的系統(tǒng)上，這個字符串可能是不一樣，不過它所表示的意義是一樣的。這意味著只有用戶ID為app_17或者用戶組ID為app_17的那些進(jìn)程才可以對這個calendar.db文件進(jìn)行讀寫操作。我們通過執(zhí)行終端上執(zhí)行ps命令來查看一下哪個進(jìn)程的用戶ID為app_17：

root@android:/ # ps
USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME
root      1     0     272    184   c009f230 0000875c S /init
...      ...   ...    ...    ...      ...    ...         ...
app_17   295   35    107468 21492 ffffffff afd0c38c  S com.android.providers.calendar
..       ...   ...    ...    ...      ...    ...         ...
root     556   527   892    332   00000000 afd0b24c  R ps

        這里我們看到，正是這個日歷應(yīng)用程序com.android.providers.calendar進(jìn)程的用戶ID為app_17。這樣，就驗證了我們前面的分析了：只有這個日歷應(yīng)用程序com.android.providers.calendar才可以對這個calendar.db文件進(jìn)行讀寫操作。這個日歷應(yīng)用程序com.android.providers.calendar其實是由一個Content Provider組件來實現(xiàn)的，在下一篇文章中，我們將實現(xiàn)一個自己的Content Provider，然后再對Content Provider的實現(xiàn)原理進(jìn)行詳細(xì)分析。

 

        Android系統(tǒng)對應(yīng)用程序的數(shù)據(jù)文件作如此嚴(yán)格的保護(hù)會不會有點過頭了呢？如果一個應(yīng)用程序想要讀寫另外一個應(yīng)用程序的數(shù)據(jù)文件時，應(yīng)該怎么辦呢？舉一個典型的應(yīng)用場景，我們在開發(fā)自己的應(yīng)用程序時，有時候會希望讀取通訊錄里面某個聯(lián)系人的手機(jī)號碼或者電子郵件，以便可以對這個聯(lián)系人打電話或者發(fā)送電子郵件，這時候就需要讀取通訊錄里面的聯(lián)系人數(shù)據(jù)文件了。

        現(xiàn)在在互聯(lián)網(wǎng)里面，都流行平臺的概念，各大公司都打著開放平臺的口號，來吸引第三方來為自己的平臺做應(yīng)用，例如，國外最流行的Fackbook開放平臺和Google+開放平臺等，國內(nèi)的有騰訊的Q+開放平臺，還有新浪微博開放平臺、360的開放平臺等。這些開放平臺的核心就是要開放用戶數(shù)據(jù)給第三方來使使用，就像前面我們說的Android系統(tǒng)的通訊錄，它需要把自己聯(lián)系人數(shù)據(jù)開放出來給其它應(yīng)用程序使用。但是，這些數(shù)據(jù)都是各個平臺自己的核心數(shù)據(jù)和核心競爭力，它們需要有保護(hù)地進(jìn)行開放。Android系統(tǒng)中的Content Provider應(yīng)用程序組件正是結(jié)合上面分析的這種文件權(quán)限機(jī)制來秉承這種有保護(hù)地開放自己的數(shù)據(jù)給其它應(yīng)用程序使用的理念。

        從另外一個觀點來看，即使我們不是在做平臺，而只是在做一個應(yīng)用程序軟件，是不是就不需要這么使用到Content Provider機(jī)制了呢？非也，現(xiàn)在的應(yīng)用程序軟件，越著公司業(yè)務(wù)的成長，越來越龐大，越來越復(fù)雜。軟件工程告訴我們，我們在設(shè)計這種大型的復(fù)雜的軟件的時候，需要分模塊和分層次來實現(xiàn)各個子功能組件，使得各個模塊功能以松耦合的方式組織在一起完成整個應(yīng)用程序功能。這樣做的好處當(dāng)然就是便于我們維護(hù)和擴(kuò)展應(yīng)用程序的代碼和功能了，以及適應(yīng)復(fù)雜的業(yè)務(wù)環(huán)境。在一個大型的應(yīng)用程序軟件架構(gòu)中，從垂直的方向來看，一般都會劃分為數(shù)據(jù)層、數(shù)據(jù)訪問接口層以及上面的業(yè)務(wù)層。數(shù)據(jù)層用來保存數(shù)據(jù)，這些數(shù)據(jù)可以用文件的方式來組織，也可以用數(shù)據(jù)庫的方式來組織，甚至可以保存在網(wǎng)絡(luò)中；數(shù)據(jù)訪問層負(fù)責(zé)向上面的業(yè)務(wù)層提供數(shù)據(jù)，而向下管理好數(shù)據(jù)層的數(shù)據(jù)；最后業(yè)務(wù)層通過數(shù)據(jù)訪問層來獲取一些業(yè)務(wù)相關(guān)的數(shù)據(jù)來實現(xiàn)自己的業(yè)務(wù)邏輯。

        基于這種開放平臺建設(shè)或者復(fù)雜軟件架構(gòu)的理念，我們得出一個Android應(yīng)用程序設(shè)計的一般方法，如下圖所示：

        在這個架構(gòu)中， 數(shù)據(jù)層采用數(shù)據(jù)庫、文件或者網(wǎng)絡(luò)來保存數(shù)據(jù)，數(shù)據(jù)訪問層使用Content Provider來實現(xiàn)，而業(yè)務(wù)層就通過一些APP來實現(xiàn)。為了降低各個功能模塊間耦合性，我們可以把業(yè)務(wù)層的各個APP和數(shù)據(jù)訪問層中的Content Provider，放在不同的應(yīng)用程序進(jìn)程中來實現(xiàn)，而數(shù)據(jù)庫中的數(shù)據(jù)統(tǒng)一由Content Provider來管理，即Content Provider擁有對這些文件直接進(jìn)行讀寫的權(quán)限，同時，它又根據(jù)需要來有保護(hù)地把這些數(shù)據(jù)開放出來給上層的APP來使用。

        那么，Content Provider又是如何把數(shù)據(jù)開放給上面的APP使用呢？一方面是這些APP沒有權(quán)限讀取這些數(shù)據(jù)文件，另一外面是Content Provider和這些APP是在不同的進(jìn)程空間里面。回憶一下，我們在前面Android進(jìn)程間通信（IPC）機(jī)制Binder簡要介紹和學(xué)習(xí)計劃這一系文章中學(xué)習(xí)的Android系統(tǒng)中Binder進(jìn)程間通信機(jī)制，不同的應(yīng)用程序之間可以通過Binder進(jìn)程間調(diào)用來傳輸數(shù)據(jù)。因此，前面關(guān)于一個應(yīng)用程序應(yīng)該如何來讀寫另外一個應(yīng)用程序的數(shù)據(jù)的問題的答案就是使用Binder進(jìn)程間通信機(jī)制，雖然一個應(yīng)用程序不能直接讀取另一個應(yīng)用程序的數(shù)據(jù)，但是它卻可以通過進(jìn)程間通信方式來請求另一個這個應(yīng)用程序給它傳輸數(shù)據(jù)。這樣我們就解決了文件權(quán)限限制所帶來的問題了。

        然而，事情還不是那么簡單，一般Content  Provider管理的都是大量的數(shù)據(jù)，如果在進(jìn)程間傳輸大量的數(shù)據(jù)，效率是不是會很低下呢？這時候，前面我們在Android系統(tǒng)匿名共享內(nèi)存Ashmem（Anonymous Shared Memory）簡要介紹和學(xué)習(xí)計劃這一系列文章中學(xué)習(xí)的匿名共享內(nèi)存（Anonymous Shared Memory）就派上用場了。把需要在進(jìn)程間傳輸?shù)臄?shù)據(jù)都寫到共享內(nèi)存中去，然后只能通過Binder進(jìn)程間通信機(jī)制來傳輸一個共享內(nèi)存的打開文件描述符給對方就好了，是不是很簡單呢。在Android系統(tǒng)中，Binder進(jìn)程間通信機(jī)制和匿名共享內(nèi)存機(jī)制結(jié)合在一起使用，真是太完美了。

        Content Provider如何在應(yīng)用程序之間共享數(shù)據(jù)以及它在應(yīng)用程序設(shè)計中的地位就簡要介紹到這里了，在接下來的四篇文章中，我們將以一個 Content Provider的應(yīng)用實例來詳細(xì)分析它的啟動過程、數(shù)據(jù)共享原理以及數(shù)據(jù)監(jiān)控機(jī)制：

        1. Android應(yīng)用程序組件Content Provider的應(yīng)用實例。

        2. Android應(yīng)用程序組件Content Provider的啟動過程源代碼分析。

        3. Android應(yīng)用程序組件Content Provider在不同應(yīng)用程序之間共享數(shù)據(jù)的原理分析。

        4. Android應(yīng)用程序組件Content Provider的數(shù)據(jù)監(jiān)控機(jī)制分析。

        敬請關(guān)注！