相關文章：
蘋果通知中心服務ANCS協議分析
低功耗藍牙BLE介紹
IOS設備的ANCS服務是為了周邊設備通過低功耗藍牙獲取實時通知而產生的機制，它實際上是ble gatt協議的一種封裝。
本人作為android開發者，對ios的開發一竅不通，但是android從4.3開始也提供了對于ble的支持，這給了我們一種ios設備與android設備互聯的可能，此文重要針對發現ANCS和從ANCS中獲取ios通知的過程中的幾個重要的問題做出說明。
區分GAP和GATT中定義的角色的不同
- 首先GAP中定義了兩種角色，一種是中心設備，主要以ios設備為主；二是周邊設備，以小型的低功耗設備為主，比如iwatch、各種手環等，他主要是從連接的層面下的定義，即中心設備可以同時連接不同的周邊設備，而一個周邊設備只能連接一個中心設備。
- 而對于GATT來說，他是基于c/s模型的，因此它又一個server和client的區分，保持有service和characteristic的為server，而連接上server去讀寫這些characteristic的為client。
不能想當然的認為中心設備等同于server,周邊設備等同于client，他們是不同層面的東西。以兩個不同的生活場景進行舉例說明：
- 手環中的傳感器獲取人的運動狀態以及身體數據，ios設備從手環中獲取這些基礎的數據來進行進一步的處理和分析。這個場景中手環是提供數據者，ios設備從中獲取設備，因為此時，ios是client，手環是server。
- iwatch等智能手表，可以同步ios設備的短信和來電等，此時數據的提供者是ios設備，而智能手表則作為數據獲取者，此時ios是server，而智能周邊設備則是client.
發現和綁定ios設備
如果有了ANCS的基本的知識,我們知道ANCS其實是基于ble gatt協議的，而ANCS扮演的就是gatt協議中的gatt server中的一個service，我們想要獲取該service中的內容的話需要gatt client先掃描到該設備，然后連接上gatt server就可以讀寫其中的service和characteristic來獲得信息。
但是根據官方提供的ble gatt client的api實現簡單的應用的話，發現能夠掃描到很多的ble設備,但是始終無法掃描到ANCS這個服務，這是什么原因呢？莫非ios設備沒有打開該服務？
其實并不是這樣的，只要ios設備的藍牙打開后，ANCS就會不停的發送廣播告之周圍的gatt client。
那么既然ANCS打開了我們為什么掃描不到呢？
原因是IOS對與ANCS服務做了特殊的限制，只有同ios設備進行連接和綁定的設備才能后發現ANCS.
ios藍牙的限制我們都知道，那么如何才能夠同ios設備進行連接和綁定呢？
這里我給出的解決方案是：
- ios設備上需要虛擬一個ble周邊設備。可以通過調用gatt server的api自己實現app，或者下載lightblue。
- 掃描到ios設備上的自己虛擬出來的周邊設備后，跟該設備綁定。
//android提供的代碼如下：
BluetoothDevice device;
device.createBond();
- 連接到該設備
device.connectGatt(getApplicationContext(), false, mGattCallback);
- 連接成功后，就能夠獲得ANCS service了
BluetoothGattService ancsService = gatt.getService(UUID.fromString(Constants.service_ancs));
ANCS的操作
這個在蘋果通知中心服務ANCS協議分析這篇文章中已經做了詳細的描述，這里只是簡單的梳理一下：
獲取通知的基本的信息：
訂閱Notification Source特性，可以在Notification Source特性中讀取通知的基本信息。
- 通知的事件類型（增刪改三種），很容易理解，ios設備產生了通知就是add；ios設備上查看了該通知，就會產生一個remove事件。
- 通知的事件標志：可以從這個參數中看出ios設備給出的通知級別，以及可以對該通知執行的動作（這個稍后詳解）。
- 通知的范疇或者翻譯做種類？總之就是告訴你是個什么通知，比如是消息，來電，未接來電，郵件，新聞等，總共定義了12種。
- 該種類通知的活躍數量：就是幾條未接來電啊之類。
- UID：該通知的唯一標示。
獲取通知的詳細信息：
首先訂閱 Data Source特性，然后往 Control Point中寫入獲得通知屬性的命令，然后在 Data Source中讀取通知詳細信息的數據包。
寫入命令的格式的示例，當然可以獲得屬性不止這些：
byte[] getNotificationAttribute = {
//規定為０
(byte) 0x00,
//UID，通知的id
uid[0], uid[1], uid[2], uid[3],
//title,Attribute 1,第一條屬性，通知的標題
(byte) 0x01, (byte) 0xff, (byte) 0xff,
//message，第二條屬性，標題的消息
(byte) 0x03, (byte) 0xff, (byte) 0xff
};
從Data Source中讀取的數據包格式
前面文章中有說到這個數據包的長度如果超過最大長度就會被分為多段發送，這個最大長度經親測為20byte。
而為了最大的有效信息的傳輸，除了第一個分段中包含commandID,Notification這兩個重要的標示信息外，后面的分段并不包含這些，而是直接跟數據信息，也就是說你把拿到的所有分段直接組合起來就是完整的數據包，但是那個分段是最后的結束分段要通過參數的長度進行計算。
對通知執行特定的動作：
很容易理解，我們使用智能手表可以代接ios的消息，手表查看后，ios中的該信息的通知消失，這個消失的動作就是針對消息型通知的特定動作；而對于來電而言，就可以有接聽來電和拒絕接聽兩種操作。
ANCS將特定動作分為negative action和positive action，但這里有兩個問題需要特別注意：
- 特定動作是NC請求NP去執行的，也就是說，動作是在NP上面執行。
- negative action和positive action對于不同類型的通知代表的含義是不同的，比如negative action對于來電就是拒絕接聽，而對于信息類型來說就是刪除通知。
- 并不是每一個通知都可以執行這兩種動作，比如消息類型的通知就只能執行negative動作，具體NC能夠去請求執行哪些動作，NP會告知你，下面進行詳解。
前面獲取通知的基本的信息這一節中基本信息的第二項是事件標志位eventFlags，它占一個字節，也就是8bit，這8bit每一位都表示一種屬性。
EventFlagSilent = (1 << 0),
EventFlagImportant = (1 << 1),
EventFlagPreExisting = (1 << 2),
EventFlagPositiveAction = (1 << 3),
EventFlagNegativeAction = (1 << 4),
Reserved EventFlags = (1 << 5)–(1 << 7)
由此可知，我們可以通過查看其第4、５位是否為１來判斷該通知可以執行什么動作。
暫時想到這些，想到再補。
