相關(guān)文章：
蘋果通知中心服務(wù)ANCS協(xié)議分析
低功耗藍(lán)牙BLE介紹
IOS設(shè)備的ANCS服務(wù)是為了周邊設(shè)備通過低功耗藍(lán)牙獲取實時通知而產(chǎn)生的機(jī)制付枫，它實際上是ble gatt協(xié)議的一種封裝涎永。
本人作為android開發(fā)者蛤铜，對ios的開發(fā)一竅不通辐董，但是android從4.3開始也提供了對于ble的支持调炬，這給了我們一種ios設(shè)備與android設(shè)備互聯(lián)的可能函筋，此文重要針對發(fā)現(xiàn)ANCS和從ANCS中獲取ios通知的過程中的幾個重要的問題做出說明盼忌。
區(qū)分GAP和GATT中定義的角色的不同
- 首先GAP中定義了兩種角色贝润，一種是中心設(shè)備绊茧，主要以ios設(shè)備為主；二是周邊設(shè)備打掘，以小型的低功耗設(shè)備為主华畏，比如iwatch、各種手環(huán)等尊蚁，他主要是從連接的層面下的定義亡笑，即中心設(shè)備可以同時連接不同的周邊設(shè)備，而一個周邊設(shè)備只能連接一個中心設(shè)備横朋。
- 而對于GATT來說仑乌，他是基于c/s模型的，因此它又一個server和client的區(qū)分，保持有service和characteristic的為server晰甚，而連接上server去讀寫這些characteristic的為client衙传。
不能想當(dāng)然的認(rèn)為中心設(shè)備等同于server,周邊設(shè)備等同于client，他們是不同層面的東西厕九。以兩個不同的生活場景進(jìn)行舉例說明：
- 手環(huán)中的傳感器獲取人的運動狀態(tài)以及身體數(shù)據(jù)粪牲，ios設(shè)備從手環(huán)中獲取這些基礎(chǔ)的數(shù)據(jù)來進(jìn)行進(jìn)一步的處理和分析。這個場景中手環(huán)是提供數(shù)據(jù)者止剖，ios設(shè)備從中獲取設(shè)備腺阳，因為此時，ios是client穿香，手環(huán)是server亭引。
- iwatch等智能手表，可以同步ios設(shè)備的短信和來電等皮获，此時數(shù)據(jù)的提供者是ios設(shè)備焙蚓，而智能手表則作為數(shù)據(jù)獲取者，此時ios是server洒宝，而智能周邊設(shè)備則是client.
發(fā)現(xiàn)和綁定ios設(shè)備
如果有了ANCS的基本的知識,我們知道ANCS其實是基于ble gatt協(xié)議的购公，而ANCS扮演的就是gatt協(xié)議中的gatt server中的一個service，我們想要獲取該service中的內(nèi)容的話需要gatt client先掃描到該設(shè)備雁歌，然后連接上gatt server就可以讀寫其中的service和characteristic來獲得信息宏浩。
但是根據(jù)官方提供的ble gatt client的api實現(xiàn)簡單的應(yīng)用的話，發(fā)現(xiàn)能夠掃描到很多的ble設(shè)備,但是始終無法掃描到ANCS這個服務(wù)靠瞎，這是什么原因呢比庄？莫非ios設(shè)備沒有打開該服務(wù)？
其實并不是這樣的乏盐，只要ios設(shè)備的藍(lán)牙打開后佳窑，ANCS就會不停的發(fā)送廣播告之周圍的gatt client。
那么既然ANCS打開了我們?yōu)槭裁磼呙璨坏侥兀?br> 原因是IOS對與ANCS服務(wù)做了特殊的限制父能，只有同ios設(shè)備進(jìn)行連接和綁定的設(shè)備才能后發(fā)現(xiàn)ANCS.
ios藍(lán)牙的限制我們都知道神凑，那么如何才能夠同ios設(shè)備進(jìn)行連接和綁定呢？
這里我給出的解決方案是：
- ios設(shè)備上需要虛擬一個ble周邊設(shè)備何吝「任可以通過調(diào)用gatt server的api自己實現(xiàn)app，或者下載lightblue岔霸。
- 掃描到ios設(shè)備上的自己虛擬出來的周邊設(shè)備后薛躬，跟該設(shè)備綁定俯渤。
//android提供的代碼如下：
BluetoothDevice device;
device.createBond();
- 連接到該設(shè)備
device.connectGatt(getApplicationContext(), false, mGattCallback);
- 連接成功后呆细，就能夠獲得ANCS service了
BluetoothGattService ancsService = gatt.getService(UUID.fromString(Constants.service_ancs));
ANCS的操作
這個在蘋果通知中心服務(wù)ANCS協(xié)議分析這篇文章中已經(jīng)做了詳細(xì)的描述，這里只是簡單的梳理一下：
獲取通知的基本的信息：
訂閱Notification Source特性，可以在Notification Source特性中讀取通知的基本信息絮爷。
- 通知的事件類型（增刪改三種）趴酣，很容易理解，ios設(shè)備產(chǎn)生了通知就是add坑夯；ios設(shè)備上查看了該通知岖寞，就會產(chǎn)生一個remove事件。
- 通知的事件標(biāo)志：可以從這個參數(shù)中看出ios設(shè)備給出的通知級別柜蜈，以及可以對該通知執(zhí)行的動作（這個稍后詳解）仗谆。
- 通知的范疇或者翻譯做種類？總之就是告訴你是個什么通知淑履，比如是消息隶垮，來電，未接來電秘噪，郵件狸吞，新聞等，總共定義了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ù)包格式
前面文章中有說到這個數(shù)據(jù)包的長度如果超過最大長度就會被分為多段發(fā)送，這個最大長度經(jīng)親測為20byte跟狱。
而為了最大的有效信息的傳輸俭厚，除了第一個分段中包含commandID,Notification這兩個重要的標(biāo)示信息外，后面的分段并不包含這些驶臊，而是直接跟數(shù)據(jù)信息挪挤，也就是說你把拿到的所有分段直接組合起來就是完整的數(shù)據(jù)包，但是那個分段是最后的結(jié)束分段要通過參數(shù)的長度進(jìn)行計算关翎。
對通知執(zhí)行特定的動作：
很容易理解扛门，我們使用智能手表可以代接ios的消息，手表查看后纵寝，ios中的該信息的通知消失论寨，這個消失的動作就是針對消息型通知的特定動作；而對于來電而言，就可以有接聽來電和拒絕接聽兩種操作葬凳。
ANCS將特定動作分為negative action和positive action绰垂，但這里有兩個問題需要特別注意：
- 特定動作是NC請求NP去執(zhí)行的，也就是說火焰，動作是在NP上面執(zhí)行劲装。
- negative action和positive action對于不同類型的通知代表的含義是不同的，比如negative action對于來電就是拒絕接聽昌简，而對于信息類型來說就是刪除通知占业。
- 并不是每一個通知都可以執(zhí)行這兩種動作，比如消息類型的通知就只能執(zhí)行negative動作纯赎，具體NC能夠去請求執(zhí)行哪些動作纺酸，NP會告知你，下面進(jìn)行詳解址否。
前面獲取通知的基本的信息這一節(jié)中基本信息的第二項是事件標(biāo)志位eventFlags餐蔬，它占一個字節(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í)行什么動作词爬。
暫時想到這些，想到再補(bǔ)权均。
