蘋果ANCS官網(wǎng)ANCS spec：
https://developer.apple.com/library/content/documentation/CoreBluetooth/Reference/AppleNotificationCenterServiceSpecification/Introduction/Introduction.html#//apple_ref/doc/uid/TP40013460-CH2-SW1

此文大部分內(nèi)容來(lái)自官方的翻譯，加上了自己的一些蹩腳的理解。

一、簡(jiǎn)介

ANCS是Apple Notification Center Service的簡(jiǎn)稱，中文為蘋果通知中心服務(wù)。
ANCS是蘋果讓周邊藍(lán)牙設(shè)備（手環(huán)、手表等）可以通過(guò)低功耗藍(lán)牙訪問(wèn)IOS設(shè)備（iphone、ipad等）上的各類通知提供的一種簡(jiǎn)單方便的機(jī)制。

依賴

ANCS是基于BLE協(xié)議中的通用屬性協(xié)議（Generic Attribute Profile,GATT）協(xié)議實(shí)現(xiàn)的，他是GATT協(xié)議的一個(gè)子集。在ANCS協(xié)議中，IOS設(shè)備作為gatt-server,而周邊設(shè)備作為gatt client來(lái)連接和使用server提供的其他services。

端和字符編碼

除非特殊說(shuō)明，IOS設(shè)備ANCS與ble設(shè)備進(jìn)行通信的過(guò)程中都是采用的小端模式進(jìn)行傳輸?shù)?，比如NC接收到的attribute length數(shù)據(jù)為0x02 0x00,應(yīng)該解析為0x00 0x02，即長(zhǎng)度為2byte.
字符串的編碼采用了UTF-8編碼格式。

相關(guān)術(shù)語(yǔ)

NP（Notification Provider）:消息提供者，指的是ANCS服務(wù)的產(chǎn)生者，即IOS設(shè)備。
NC（Notification Consumer）:消息接受者，指的是ANCS服務(wù)的客戶端，即周邊BLE設(shè)備。

二、ANCS

蘋果通知中心服務(wù)的UUID為7905F431-B5CE-4E99-A40F-4B1E122D00D0。
由于IOS的特性限制，一個(gè)蘋果設(shè)備上只能有一個(gè)ANCS存在，一個(gè)ANCS可以連接多個(gè)client。因?yàn)锳NCS并不能保證始終存在（be present？），NC需要訂閱服務(wù)變更特性（the Service Changed characteristic of the GATT service ）以便任何時(shí)候都可以監(jiān)聽(tīng)準(zhǔn)備發(fā)布和取消發(fā)布的ANCS。

服務(wù)特性

ANCS有三個(gè)特性：

• Notification Source: UUID 9FBF120D-6301-42D9-8C58-25E699A21DBD
  通知源，權(quán)限是可通知
• Control Point: UUID 69D1D8F3-45E1-49A8-9821-9BBDFDAAD9D9
  控制點(diǎn)，權(quán)限是可寫入，可響應(yīng)
• Data Source: UUID 22EAC6E9-24D6-4BB5-BE44-B36ACE7C7BFB
  數(shù)據(jù)源，權(quán)限是可通知

所有的特性需要認(rèn)證（NC設(shè)備連接上NP并且完成配對(duì)和綁定）才能過(guò)連接。
對(duì)于NC來(lái)說(shuō)，通知源是必須訂閱的，其他兩個(gè)是可選擇的。

通知源

NC收到的通知源特性主要有三種事件：

• NP上新通知的到達(dá)
• NP上通知的修改
• NP上通知的刪除
  當(dāng)NC訂閱了通知源特性時(shí)，這些通知將會(huì)立刻被分發(fā)。因此NC在訂閱該特性時(shí)必須處于有能力接收和處理這些消息的狀態(tài)。

數(shù)據(jù)源特性分發(fā)的通知的格式

經(jīng)過(guò)數(shù)據(jù)源特性分發(fā)的Gatt通知包含一下信息：

• EventID：這個(gè)字段指明了iOS通知添加、修改或移除三種事件中的一種。該字段的枚舉值可參考后面附錄的EventID Value表。
• EventFlags：一個(gè)位掩碼，這個(gè)位掩碼表明了這個(gè)通知的一種特征。例如，如果一個(gè)通知被認(rèn)為是重要的，那么NC收到這個(gè)通知后，就想用明顯的方式提醒用戶。位掩碼的枚舉值在后面的EventFlags表中。
• CategoryID：通知的種類，分為郵件，來(lái)電，未接來(lái)電，社交，娛樂(lè)等多種分類，短信和微信扣扣等消息全部在社交（social）。
• CategoryCount：給定類型中活躍的通知的數(shù)量。例如，郵箱中有兩封未讀的郵件，這個(gè)時(shí)候又來(lái)了一封新的郵件，那么通知的郵件的數(shù)量將是3。
• NotificationUID：該通知的id，一個(gè)32位的數(shù)字來(lái)作為通知的唯一標(biāo)示（UID）。獲取更多該通知的信息時(shí)，這個(gè)數(shù)值在將作為命令中的一個(gè)句柄寫入控制點(diǎn)特性（即告訴控制點(diǎn)我想要獲得那條通知的詳細(xì)信息）。

