聯(lián)系人信息的存儲結(jié)構(gòu)：

從Android 2.0(API Level 5)開始，Android平臺提供了一個改進的Contacts API，以適應(yīng)一個聯(lián)系人可以有多個帳戶的需求，比如說手機通訊錄和GMAIL通訊錄，兩個通訊錄中的兩條記錄可以是同一個人。新的Contacts API主要是由ContactsContract及其相關(guān)的類來管理，舊的API(android.provider.Contacts）已不贊成使用，但為了兼容仍可以使用，只不過像以前一樣，只能返回第一個帳戶的信息。

在新的Contacts API中，聯(lián)系人數(shù)據(jù)被放到三張表中：Contacts、RawContacts和Data。這樣可以幫助系統(tǒng)更好地存儲與管理一個聯(lián)系人的多個帳戶的信息。

Data：

Data表存儲了聯(lián)系人的詳細信息，表中的每一行存儲一個特定類型的信息，比如Email、Address或Phone。每一行通過一個mimetype_id的字段來表示該行存儲的是什么類型的數(shù)據(jù)，該字段引用了mimetyps表，此表存儲了常用的數(shù)據(jù)類型。Data表的字段主要有：

mimetype_id 表示該行存儲的信息的類型
raw_contact_id 表示該行所屬的RawContact
is_primary 多個data數(shù)據(jù)組成一個raw contact，該字段表示此data是否是其所屬的raw contact的主data，即其display name會作為raw contact的display name
is_super_primary 該data是否是其所屬的contact的主data，如果is_super_primary為1則is_primary一定為1
data1~data15 15個數(shù)據(jù)字段，對于不同類型的信息，表示不同的含義，ContactsContract.CommomDataKinds類中定義了與常用的數(shù)據(jù)類型相對應(yīng)的一些類，這些類中分別定義了相應(yīng)數(shù)據(jù)類型中這些字段表示的含義。一般data1表是主信息（如電話，Email地址等），data2表示副信息，data15表示Blob數(shù)據(jù)。
data_sync1~data_sync4 sync_adapter要用的字段（sync_adapter用于數(shù)據(jù)的同步，比如你手機中的Gmail帳戶與Google服務(wù)器的同步）。
data_version 數(shù)據(jù)的版本，用于數(shù)據(jù)的同步。

RawContact：

RawContact表中的一行存儲Data表中一些數(shù)據(jù)行的集合及一些其他的信息，表示一個聯(lián)系人某一特定帳戶的信息，比如Facebook或Exchange的一個聯(lián)系人。

當(dāng)插入一個raw contact或當(dāng)一個raw contact所屬的一個data改變時，系統(tǒng)會檢查這個raw contact跟其他的raw contact是否可以匹配（比如如果兩個raw contact的data包含相同的電話號碼或名字），如果匹配他們就會被綜合到一起，也就是說他們會屬于同一個cantact，表現(xiàn)為在RawContact表中他們引用的cantact_id是一樣的。

聯(lián)系人姓名、組織、電話號碼、Email或昵稱的改變會引發(fā)raw contact的重新聚合。有兩個方法控制聚合的行為Aggregaton Mode與ContactsContract.AggregationExceptions。

Aggregaton Mode：

RawContact表中有一個字段aggregation_mode，通過向特定raw contact行中插入這個字段可以修改系統(tǒng)對這個raw contact的聚合行為，其允許的值如下：

AGGREGATION_MODE_DEFAULT：正常模式，允許自動聚合；
AGGREGATION_MODE_DISABLE：不允許聚合；
AGGREGATION_MODE_SUSPENDED：當(dāng)一個raw contact的aggregation mode修改為suspended時，如果其已是一個已聚合的contact的一部分，那么它仍會保持與原來聚合到一起的raw contact的關(guān)系，即使它已改變不再跟其他raw contact匹配。

AGGREGATIONEXCEPTIONS：

在數(shù)據(jù)庫中存在一個表：agg_exceptions。通過字段raw_contact_id1、raw_contact_id2、mode存儲兩個raw contact聚合的方法，系統(tǒng)定義的聚合行為有3個：

TYPE_AUTOMATIC=0　　由系統(tǒng)決定聚合行為，默認值。
TYPE_KEEP_SEPARATE=2　　不聚合
TYPE_KEEP_TOGETHER=1　　聚合

Contact：

Contact表中的一行表示一個聯(lián)系人，它是RawContact表中的一行或多行的數(shù)據(jù)的組合，這些RawContact表中的行表示同一個人的不同的帳戶信息。Contact中的數(shù)據(jù)由系統(tǒng)組合RawContact表中的數(shù)據(jù)自動生成。

不可以直接向這個表中插入數(shù)據(jù)，當(dāng)一個raw contact被插入的時候，系統(tǒng)會首先查找Contact表看是否有記錄跟插入的raw contact表示同一個人，如果找到了，則把找到的這個contact的_ID插入raw contact記錄的CONTACT_ID字段，如果沒有找到，則系統(tǒng)自動插入一個Contact記錄并把它的_ID插入新插入的raw contact的CONTACT_ID列。

Contact表中只有TIMES_CONTACTED、LAST_TIME_CONTACTED、STARRED、CUSTOM_RINGTONE、SENE_TO_VOICEMAIL列可更改，這些列的更改會導(dǎo)致相應(yīng)的raw contact被更改。

當(dāng)刪除Contact表中的記錄時，會刪除一個聯(lián)系人的所有帳戶的信息，也就是說，其對應(yīng)的所有raw contacts也會被刪除，各raw contact對應(yīng)的data也就被刪除了，sync adapter同步時也會刪除服務(wù)器端的相應(yīng)記錄。

如果需要讀取一個聯(lián)系人的信息用CONTENT_LOOKUP_RUI代替CONTENT_URI（見后面）；

如果需要通過電話號碼查找一個聯(lián)系人，用PhoneLookup.CONTENT_FIILTER_URI，這個URI為這個目的進行了優(yōu)化；

如果需要通過部分名字的匹配查找，用CONTENT_FILTER_URI；

如果需要通過email，address等信息查找，查找表ContactsContract.Data，結(jié)果包含contact ID，名字...

android.provider.ontactsContract.Data類

其定義如下：

 public final static class Data implements DataColumnsWithJoins {
        private Data() {}
        public static final Uri CONTENT_URI = Uri.withAppendedPath(AUTHORITY_URI, "data");
        public static final String CONTENT_TYPE = "vnd.android.cursor.dir/data";
    //This flag is useful (currently) only for vCard exporter in Contacts app
        public static final String FOR_EXPORT_ONLY = "for_export_only";
    /*Build a CONTENT_LOOKUP_URI style Uri for the parent ContactsContract.Contacts entry of the given ContactsContract.Data entry.*/
        public static Uri getContactLookupUri(ContentResolver resolver, Uri dataUri) {...}
    }

Data類定義了CONTENT_URI及CONTENT_TYPE，主要是繼承了DataColumnsWithJoins接口中的字段。DataColumnsWithJoins定義如下：

protected interface DataColumnsWithJoins extends BaseColumns, DataColumns, StatusColumns,
            RawContactsColumns, ContactsColumns, ContactNameColumns, ContactOptionsColumns,
            ContactStatusColumns {
    }

該接口只是綜合了一些接口，其中：

BaseColumns定義了_ID與_COUNT字段，ContentProvider查詢中都要用到的字段。

DataColumns定義了與Data表中字段一一對應(yīng)的常量

RawContactsColumns, ContactsColumns, ContactNameColumns, ContactOptionsColumns表示RawContact與Contact中的一些字段，定義到此類中以方便訪問。

由于聯(lián)系人的信息都是按類別存儲到了這個Data表中，所以我們要查找聯(lián)系人的信息只需要查這個表。Data類中的Data.CONTACT_ID與Data.RAW_CONTACT_ID分別表示該表項對應(yīng)的聯(lián)系人在Contact與RawContract表中的ID，我們只需要知道某一個聯(lián)系人的contactId或rawContractId，并根據(jù)其查找的數(shù)據(jù)的類型就可以查到相應(yīng)類型的信息。

Cursor c = getContentResolver().query(Data.CONTENT_URI,
          new String[] {Data._ID, Phone.NUMBER, Phone.TYPE, Phone.LABEL},
          Data.CONTACT_ID + "=?" + " AND "
                  + Data.MIMETYPE + "='" + Phone.CONTENT_ITEM_TYPE + "'",
          new String[] {String.valueOf(contactId)}, null);

以上代碼根據(jù)聯(lián)系人的contractId，并通過設(shè)置其MIMETYPE為Phone.CONTENT_ITEM_TYPE查到了該聯(lián)系人的電話號碼，把Data.CONTACT_ID換為Data.RAW_CONTACT_ID即可查找相應(yīng)rawContactId對應(yīng)的電話號碼。其中用到了Phone.CONTENT_ITEM_TYPE，這是什么呢？

CommonDataKinds類

在前面講Data表的結(jié)構(gòu)時講到，Data的data1~data15字段用于存儲各類型的數(shù)據(jù)信息，那么這15個字段分別表示什么信息呢？

前面提到了，Data表中有一個mimetype_id字段，通過這個字段關(guān)聯(lián)mimetypes表表示該行代表的信息類型，因為Data表中的每一行可以表示如Phone或Address等不同類型的信息，所以對于不同類型的信息，data1~data15這15列表示不同的含義，如果要靠記憶記住這15列對于特定的類型分別表示什么意義自然不行，于是Google就預(yù)定義了一些類，每一個類對應(yīng)一些預(yù)先定義好的數(shù)據(jù)類型，在每個類中定義了一些語義地、方便記憶的常量，用來對應(yīng)這15個字段，比如在CommonDataKinds.Email類中有如下定義

public static final String ADDRESS = DATA1;
public static final String DISPLAY_NAME = DATA4;

DATA1與DATA4為繼承自DataColumns中的常量，在DataColumns中是這樣定義的：

public static final String DATA1 = "data1";
public static final String DATA4 = "data4";

這樣，當(dāng)于們要查找Email地址時，只需要通過ContactsContract.CommonDataKinds.Email.ADDRESS引用，而不需要知道它是存儲在Data表中的data1列中。

回到上一個問題，上面查詢電話號碼的例子中用到了Phone.CONTENT_ITEM_TYPE，即是表示CommonDataKinds.Phone.CONTENT_ITEM_TYPE，在Phone類中有如下定義

public static final String CONTENT_ITEM_TYPE = "vnd.android.cursor.item/phone_v2";

vnd.android.cursor.item/phone_v2 就是表示Data表中相應(yīng)的行存儲的是電話號碼的信息，通過相應(yīng)類型（如Phone、Email）的CONTENT_ITEM_TYPE，我們就可以指定要查詢的MIMETYPE，即要查詢的數(shù)據(jù)類型。

其實在上面的例子中還有更簡單的方法：

Cursor phone = getContentResolver().query(ContactsContract.CommonDataKinds.Phone.CONTENT_URI,
    new String[] { CommonDataKinds.Phone.NUMBER }, CommonDataKinds.Phone.CONTACT_ID + " =? ",
    new String[] { String.valueOf(contactId) }, null);

只需把query的第一個參數(shù)處傳遞想查找的數(shù)據(jù)類型的相應(yīng)的類中的CONTENT_URI就可以了。

 Lookup Key

在新的Contact API中，為contact引入了lookup key的概念，當(dāng)你的程序需要保存對聯(lián)系人的引用時，用lookup key而別用row id，lookup key是contacts表中的一列，當(dāng)你有一個lookup key時，可以這樣構(gòu)造一個Uri：

Uri lookupUri = Uri.withAppendedPath(Contacts.CONTENT_LOOKUP_URI, lookupKey);

然后用這個Uri查詢：

Cursor c = getContentResolver().query(lookupUri, new String[]{Contacts.DISPLAY_NAME}, ...);
try {
    c.moveToFirst();
    String displayName = c.getString(0);
} finally {
    c.close();
}

用lookup key 而不用row id的原因是因為row id容易改變，用戶把原先兩個聯(lián)系人合并成一個或因為同步的問題都會導(dǎo)致row id的改變。lookup key是一個字符串，它由raw contact的標識連接組成。

使用row id會比使用lookup key效率高，你可以同時保存二者，然后聯(lián)合二者生成一個lookup uri：

Uri lookupUri = getLookupUri(contactId, lookupKey)

當(dāng)同時有row id跟lookup key時，系統(tǒng)會優(yōu)先以row id查詢，如果無查找結(jié)果或找到的結(jié)果跟lookup key不匹配，則再用lookup key查找。

初學(xué)android，連android代碼都沒寫過幾行，想學(xué)習(xí)一下Contact API，發(fā)現(xiàn)說2.0后API改了，2.0以前的機子基本上也被淘汰了吧，就只看一下2.0以后的API吧，在網(wǎng)上找一點有用的資料都沒有，找來找去就那幾個帖子，都可以說是SDK上的例子，本想找點參考的，最后發(fā)現(xiàn)還是只有SDK，看的暈頭轉(zhuǎn)行的，只有了一些最基本的理解，像跟IM有關(guān)的StatusColumns之類的還有Directory等就只粗略看了一眼就過去了。畢竟剛接觸android，SDK的文檔即使每一句話都能看懂也不太了解意思，不知道在哪用，先把看懂的記一下吧，免得以后又忘了。只是把SDK中分散到各頁面的東西綜合了一下。有錯的方希望別誤導(dǎo)了人。