文章出處：可不可以不取名（轉載文章，如有不妥，通知後我會立即删除）
1 ANCS綜述
ANCS即 Apple Notification Center Service。是IOS系統中的一個通知服務。裝置連接配接手機後，裝置首先需要先使能IOS系統的通知功能，具體即裝置上的GATT 用戶端發現IOS上的ANCS，并且使能其 通知源Characteristics 的notify功能。 之後IOS系統就會通過ble 推送消息給裝置了。
通常推送的消息僅僅是一個簡短通知，比如通知有一個社交消息。如果需要擷取詳細消息，還需要 裝置通過 控制點 Characteristics 主動發送控制指令給 ANCS服務，讓其傳回詳細資訊。傳回的詳細資訊通過一個資料源Characteristics來傳回。是以連接配接上服務後除了使能通知源Characteristics的notify功能，還需要使能 資料源Characteristics的notify功能，因為可能需要通過資料源來擷取通知的詳細資訊。
如下圖所示：NC（通知消費者）連接配接NP（通知提供者）上後發現服務，然後 訂閱(使能通知功能) 通知源和資料源，之後如果NP有消息就會 通過 通知源 通知NC了。
綜上，ANCS是一個服務，
其服務UUID是特定的為7905F431-B5CE-4E99-A40F-4B1E122D00D0
該服務會主動推送一些 通知消息給 裝置，是以有一個具有notify功能的Characteristics。
該特性稱為Notification Source.
（注意這裡 notify指的是Characteristics的發送消息方式， 而notification source僅僅是一個稱謂，就是字面意思，表示這個Characteristics的目的是為了推送一些通知，是以稱為通知源）
通過notification source發送過來的通知僅僅是簡短的消息。如果希望擷取更消息的消息則需要 裝置主動發送控制指令給手機上的ANCS，是以該服務還有一個具有寫功能的Characteristics，這樣就可以通過這個Characteristics來發送控制指令給ANCS服務。這個特性稱為Control Point
發送控制消息後 ANCS服務會傳回更詳細的消息。這個消息不會再通過notification source這個Characteristics，而是用過另一個具有 notify功能的Characteristics來傳回，該特性稱為Data Source。
綜上ANCS服務至少有3個特性。其UUID如下：
· Notification Source: UUID 9FBF120D-6301-42D9-8C58-25E699A21DBD (notifiable)
· Control Point: UUID 69D1D8F3-45E1-49A8-9821-9BBDFDAAD9D9 (writeable with response)
· Data Source: UUID 22EAC6E9-24D6-4BB5-BE44-B36ACE7C7BFB (notifiable)
即 :notify source 這個Characteristics 是NP用來發送通知給NC的，
Control point這個Characteristics 是NC用來發送控制指令給NP的，如擷取通知詳細資訊。
Data source這個Characteristics 是NP收到NC擷取詳細資訊指令後傳回通知的詳細資訊
下面分别介紹三個Characteristics 中(也可以認為是三個資料通道)傳輸的資料的 内容和格式
2 notify source ：通知源
NP發送通知給NC的通道。其上發送的資料格式如下：
2.1 EventID:
表示這個通知是 added, modified， removed 三種中的哪種。
如果手機收到一個qq消息，則手機（NP）發給一個 added的通知給 裝置( NC )。
如果使用者在手機通知欄上滑動清除了這通知，則手機(NP)就會發送一個removed的通知給裝置(NC)
Modified類型的具體還沒碰到
2.2 EventFlags：
每個位有特殊的意義，用來訓示這個通知的一些特性
| EventFlagSilent | = (1 << 1), |
| EventFlagPreExisting | = (1 << 3), |
| EventFlagNegativeAction | Reserved= (1 << 5)–(1 << 7) |
2.2.1 Slient标記：
沒搞清幹嗎用的。
2.2.2 Important标記:
表示通知重要，比如手機有來電時，推送給NC的通知其flag的important就會被置位，表示通知重要。
2.2.3 PreExisting标記:
表示消息是之前就存在，比如手機連接配接裝置後，再斷開裝置，然後重新連接配接，則連接配接上後手機(NP)會發送一些 斷開前就有的沒處理的手機上的通知，這些通知的preExisting位就會被置位。
2.2.4 PositiveAction，NegativeAction标記:
稱積極動作和消極動作吧，和每個具體通知有關， 比如手機收到 來電，則就會發送 來電通知給 裝置，這個通知就通知具有這兩個 标記，積極動作表示 接電話，而消極動作表示拒接電話。
再如，手機收到qq消息，則手機發送 通知給 裝置，這個通知就隻有 negativeaction标記。
PositiveAction,NegativeAction 這兩個标記僅僅表示 這個”通知”具有一些預定義的動作，比如 電話通知的 接聽和 拒接。 具體是否執行，則需要 通過控制通道發送 控制指令 執行 積極動作或者消極動作。
也就是 這兩個标記僅僅表示 這個通知具有某個預定義的對這個通知的特殊處理，至于執不執行則要看 裝置(NC) 是否發送執行PositiveAction 或NegativeAction的指令 後面 對控制通道的描述會有說明。
2.3 CategoryID:
用來分類通知類型的
| CategoryIDOther | = 1, |
| CategoryIDMissedCall | = 3, |
| CategoryIDSocial | = 5, |
| CategoryIDEmail | = 7, |
| CategoryIDHealthAndFitness | = 9, |
| CategoryIDLocation | = 11, |
| CategoryIDvalues | = 0, |
| NotificationAttributeIDTitle | = 2, (Needs to be followed by a 2-bytes max length parameter) |
| NotificationAttributeIDMessage | = 4, |
| NotificationAttributeIDDate | = 6, |
| NotificationAttributeIDNegativeActionLabel | Reserved = 8–255 |
AppIdentifier該attribute表示發送這個通知App的辨別。比qq消息的app id就是com.tencent.mqq
Title 該attribute表示通知的标題，qq消息的标題就是QQ
Subtitle為子标題，通常為空。Message就是資訊内容，MessageSize為資訊大小，
Date為通知發出的時間(不是傳回詳細資訊的時間，是 之前通知的發出時間)，
PositiveActionLabel和NegativeActionLabel即描述 積極動作和消極動作具體是什麼。 來電通知其積極動作和消極動作通常就是 接聽和拒接。
具體過程如， 當手機qq收到一條qq消息時， 手機就會在 通知源通道上 推送一條 Social類型的通知給 裝置，裝置收到後 可以在 控制點通道上發送一條擷取該通知詳細指令，之後手機再通過 資料源通道傳回其詳細資訊。
3.1 擷取通知的詳細資訊的指令格式和 響應資料格式
既然通知的詳細資訊是由一個個 attribute組成，那麼我們擷取詳細資訊的時候就可以自己指定 擷取 這個 通知的 哪些attribute。是以擷取通知詳細指令的格式如下：
3.1.1 CommandID：
擷取通知詳細資訊的 指令ID為0
3.1.2 NotificationUID：
用來具體辨別要擷取哪個通知的詳細消息，這個值就是用 通知源通道中收到的通知的NotificationUID字段。
3.1.3 AttributeID n：
這些字段即指定想擷取這個通知的哪些詳細資訊，一些attributeID之後需要跟2位元組的max length表示 裝置(NC)期望擷取這個通知該特性資訊的最大長度。具體哪些attribute需要跟2位元組max length在前面的attributes表中有說明。
擷取通知attributes（即擷取通知詳細資訊）在 控制點通道上發出以後，NP(手機)就會在 資料源通道傳回這些 attributes的值。即通知的一些具體資訊。傳回的響應資料格式如下：
CommandID同樣還是0，表示該響應是擷取通知attributes的響應，
NotificationUID 與 指令中的NotificationUID對應，用來表示傳回的這些attributes的值是 對應哪個 通知的。
随後就是 具體的attributes的值了， 均由3字段組成，分别表示attribute,其值長度，具體值。
3 . 2 擷取手機上産生本條通知的APP的資訊
如何擷取 産生這個通知的app的消息？ 裝置收到的通知實際是 手機發送過來的，而手機之是以發送這個通知給裝置時因為 手機中的一些應用産生了一些消息。
比如，手機上的qq産生了一條消息，則手機通知欄上就會産生這個通知，同時也會推送一條 Social類型的通知給 連接配接的裝置。
是以 裝置端 想擷取 産生這個通知的APP的一些資訊，首先應該 擷取 該通知由哪個app産生的，然後才能查詢該app的消息。
前面提到，收到通知後，一般需要再 在控制通道上發送擷取通信詳細資訊的指令來擷取到 該通知相關的一些更具體的資訊， 而擷取詳細資訊實際就是擷取這個通知的 一些 attributes 的具體的值。
其中就有一個 attribute用來辨別 是由哪個 app 産生的這個通知，即NotificationAttributeIDAppIdentifier。
是以受到通知後首先 需要使用 擷取通知attributes的指令來擷取其NotificationAttributeIDAppIdentifier的具體值，這個就知道了産生這個 通知的app的辨別。
之後再通過 擷取 app資訊指令來擷取 産生這個通知的app的資訊，指令格式如下
CommandID：為1，辨別擷取 app的相關資訊指令。
App Identifier: 用來訓示擷取哪個app資訊。就是擷取通知詳細資訊中傳回的NotificationAttributeIDAppIdentifier的值。
Attributes: 擷取通知的詳細資訊 就是擷取通知一些attributes的值，同樣擷取APP詳細資訊 也就是 擷取 APP的一些attributes。
目前：app相關的 attributes隻有一個，即其名字。
| AppAttributeIDDisplayName | Reserved = 1–255 |
同樣 擷取 app詳細資訊的傳回也是通過 資料源通道傳回。
CommandID：為1，辨別擷取 app的相關資訊指令的響應。
App Identifier: 與指令中的app id對應，用來訓示擷取哪個app資訊。
随後就是具體的各個 attributes的值。
如下圖是 收到qq消息的通知後，擷取其詳細資訊，并通過 app id這個attribute來擷取 app的消息
3.3 執行通知預定義動作
通知源部分有 提到一些通知具有一些預定義的執行動作，通過 通知的EventFlags 字段來訓示這個通知是否 有預定義的 積極動作或消極動作。來電通知就有 接聽/拒聽的 積極動作/消極動作。
是以如果收到 來電通知時， 即 通知CategoryID字段為CategoryIDIncomingCall 時，如果接聽，就可以讓裝置 在控制點 通道上發送 執行積極動作的指令， 同理如果拒接，就在 控制點通道 上發送執行消極動作的指令。
執行預定義指令格式如下