相關(guān)文章：
蘋果通知中心服務(wù)ANCS協(xié)議分析
低功耗藍(lán)牙BLE介紹

jiesean攝

IOS設(shè)備的ANCS服務(wù)是為了周邊設(shè)備通過低功耗藍(lán)牙獲取實(shí)時(shí)通知而產(chǎn)生的機(jī)制，它實(shí)際上是ble gatt協(xié)議的一種封裝。

本人作為android開發(fā)者，對(duì)ios的開發(fā)一竅不通，但是android從4.3開始也提供了對(duì)于ble的支持，這給了我們一種ios設(shè)備與android設(shè)備互聯(lián)的可能，此文重要針對(duì)發(fā)現(xiàn)ANCS和從ANCS中獲取ios通知的過程中的幾個(gè)重要的問題做出說明。

區(qū)分GAP和GATT中定義的角色的不同

1. 首先GAP中定義了兩種角色，一種是中心設(shè)備，主要以ios設(shè)備為主；二是周邊設(shè)備，以小型的低功耗設(shè)備為主，比如iwatch、各種手環(huán)等，他主要是從連接的層面下的定義，即中心設(shè)備可以同時(shí)連接不同的周邊設(shè)備，而一個(gè)周邊設(shè)備只能連接一個(gè)中心設(shè)備。
2. 而對(duì)于GATT來說，他是基于c/s模型的，因此它又一個(gè)server和client的區(qū)分，保持有service和characteristic的為server，而連接上server去讀寫這些characteristic的為client。

不能想當(dāng)然的認(rèn)為中心設(shè)備等同于server,周邊設(shè)備等同于client，他們是不同層面的東西。以兩個(gè)不同的生活場(chǎng)景進(jìn)行舉例說明：

• 手環(huán)中的傳感器獲取人的運(yùn)動(dòng)狀態(tài)以及身體數(shù)據(jù)，ios設(shè)備從手環(huán)中獲取這些基礎(chǔ)的數(shù)據(jù)來進(jìn)行進(jìn)一步的處理和分析。這個(gè)場(chǎng)景中手環(huán)是提供數(shù)據(jù)者，ios設(shè)備從中獲取設(shè)備，因?yàn)榇藭r(shí)，ios是client，手環(huán)是server。
• iwatch等智能手表，可以同步ios設(shè)備的短信和來電等，此時(shí)數(shù)據(jù)的提供者是ios設(shè)備，而智能手表則作為數(shù)據(jù)獲取者，此時(shí)ios是server，而智能周邊設(shè)備則是client.

發(fā)現(xiàn)和綁定ios設(shè)備

如果有了ANCS的基本的知識(shí),我們知道ANCS其實(shí)是基于ble gatt協(xié)議的，而ANCS扮演的就是gatt協(xié)議中的gatt server中的一個(gè)service，我們想要獲取該service中的內(nèi)容的話需要gatt client先掃描到該設(shè)備，然后連接上gatt server就可以讀寫其中的service和characteristic來獲得信息。

但是根據(jù)官方提供的ble gatt client的api實(shí)現(xiàn)簡(jiǎn)單的應(yīng)用的話，發(fā)現(xiàn)能夠掃描到很多的ble設(shè)備,但是始終無法掃描到ANCS這個(gè)服務(wù)，這是什么原因呢？莫非ios設(shè)備沒有打開該服務(wù)？
其實(shí)并不是這樣的，只要ios設(shè)備的藍(lán)牙打開后，ANCS就會(huì)不停的發(fā)送廣播告之周圍的gatt client。

那么既然ANCS打開了我們?yōu)槭裁磼呙璨坏侥兀?br> 原因是IOS對(duì)與ANCS服務(wù)做了特殊的限制，只有同ios設(shè)備進(jìn)行連接和綁定的設(shè)備才能后發(fā)現(xiàn)ANCS.

ios藍(lán)牙的限制我們都知道，那么如何才能夠同ios設(shè)備進(jìn)行連接和綁定呢？
這里我給出的解決方案是：

1. ios設(shè)備上需要虛擬一個(gè)ble周邊設(shè)備。可以通過調(diào)用gatt server的api自己實(shí)現(xiàn)app，或者下載lightblue。
2. 掃描到ios設(shè)備上的自己虛擬出來的周邊設(shè)備后，跟該設(shè)備綁定。