IOS通知的生命周期

控制點(diǎn)和數(shù)據(jù)源

NC設(shè)備可能想要與IOS通知進(jìn)行交互。它可能需要獲得通知的更多信息，其中包括它的內(nèi)容以及在此基礎(chǔ)上進(jìn)行一些操作，這些都要通過(guò)控制點(diǎn)和數(shù)據(jù)源特性來(lái)實(shí)現(xiàn)。

NC可以通過(guò)往控制點(diǎn)特性里寫入命令來(lái)獲取關(guān)于通知的更多消息。如果命令寫入成功的話，NP會(huì)在數(shù)據(jù)源特性中通過(guò)通知流對(duì)該請(qǐng)求進(jìn)行回復(fù)。

獲取通知具體屬性的命令
獲取通知屬性命令使得NC可以得到某個(gè)特定通知的詳細(xì)屬性，比如短信的發(fā)送人，短信內(nèi)容，時(shí)間等。

通知屬性獲取命令的格式

該命令包含了一下的信息：

• CommandID: 設(shè)為零 (CommandIDGetNotificationAttributes)，0x00
• NotificationUID: 想要獲得的通知的uid,32位數(shù)字是通知的唯一標(biāo)示。
• AttributeIDs:NC想要獲得的屬性列表。有些屬性可能需要后面接一個(gè)16位的的參數(shù),0xff 0xff。

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
};

針對(duì)通知屬性獲取命令的響應(yīng)的格式

該響應(yīng)包含一下內(nèi)容：

• CommandID: 設(shè)為0 (CommandIDGetNotificationAttributes)。
• NotificationUID: 32位的UID。
• AttributeList:由屬性ID、16位長(zhǎng)度、屬性所組成的一個(gè)列表。一個(gè)屬性始終是字符串，并且它的長(zhǎng)度由16位長(zhǎng)度所決定，而不是以空(NULL)結(jié)束。如果所請(qǐng)求的屬性是空的，或者是錯(cuò)過(guò)了iOS通知，那么長(zhǎng)度設(shè)為0。

如果響應(yīng)的長(zhǎng)度大于GATT所規(guī)定的最大傳輸單元(Maximum Transmission Unit, MTU)，則NP會(huì)它分成多段傳送。NC必須將響應(yīng)的數(shù)據(jù)段重新組包。當(dāng)收到所有請(qǐng)求屬性的內(nèi)容時(shí)，則表示響應(yīng)完成。

獲得應(yīng)用屬性
獲取應(yīng)用屬性命令允許NC指定獲取NP上某個(gè)已安裝的應(yīng)用程序的屬性。

獲取應(yīng)用屬性命令的格式

獲取應(yīng)用屬性命令包含下面信息：

• CommandID：必須設(shè)置為1(CommandIDGetAppAttributes)。
• AppIdentifier：客戶端想要獲取信息的應(yīng)用程序的字符串標(biāo)志。字符串必須以空(NULL)結(jié)束。
• AttributeIDs：想要NC先要獲取的屬性列表。

應(yīng)用獲取命令的響應(yīng)的格式

響應(yīng)一個(gè)獲取應(yīng)用屬性命令的數(shù)據(jù)包含下面信息：

• CommandID：設(shè)置為1(CommandIDGetAppAttributes)。
• AppIdentifier：應(yīng)用的字符串標(biāo)識(shí)。字符串以空(NULL)結(jié)束。
• AttributeList：由屬性ID、16位長(zhǎng)度、屬性所組成的一個(gè)列表。一個(gè)屬性始終是字符串，并且它的長(zhǎng)度由16位長(zhǎng)度所決定，而不是以空(NULL)結(jié)束。如果所請(qǐng)求的屬性是空的，或者錯(cuò)過(guò)了應(yīng)用應(yīng)用程序，那么長(zhǎng)度設(shè)為0。

如果響應(yīng)數(shù)據(jù)的長(zhǎng)度大于GATT所規(guī)定的最大傳輸單元(Maximum Transmission Unit, MTU)，則NP會(huì)它分成多端傳送。NC必須將響應(yīng)的數(shù)據(jù)段重新組包。當(dāng)收到所有請(qǐng)求屬性的內(nèi)容時(shí)，則表示響應(yīng)完成。

**執(zhí)行通知?jiǎng)幼?br> 它允許NC向指定的iOS通知執(zhí)行一條預(yù)定動(dòng)作。

執(zhí)行通知?jiǎng)幼髅罡袷?/div>

一條執(zhí)行通知?jiǎng)幼靼旅嫘畔ⅲ?/p>

