這是一個對于Apple開發(fā)者文檔的翻譯，基于自己的知識經(jīng)驗和有道詞典帖烘，希望能為需要的同仁提供一些幫助。水平有限橄杨，不足之處還望指出秘症，好做更正照卦，避免誤導他人。
先貼上原文鏈接](https://developer.apple.com/library/ios/documentation/CoreBluetooth/Reference/AppleNotificationCenterServiceSpecification/Introduction/Introduction.html#//apple_ref/doc/uid/TP40013460)
介紹
ANCS的目的是給藍牙外設（指通過BLE與iOS設備建立連接的設備）一種簡單方便的方式去接收各種各樣的產(chǎn)生于iOS設備上的通知乡摹。
ANCS的設計遵循三個原則：簡單的役耕，高效的，可擴展的聪廉∷捕唬基于此，不管是簡單的led設備板熊，還是大型的能源設備都能在一定范圍內有效發(fā)現(xiàn)這個服務框全。
依賴
除了遵循標注GATT的子程序，ANCS沒有什么依賴邻邮。一個作為GATT客戶端的設備在使用ANCS的同時可以使用其他的服務與iOS設備通信竣况。這里說明藍牙設備在與iOS設備透過其它服務通信的同時可以使用ANCS服務。
字節(jié)與編碼
除非特別說明,所有ANCS通道數(shù)值采用小端字節(jié)序
除非特別說明,所有ANCS通道的字符串才有UTF－8編碼
術語
蘋果通知中心服務被簡稱為ANCS
ANCS服務發(fā)行端（iOS設備）被稱為通知提供者（NP）
ANCS服務客戶端（外圍設備）被稱為通知消費者（NC）
出現(xiàn)在iOS設備的通知中心的通知稱為iOS通知
通過GATT特征作為異步信息發(fā)送的通知稱為GATT通知
蘋果通知中心服務
蘋果通知中心服務是一項基礎服務筒严，服務UUID是7905F431-B5CE-4E99-A40F-4B1E122D00D0.
在一個NP上同時只允許一個ANCS實例存在。由于iOS的特性情萤，ANCS實例并不總是存在鸭蛙，基于這個結果，為了能夠監(jiān)聽到ANCS隨時不定發(fā)送的通知筋岛，NC隨時需要尋找并訂閱ANCS服務改變的GATT特征娶视。
服務特征
從基本要素上看，ANCS暴露了3個特征
通知源 ：UUID 9FBF120D-6301-42D9-8C58-25E699A21DBD (notifiable)
控制點：UUID 69D1D8F3-45E1-49A8-9821-9BBDFDAAD9D9 (writeable with response)
數(shù)據(jù)源： UUID 22EAC6E9-24D6-4BB5-BE44-B36ACE7C7BFB (notifiable)
所有這些特征都需要授權使用睁宰。
通知源特征的支持是強制的肪获，然而控制點和數(shù)據(jù)源的特征支持是可選的。
Note：ANCS擁有除了上面說的三種之外的特征柒傻，也就是說孝赫，一個NC可以忽略任何他不能識別的特征。
通知源
通知源特征是基于NC接收到下述消息之上的特征：
NP上新的iOS通知的到達
NP上iOS通知的修正
NP上iOS通知的移除
GATT通知在NC訂閱通知源特征的時候就送達了红符。因此青柄，NC在訂閱通知源特征之前需要保持一個可以正確接受并使用這些消息的狀態(tài)。
一段通過通知源特證送達的GATT通知的格式如圖2-1所示预侯。
（圖省略了致开，用[]來表示了）
[EventID 1Byte][EventFlags 1Byte][CategoryID 1Byte][CategoryCount 1Byte][NotificationUID 4Bytes]
一段通過通知源特征送達的GATT通知包含了以下信息：
EventID：這個字段告訴配件發(fā)過來的iOS通知是添加、修改還是刪除萎馅，EventID values這個枚舉值幫助定義這個字段 EventIDNotificationAdded = 0,
EventIDNotificationModified = 1,
EventIDNotificationRemoved = 2,
Reserved EventID values = 3–255
EventFlags：一個用來告知NC這條iOS通知的特殊性.舉個例子双戳，如果一個iOS通知被認為是“重要的”，NC可能需要在供給用戶接口（在UI上展示）來確保這條消息提醒到了用戶.EventFlags這個枚舉幫助定義這個字段
EventFlagSilent = (1 << 0),
EventFlagImportant = (1 << 1),
EventFlagPreExisting = (1 << 2),
EventFlagPositiveAction = (1 << 3),
EventFlagNegativeAction = (1 << 4),
Reserved EventFlags = (1 << 5)–(1 << 7)
CategoryID：一個數(shù)值編成的類別用于對iOS通知分類糜芳，NP盡可能對每一條iOS通知進行精確的分類飒货。CategoryID Values這個枚舉幫助定義這個字段
CategoryIDOther = 0,
CategoryIDIncomingCall = 1,
CategoryIDMissedCall = 2,
CategoryIDVoicemail = 3,
CategoryIDSocial = 4,
CategoryIDSchedule = 5,
CategoryIDEmail = 6,
CategoryIDNews = 7,
CategoryIDHealthAndFitness = 8,
CategoryIDBusinessAndFinance = 9,
CategoryIDLocation = 10,
CategoryIDEntertainment = 11,
Reserved CategoryID values = 12–255
CategoryCount:這個分類當前活躍的iOS通知的個數(shù)魄衅。舉個例子，如果現(xiàn)在用戶的郵箱里有兩條未讀郵件膏斤，這個時候一條新的郵件推送過來了徐绑，那么這個CategoryCount的值將是3。
NotificationUID：一個作為iOS通知的唯一識別符的32位（32-bit）數(shù)莫辨。這個數(shù)可以被用作一個發(fā)送給控制點特征（Control Point characteristic）的命令句柄與iOS通知交互傲茄。
一個iOS通知的生命周期隱約可以通過NP生成的通知源GATT通知的序列推理出來，如下圖
控制點和數(shù)據(jù)源
一個NC可能需要和iOS通知相互作用沮榜，它可能想要獲取更多關于iOS通知的信息盘榨，包括它的內容，或者是想要在通知上執(zhí)行些什么蟆融。這些屬性檢索的執(zhí)行貫穿整個控制點和數(shù)據(jù)源特征草巡。
NC可以通過發(fā)送特定命令給控制點特征用于接受更多關于iOS通知的信息。如果寫成功了型酥，NP會立即作出反應山憨，通過數(shù)據(jù)源特征返回一條GATT通知的數(shù)據(jù)流。
通過寫命令到控制點特征上NC可以在iOS通知上執(zhí)行預設動作弥喉，更多關于行為和iOS通知的信息在 Perform Notification Action(執(zhí)行通知行為).
獲取通知屬性
獲取通知屬性命令允許NC獲得特定iOS通知的屬性郁竟。獲取通知屬性的命令格式如下：
[CommandID 1byte][NotificationUID 4bytes][AttributeID1 1byte][AttributeID2 1byte][Attribute2 max length 2bytes][…]
一條取通知屬性命令包含如下信息：
? CommandID :應該寫0（CommandIDGetNotificationAttributes）
? NotificationUID :32位的數(shù)值表示客戶端想要信息的iOS通知的唯一ID（UID）
? AttributeIDs:NC想要獲取的屬性列表.一些屬性會跟一個16位(2bytes)的參數(shù)指定該屬性的最大字節(jié)數(shù)。
獲取通知屬性命令的返回值（Response）的格式如下：
[CommandID 1byte][NotificationUID 4bytes][AttributeID1 1byte][AttributeID1 length 2bytes][…Attribute1…][AttributeID2 1byte][Attribute2 length 2bytes][…Attribute2…][…]
一條取通知屬性命令的返回值包含如下信息：
? CommandID :應該寫0（CommandIDGetNotificationAttributes）
? NotificationUID :32位的數(shù)值表示這些屬性對應的iOS通知的唯一ID（UID）
? AttributeList:一個(屬性ID/16位長度說明/屬性元組)列表.屬性是一條長度被元組提供的字符串由境，但是不以NULL結尾.如果一條被請求的iOS通知屬性是空的或者丟失了棚亩，它的長度將被置為0.
如果一條返回值長度超過了GATT的長度上限，它將被NP分包處理.NC則必須要重新組包.每條請求的返回值消息完成時都會有完成元組被接收到.
獲取應用屬性（Get App Attributes）
獲取應用屬性的命令允許NC獲取NP上已安裝的制定App的的屬性虏杰。命令格式標準如下：
[CommandID 1byte][…App Identifier…][AttributeID1][AttributeID2][…]
獲取應用屬性的命令包含以下信息：
? CommandID :應該寫1（CommandIDGetAppAttributes）
? AppIdentifier :NC想要獲取信息的對象App的字符串標示.這個字符串必須是Null結尾.
? AttributeIDs:NC想要獲取的屬性列表
獲取應用屬性命令的返回值的格式如下
[CommandID 1byte][…App Identifier…][AttributeID1 1byte][AttributeID1 length 2bytes][…Attribute1…][AttributeID2 1byte][Attribute2 length 2bytes][…Attribute2…][…]
獲取應用屬性命令的返回值包含以下信息：
? CommandID :應該寫1（CommandIDGetAppAttributes）
? NotificationUID :跟隨的屬性對應的App的字符串標示.這個字符串必須是Null結尾.
? AttributeList:一個(屬性ID/16位長度說明/屬性元組)列表.屬性是一條長度被元組提供的字符串讥蟆，但是不以NULL結尾.如果一條被請求的iOS通知屬性是空的或者丟失了，它的長度將被置為0.
和獲取通知屬性的返回值一樣纺阔，如果一條獲取應用通知的返回值長度超過了GATT的長度上限瘸彤，它將被NP分包處理.NC則必須要重新組包.每條請求的返回值消息完成時都會有完成元組被接收到.
執(zhí)行通知行為
這個命令允許客戶端真對特定iOS通知執(zhí)行一條預設任務.一條執(zhí)行通知行為的命令包含以下幾個部分：
Bytes? ? Name? Description
1 ? CommandID 設為2 (CommandIDPerformNotificationAction).
2-5 ? NotificationUID 客戶端想執(zhí)行行為的對應iOS通知的32位（4bytes）唯一ID；
6 ? ActionId NC想在這條iOS通知上執(zhí)行的行為
當這條命令錯誤是數(shù)據(jù)源特征上不會有數(shù)據(jù)產(chǎn)生州弟，不管命令發(fā)送成功或者失敗钧栖。
通知行為
從iOS8.0開始，NP可以通知NC和iOS通知關聯(lián)的潛在行為.出于用戶考慮婆翔，NC可以請求NP完成一個特定iOS通知關聯(lián)的行為.
NC被通知源特特征通過檢索事件標記位的存在來驗證iOS通知上可執(zhí)行行為的需要而生成的GATT通知通知.(The NC is informed of the existence of performable actions on an iOS notification by detecting the presence of set flags in the EventFlags field of the GATT notifications generated by the Notification Source characteristic:
通知源特征? ? ? ? 生成的GATT通知? ? 堅定事件標記位的存在? ? iOS通知上的可執(zhí)行行為的存在? 通知 NC）
? EventFlagPositiveAction: 與iOS通知關聯(lián)的一個正向行為的存在
? EventFlagNegativeAction: 與iOS通知關聯(lián)的一個負向行為的存在
實際上NP代表NC執(zhí)行的行為的不同取決于它依靠的iOS通知類型拯杠。舉個例子，在來電通知里執(zhí)行一條正向行為代表接聽啃奴，執(zhí)行反響行為代表掛斷潭陪。
NC不能假設或預判在iOS通知上行為的準確執(zhí)行，因為這些行為建立在不能被他利用的信息之上，如同NP實現(xiàn)的ANCS版本的其他影響因素一樣依溯。NP保證這些正向或者負向的行為導致的結果不會嚇到用戶老厌。
如果被一條iOS通知提出，正向或負向的行為必須要展示給用戶黎炉，通過核實標記（check marks）枝秤、X marks、感謝和免責的通用顏色（就像綠色和紅色）.
在iOS8.0慷嗜，NC可以檢索標簽來簡潔描述介紹在收到新的iOS通知屬性后的實際行為
?NotificationAttributeIDPositiveActionLabel: 這個標簽用于描述正向的行為
?NotificationAttributeIDNegativeActionLabel: 這個標簽用于描述負向的行為
會話（Sessions）
一個ANCS會話開始于NC通過通知源特征向NP訂閱淀弹，結束于NC在同一特征上取消訂閱或者NC與NP斷開連接。因為ANCS沒有被設計成完整的同時性服務庆械，所以它不保存整個會話的狀態(tài)軌跡.基于此薇溃，NP和NC之間交換的所有標示(例如通知唯一表示和應用標示字符串)和數(shù)據(jù)都只在特定會話內有效。
當一個會話結束時缭乘，NC應該清理掉在這個會話里接受到和保存的所有標示和數(shù)據(jù).當一個新的session開始時沐序，NP盡可能通知NC所有存在與系統(tǒng)的iOS通知.NC可以用這些信息建模以便在接下來的會話中使用.
屬性抓取和緩存（Attribute Fetching and Caching）
強烈建議NC只在需要和可能的用戶行為的返回值時才抓取屬性.舉個例子，NC選擇顯示iOS通知在一個簡單列表里堕绩，并且在用戶選擇時展示特定iOS通知的詳情策幼，那么檢索這些通知屬性的行為就可以被懶加載.
在一個會話里，強烈建議NC為它遇到的每一個App屬性的每一個標示建立緩存.這些緩存可以幫助NC過濾相同App屬性的多次接受—-省時省電.
錯誤碼
在寫控制點特征命令時奴紧，NC可能會收到以下特定錯誤碼:
?Unknown command (0xA0): NP 不承認這個命令
?Invalid command (0xA1): 命令格式不正確
?Invalid parameter (0xA2): 參數(shù)中（eg：the NotificationUID）沒有關系到NP上已存在對象.
?Action failed (0xA3): 這個行為不被允許.
如果NP的回復包含了error垄惧，它就不會在數(shù)據(jù)源特征上生成一條相關命令的GATT通知。
示例圖表
圖表在原文最后绰寞，用兩個例子描述下NP與NC的工作流程。這里就不貼了