//android提供的代碼如下：
BluetoothDevice device;
device.createBond();

3. 連接到該設(shè)備

device.connectGatt(getApplicationContext(), false, mGattCallback);

4. 連接成功后，就能夠獲得ANCS service了

BluetoothGattService ancsService = gatt.getService(UUID.fromString(Constants.service_ancs));

ANCS的操作

這個(gè)在蘋果通知中心服務(wù)ANCS協(xié)議分析這篇文章中已經(jīng)做了詳細(xì)的描述，這里只是簡(jiǎn)單的梳理一下：

獲取通知的基本的信息：

訂閱Notification Source特性，可以在Notification Source特性中讀取通知的基本信息。

• 通知的事件類型（增刪改三種），很容易理解，ios設(shè)備產(chǎn)生了通知就是add；ios設(shè)備上查看了該通知，就會(huì)產(chǎn)生一個(gè)remove事件。
• 通知的事件標(biāo)志：可以從這個(gè)參數(shù)中看出ios設(shè)備給出的通知級(jí)別，以及可以對(duì)該通知執(zhí)行的動(dòng)作（這個(gè)稍后詳解）。
• 通知的范疇或者翻譯做種類？總之就是告訴你是個(gè)什么通知，比如是消息，來電，未接來電，郵件，新聞等，總共定義了12種。
• 該種類通知的活躍數(shù)量：就是幾條未接來電啊之類。
• UID：該通知的唯一標(biāo)示。

獲取通知的詳細(xì)信息：

首先訂閱 Data Source特性，然后往 Control Point中寫入獲得通知屬性的命令，然后在 Data Source中讀取通知詳細(xì)信息的數(shù)據(jù)包。
寫入命令的格式的示例，當(dāng)然可以獲得屬性不止這些：

byte[] getNotificationAttribute = { 
    //規(guī)定為０ 
    (byte) 0x00, 
    //UID，通知的id 
    uid[0], uid[1], uid[2], uid[3], 
    //title,Attribute 1,第一條屬性，通知的標(biāo)題 
    (byte) 0x01, (byte) 0xff, (byte) 0xff, 
    //message，第二條屬性，標(biāo)題的消息 
    (byte) 0x03, (byte) 0xff, (byte) 0xff
};

從Data Source中讀取的數(shù)據(jù)包格式

對(duì)通知執(zhí)行特定的動(dòng)作：

很容易理解，我們使用智能手表可以代接ios的消息，手表查看后，ios中的該信息的通知消失，這個(gè)消失的動(dòng)作就是針對(duì)消息型通知的特定動(dòng)作；而對(duì)于來電而言，就可以有接聽來電和拒絕接聽兩種操作。
ANCS將特定動(dòng)作分為negative action和positive action，但這里有兩個(gè)問題需要特別注意：

• 特定動(dòng)作是NC請(qǐng)求NP去執(zhí)行的，也就是說，動(dòng)作是在NP上面執(zhí)行。
• negative action和positive action對(duì)于不同類型的通知代表的含義是不同的，比如negative action對(duì)于來電就是拒絕接聽，而對(duì)于信息類型來說就是刪除通知。
• 并不是每一個(gè)通知都可以執(zhí)行這兩種動(dòng)作，比如消息類型的通知就只能執(zhí)行negative動(dòng)作，具體NC能夠去請(qǐng)求執(zhí)行哪些動(dòng)作，NP會(huì)告知你，下面進(jìn)行詳解。

前面獲取通知的基本的信息這一節(jié)中基本信息的第二項(xiàng)是事件標(biāo)志位eventFlags，它占一個(gè)字節(jié)，也就是8bit，這8bit每一位都表示一種屬性。

EventFlagSilent = (1 << 0),
EventFlagImportant = (1 << 1),
EventFlagPreExisting = (1 << 2),
EventFlagPositiveAction = (1 << 3),
EventFlagNegativeAction = (1 << 4),
Reserved EventFlags = (1 << 5)–(1 << 7)

由此可知，我們可以通過查看其第4、５位是否為１來判斷該通知可以執(zhí)行什么動(dòng)作。

暫時(shí)想到這些，想到再補(bǔ)。