• CommandID：必須設(shè)置為2(CommandIDPerformNotificationAction)。
• NotificationUID：32位的數(shù)值。其值為要執(zhí)行動(dòng)作的的iOS通知的UID。
• ActionID：NC對(duì)指定iOS通知要執(zhí)行的動(dòng)作。

當(dāng)發(fā)送這個(gè)命令到控制點(diǎn)特征后，無(wú)論發(fā)送成功或失敗，數(shù)據(jù)源特征上都不會(huì)產(chǎn)生數(shù)據(jù)。也就是說(shuō)這是一個(gè)無(wú)需響應(yīng)的命令。

通知?jiǎng)幼?/strong>
從iOS8開始，NP發(fā)送的iOS通知起始可以間接的告訴NC可執(zhí)行哪些動(dòng)作。接著，NC就可以針對(duì)指定的iOS通知，請(qǐng)求NP執(zhí)行一個(gè)動(dòng)作。
通知源特征上生成的GATT通知包含一個(gè)叫做Eventflags的數(shù)據(jù)域，NC根據(jù)這個(gè)數(shù)據(jù)域就可得知對(duì)一條iOS通知可以執(zhí)行哪些操作：

• EventFlagPositiveAction：積極動(dòng)作(Positive Action)，與iOS通知相關(guān)。
• EventFlagNegativeAction：消極動(dòng)作(Negative Action)，與iOS通知相關(guān)。

實(shí)際的動(dòng)作都是由NP執(zhí)行的，這就表示：NC可執(zhí)行動(dòng)作都是由NP所決定的，而且根據(jù)iOS通知的不同而不同。舉個(gè)例子，當(dāng)NC收到來(lái)電通知時(shí)，執(zhí)行積極動(dòng)作可以接聽(tīng)，執(zhí)行消極動(dòng)作就拒接，而對(duì)于消息（官方是social）類型的通知而言，則只有消極操作，也就是說(shuō)，在手表等從設(shè)備上面只能查看消息，而無(wú)法回復(fù)。
NC不能預(yù)先去假設(shè)或嘗試猜測(cè)一條iOS通知確切的可執(zhí)行的動(dòng)作。因?yàn)檫@些動(dòng)作都是基于特定通知的，只有NP知道，而對(duì)NC無(wú)用的；同時(shí)還有其它的因素，如ANCS版本的變化等。這樣，NP才能保證積極動(dòng)作和消極動(dòng)作的結(jié)果都與用戶沒(méi)多大關(guān)系。
iOS 8系統(tǒng)中，NC通過(guò)發(fā)送獲取通知屬性命令，可獲取到某條iOS通知可執(zhí)行動(dòng)作的簡(jiǎn)潔描述：

• NotificationAttributeIDPositiveActionLabel：這條標(biāo)簽用于描述某條iOS通知可執(zhí)行的積極動(dòng)作。
• NotificationAttributeIDNegativeActionLavel：這條標(biāo)簽用于描述某條iOS通知可執(zhí)行的消極動(dòng)作。

三、生命周期

一個(gè)ANCS的服務(wù)周期開始于NC訂閱NP上的Notification Source characteristic，結(jié)束于NC取消該訂閱或者斷開連接。因?yàn)锳NCS不是一種完全同步的服務(wù)，它沒(méi)有追蹤不同周期中的狀態(tài)，因此所有的標(biāo)示以及NC、NP之間的數(shù)據(jù)交換只在某一個(gè)周期中是有效的。

當(dāng)一個(gè)周期結(jié)束后，NC應(yīng)該刪除其在本周期內(nèi)采集和存儲(chǔ)的所有的標(biāo)示以及數(shù)據(jù)。一個(gè)新的周期開始的時(shí)候，NP會(huì)可能的把所有存在的通知下發(fā)給NC。

四、錯(cuò)誤碼

當(dāng)往 Control Point characteristic中寫入控制命令時(shí),NC有時(shí)會(huì)受到ANCS錯(cuò)誤碼：

Unknown command (0xA0): 命令無(wú)法識(shí)別.

Invalid command (0xA1): 命令格式錯(cuò)誤.

Invalid parameter (0xA2): 參數(shù)錯(cuò)誤，例如notification uid并不存在對(duì)應(yīng)的notification對(duì)象.

Action failed (0xA3): 動(dòng)作沒(méi)有被執(zhí)行。

如果NP回復(fù)了一個(gè)錯(cuò)誤碼，那么Data Source characteristic中將不再產(chǎn)生任何回應(yīng)的命令的數(shù)據(jù)。

五、示例圖

以下兩個(gè)圖展示了NP和NC之間的兩種交互的過(guò)程的例子。Figure 2-7顯示了NC上想要開啟ANCS的基本流程；Figure 2-8 展示了NC獲得IOS通知更多信息的基本流程。

Figure 2-7 Service setup example

Figure 2-8 Notification attribute retrieval example