在做 iOS 蓝牙开发时，很多开发者对 Service 和 Characteristic 已经比较熟悉，但对 Descriptor 往往了解不深。提到描述符，很多人第一反应可能只有一个：0x2902，也就是 CCCD，它和 Notify / Indicate 有关。再往下问，Descriptor 到底是什么、Apple 在 CoreBluetooth 中是怎么定义它的、哪些描述符是框架已经内置支持的、它和 CBAttribute 又是什么关系，很多人就说不清了。

实际上，如果认真阅读 CoreBluetooth 的头文件，会发现 Apple 在这一层的设计并不随意。CBDescriptor 并不是一个孤立类，它继承自 CBAttribute；而在 CBUUID.h 中，Apple 又为一批标准 Descriptor 提供了 UUID 字符串常量。把这几部分放在一起看，我们就能更系统地理解：Descriptor 在 BLE 中是什么、在 iOS 中如何表示、它在 CoreBluetooth 的继承关系是怎样的、哪些是系统重点支持的标准描述符，以及它们在实际开发中的意义是什么。

这篇文章就直接从 Apple 的 CoreBluetooth 头文件出发，围绕 Descriptor 这条线，把关键知识点梳理清楚。

---

一、先明确：Descriptor 到底是什么

在 BLE 的 GATT 模型中，整体结构通常是这样的：

• Service
  • Characteristic
    • Descriptor

也就是说，Descriptor 不是一个独立于 Characteristic 存在的一级对象，它是附属于某个 Characteristic 的补充信息或配置项。

如果说：

• Service 用来组织一类功能
• Characteristic 用来承载具体的数据值和访问能力

那么 Descriptor 的作用就是进一步说明这个 Characteristic，例如：

• 这个特征值的人类可读描述是什么
• 这个特征值的数据格式是什么
• 当前是否启用了 Notify / Indicate
• 这个特征值的合法范围是什么

因此，Descriptor 并不是“可有可无的附属字段”，而是 GATT 模型中用于补充语义、格式和配置的重要组成部分。

---

二、为什么在 CoreBluetooth 中要先理解 CBAttribute

如果只看 CBDescriptor，很多人会把它理解成“一个单独的描述符类”。但从 Apple 的框架设计看，事情并不是这样。因为 CBDescriptor 继承自 CBAttribute，所以要真正理解 CBDescriptor，最好先看它的父类。

先看 CBAttribute.h 的定义：

NS_CLASS_AVAILABLE(10_13, 8_0)
CB_EXTERN_CLASS @interface CBAttribute : NSObject

- (instancetype)init NS_UNAVAILABLE;

/*!
 * @property UUID
 *
 * @discussion
 *      The Bluetooth UUID of the attribute.
 *
 */
@property(readonly, nonatomic) CBUUID *UUID;

@end

这段定义虽然不长，但信息量很大。

Apple 抽象出了一个 CBAttribute，它本质上是 CoreBluetooth 里“GATT 属性对象”的公共父类。它至少表达了一个非常核心的事实：

一个 Attribute 的核心标识，就是它的 Bluetooth UUID。

这也是为什么 CBAttribute 对外只暴露了一个最关键的公共属性：UUID。

---

三、如何理解 CBAttribute 这一层抽象

从 BLE / GATT 的角度看，“Attribute”本身就是一个很核心的概念。GATT，全称是 Generic Attribute Profile，其中的“Attribute”并不是随便起的名字，它本来就是协议模型的一部分。

Apple 在 CoreBluetooth 中设计 CBAttribute，本质上是在告诉你：

无论是 Service、Characteristic 还是 Descriptor，它们在某种意义上都可以被视为带有 UUID 的 GATT 属性对象。

所以 CBAttribute 这一层虽然接口很简单，但它的设计意义并不简单。它实际上是在给 CoreBluetooth 的属性体系提供一个共同基类。

你可以这样理解：

• CBAttribute 负责定义“公共身份”
• 这个公共身份就是：我是一个带 UUID 的蓝牙属性对象

而在这个共同身份之上，不同子类再去补充各自特有的信息。

例如：

• Service 有自己的特征集合
• Characteristic 有自己的 properties / value / descriptors
• Descriptor 有自己的 characteristic 归属和 descriptor value

也就是说，CBAttribute 是共性抽象，CBDescriptor 是具体化实现。

---

四、CBAttribute 里最值得注意的两个点

1. UUID 是它唯一公开的核心属性

CBAttribute 只公开了一个只读属性：

@property(readonly, nonatomic) CBUUID *UUID;

这说明在 Apple 看来，Attribute 最基础、最稳定、最应该被抽象出来的公共信息，就是 UUID。

这一点非常合理。因为在 BLE 里，不管你面对的是 Service、Characteristic 还是 Descriptor，你首先都要知道它“是什么”，而“它是什么”在协议层面最直接的标识方式就是 UUID。

所以可以说：

UUID 是 GATT Attribute 的身份标识。

这也是为什么在实际开发中，你总会围绕 UUID 来做判断：

• 这个 Service 是不是我想要的服务
• 这个 Characteristic 是不是我要读写的特征
• 这个 Descriptor 是不是 CCCD

---

2. init 被禁用了

CBAttribute.h 里还有一句很容易被忽略：

- (instancetype)init NS_UNAVAILABLE;

这表示你不能直接初始化一个 CBAttribute 对象。

这背后的含义其实很值得体会：
Apple 并不希望开发者把 CBAttribute 当成一个可以直接实例化使用的普通类，而是把它设计成一个抽象层基类。也就是说，它存在的意义不是让你直接 [[CBAttribute alloc] init]，而是让它的子类继承“UUID 这一公共属性语义”。

从设计上说，这也进一步说明 CBAttribute 更像一个“框架内部和继承体系层面的公共模型”。

---

五、为什么理解 Descriptor，不能绕过 CBAttribute

现在回头看 CBDescriptor，你会发现，理解了 CBAttribute 之后，很多事情就更顺了。

因为 CBDescriptor 不是凭空出现的。它首先是一个 CBAttribute，也就是说：

• 它天然带有一个 UUID
• 它首先是一个“蓝牙属性对象”
• 然后它才进一步表现为“某个 Characteristic 的 Descriptor”

换句话说，CBDescriptor 可以理解成：

在 CBAttribute 这一通用属性模型基础上，增加了 Descriptor 自己的上下文信息和取值语义。

这比单纯把 CBDescriptor 理解成“一个有 value 的对象”要准确得多。

---

六、Apple 在 CBDescriptor.h 中是如何定义 Descriptor 的

先看 CBDescriptor.h 中最核心的一段定义：

/*!
 * @class CBDescriptor
 *
 *  @discussion
 *      Represents a characteristic's descriptor.
 *
 */
NS_CLASS_AVAILABLE(10_7, 5_0)
CB_EXTERN_CLASS @interface CBDescriptor : CBAttribute

这里最关键的一点，就是：

CBDescriptor : CBAttribute

也就是说，CBDescriptor 继承自 CBAttribute。

Apple 的说明也很直接：它表示“一个 characteristic 的 descriptor”。

如果结合前面的 CBAttribute 来看，这句话的完整含义其实是：

CBDescriptor 是一种特殊的蓝牙属性对象，它的角色是作为某个 Characteristic 的描述符存在。

这也说明，Apple 在 CoreBluetooth 中对 Descriptor 的建模，是先放进 GATT Attribute 体系里，再在这个基础上补充其 Descriptor 的特征。

---

七、CBDescriptor 的两个核心属性是什么意思

CBDescriptor 本身对外暴露的属性并不多，主要就是下面两个：

@property(weak, readonly, nonatomic) CBCharacteristic *characteristic;
@property(retain, readonly, nullable) id value;

这两个属性非常关键。

---

1. characteristic

Apple 对它的说明是：

A back-pointer to the characteristic this descriptor belongs to.

也就是：

这是一个反向指针，指向这个 descriptor 所属的 characteristic。

这说明了两个重要事实。

第一，Descriptor 一定是挂在某个 Characteristic 下面的。
第二，当你拿到一个 CBDescriptor 对象时，不仅可以看它自己的 UUID，也可以通过这个属性回到它所属的特征对象。

这里你会发现一个很清晰的结构分工：

• CBAttribute 负责告诉你：“我是谁”，也就是 UUID
• CBDescriptor 再进一步告诉你：“我属于谁”，也就是 characteristic

这种设计其实很漂亮。因为 Descriptor 的意义往往离不开具体的 Characteristic 上下文。

---

2. value

Apple 的说明是：

The value of the descriptor. The corresponding value types for the various descriptors are detailed in CBUUID.h.

也就是说：

Descriptor 的值类型不是固定一种，而是要根据不同的 Descriptor 类型来理解。

这也是 value 为什么直接定义成 id 的原因。因为不同标准 Descriptor 的值语义并不一样，例如：

• 有的更适合解释成 NSNumber
• 有的更适合解释成 NSString
• 有的本质上就是 NSData

这点非常重要，因为它意味着你在做 Descriptor 展示、日志输出、调试工具设计时，不能把所有 Descriptor 的值都当成同一种原始数据去看待。

---

八、把 CBAttribute 和 CBDescriptor 连起来看，会更清楚

如果把这两个类放在一起，你会发现 Apple 的设计逻辑是非常统一的：

CBAttribute

定义公共身份：

• 这是一个蓝牙 Attribute
• 它有一个 UUID

CBDescriptor

在公共身份上增加 Descriptor 语义：

• 它属于某个 Characteristic
• 它有一个具体的 value

所以 CBDescriptor 实际上可以理解成：

“带有 Descriptor 语义的 Attribute 对象”。

从框架设计角度看，这比只记“Descriptor 是特征下面的小项”更有系统性，也更符合 Apple API 的抽象方式。

---

九、为什么理解 Descriptor，不能只看 CBDescriptor.h

如果只看 CBDescriptor.h，你能知道：

• 什么是 CBDescriptor
• 它继承自 CBAttribute
• 它属于哪个 Characteristic
• 它有一个 value
• 创建本地描述符时可以使用 CBMutableDescriptor

但你仍然不知道最关键的一点：

“这个 Descriptor 到底是哪一种标准 Descriptor，它的 UUID 是什么，它的值应该怎么理解？”

这就必须结合 CBUUID.h 来看。

在 CBUUID.h 中，Apple 预定义了一批标准 Descriptor 的 UUID 字符串常量。这些常量的意义非常大，因为它们相当于直接告诉你：

• CoreBluetooth 关注哪些标准 Descriptor
• 这些标准 Descriptor 的语义名称是什么
• 部分 Descriptor 的值应该按什么 Objective-C 类型去理解

所以，要真正理解 CoreBluetooth 中的 Descriptor，最好的方法就是把这几个头文件放在一起看：

• CBAttribute.h 负责定义公共 Attribute 身份
• CBDescriptor.h 负责定义 Descriptor 对象模型
• CBUUID.h 负责定义一批标准 Descriptor 的 UUID 常量及其值语义

---

十、Apple 在 CBUUID.h 中定义了哪些常见 Descriptor UUID 常量

CBUUID.h 中与 Descriptor 相关的常量主要包括：

• CBUUIDCharacteristicExtendedPropertiesString
• CBUUIDCharacteristicUserDescriptionString
• CBUUIDClientCharacteristicConfigurationString
• CBUUIDServerCharacteristicConfigurationString
• CBUUIDCharacteristicFormatString
• CBUUIDCharacteristicAggregateFormatString
• CBUUIDCharacteristicValidRangeString
• CBUUIDCharacteristicObservationScheduleString

这些常量本质上都是标准 GATT Descriptor UUID 的字符串表示。你在实际开发中，通常会结合 CBUUID 来使用，例如：

CBUUID *uuid = [CBUUID UUIDWithString:CBUUIDClientCharacteristicConfigurationString];

这样就可以得到对应的 CBUUID 对象，用于和 descriptor.UUID 进行比较。

---

十一、为什么 Apple 要把这些 Descriptor UUID 写成常量

很多开发者习惯直接记短 UUID，比如：

• 2901
• 2902
• 2904

这样做当然没问题，但 Apple 提供常量有明显的好处。

第一，代码可读性更高

直接写：

[CBUUID UUIDWithString:@"2902"]

是可以工作的，但如果写成：

[CBUUID UUIDWithString:CBUUIDClientCharacteristicConfigurationString]

语义会清楚得多。后者一眼就能看出你要表达的是 CCCD，而不是某个随手写下的神秘数字。

第二，常量名本身就是文档

Apple 的命名把 Descriptor 的用途直接写进了常量名里。即使不查蓝牙规范，仅靠名称也能大致看出它的用途。

第三，Apple 顺便给了值类型提示

更关键的是，这些常量的注释不仅说明“它是什么 Descriptor”，还经常说明“它对应的值通常是什么类型”。这一点对做通用 BLE 工具、调试界面、日志展示非常有参考价值。

---

十二、逐个理解这些常见 Descriptor

下面按 Apple 在 CBUUID.h 中的定义顺序，逐个来看。

---

1. CBUUIDCharacteristicExtendedPropertiesString

它表示的是 Characteristic Extended Properties Descriptor，对应标准 16 位 UUID：0x2900。

这个 Descriptor 用于表达 Characteristic 的扩展属性。从实际项目角度看，它的出现频率没有 CCCD 那么高，但它是 GATT 标准的一部分。

Apple 的注释里说明，这个 Descriptor 对应的值通常是 NSNumber。这很好理解，因为扩展属性本质上更接近一组标志位。

---

2. CBUUIDCharacteristicUserDescriptionString

它表示的是 Characteristic User Description Descriptor，对应标准 16 位 UUID：0x2901。

这个 Descriptor 的作用非常直观：为某个 Characteristic 提供一个用户可读的描述文本。

Apple 在注释中明确指出，它对应的值通常是 NSString。这和它的语义完全一致，因为它本来就是为了给人看的文本说明。

---

3. CBUUIDClientCharacteristicConfigurationString

它表示的是 Client Characteristic Configuration Descriptor，也就是最著名的 CCCD，对应标准 16 位 UUID：0x2902。

这是开发中最重要、最常见的 Descriptor 之一。

它的作用是由客户端配置某个 Characteristic 是否启用：

• Notify
• Indicate

最值得强调的一点是：Characteristic 具备 Notify / Indicate 能力，不等于当前已经启用 Notify / Indicate。

前者是 Characteristic 的 properties，表示能力；
后者则体现为 CCCD 当前的配置状态。

Apple 注释中说明，CCCD 对应的值通常是 NSNumber。

---

4. CBUUIDServerCharacteristicConfigurationString

它表示 Server Characteristic Configuration Descriptor，对应标准 16 位 UUID：0x2903。

相比 CCCD，这个 Descriptor 在日常 BLE App 开发中少见得多。Apple 依然把它的值类型标注为 NSNumber，说明它也属于配置型描述符的一类。

---

5. CBUUIDCharacteristicFormatString

它表示的是 Characteristic Presentation Format Descriptor，对应标准 16 位 UUID：0x2904。

这个 Descriptor 的意义很大，因为它是在告诉客户端：这个 Characteristic 的值应该如何被解释。

例如，它可以描述：

• 数据类型
• 单位
• 缩放指数
• 命名空间

Apple 注释中说明，这个 Descriptor 对应的值通常是 NSData。

---

6. CBUUIDCharacteristicAggregateFormatString

它表示 Characteristic Aggregate Format Descriptor，对应标准 16 位 UUID：0x2905。

这个描述符在一般 BLE 项目中很少见。它主要用于聚合多个 Presentation Format 信息。

---

7. CBUUIDCharacteristicValidRangeString

它表示 Valid Range Descriptor，对应标准 16 位 UUID：0x2906。

顾名思义，它用于表示某个 Characteristic 的合法取值范围，比如最小值和最大值。它的值更像是一段结构化数据，因此通常更适合理解为 NSData 一类内容。

---

8. CBUUIDCharacteristicObservationScheduleString

它表示 Observation Schedule Descriptor。

这个 Descriptor 在普通 BLE App 开发中非常少见，但它被 Apple 作为标准常量保留在 CBUUID.h 中，本身就说明 CoreBluetooth 在 API 设计上对标准 Descriptor 体系是有一定覆盖度的。

---

十三、在 iOS 代码中，如何判断一个 Descriptor 是什么类型

在实际代码里，常见写法是用 descriptor.UUID 和 CBUUID.h 中的常量对应起来。

例如判断是否为 CCCD：

if ([descriptor.UUID isEqual:[CBUUID UUIDWithString:CBUUIDClientCharacteristicConfigurationString]]) {
    NSLog(@"这是 CCCD 描述符");
}

判断是否为用户描述符：

if ([descriptor.UUID isEqual:[CBUUID UUIDWithString:CBUUIDCharacteristicUserDescriptionString]]) {
    NSLog(@"这是用户描述符");
}

这里你也能更深刻体会到 CBAttribute 的意义：
正因为 CBDescriptor 从父类继承了 UUID，所以你才能统一地通过 descriptor.UUID 去做类型判断。

---

十四、CBMutableDescriptor 告诉了我们什么

除了只读的 CBDescriptor，CBDescriptor.h 中还定义了 CBMutableDescriptor：

CB_EXTERN_CLASS @interface CBMutableDescriptor : CBDescriptor

它的作用，Apple 说明得很清楚：

Used to create a local characteristic descriptor, which can be added to the local database via CBPeripheralManager.

也就是说：

CBMutableDescriptor 是用来创建本地外设数据库中的 Descriptor 的。

换句话说，当你使用 CBPeripheralManager 在 iOS 端模拟或构建一个本地 GATT 服务时，如果你想给某个本地 Characteristic 增加 Descriptor，就要用到 CBMutableDescriptor。

---

十五、CBMutableDescriptor 最重要的几个信息

Apple 在注释里还进一步给出了几个非常重要的限制和行为说明。

1. Descriptor 一旦发布，就不能再改

Apple 原文大意是：

Once a descriptor is published, it is cached and can no longer be changed.

这句话很关键。

它说明，通过 CBPeripheralManager 发布到本地 GATT 数据库中的 Descriptor，在发布之后会被缓存，不能再动态修改。

---

2. 不是所有 Descriptor 都允许你手动创建

Apple 继续说明：

only the Characteristic User Description and Characteristic Presentation Format descriptors are currently supported.

也就是说，在 CBMutableDescriptor 里，当前只支持你主动创建两类描述符：

• Characteristic User Description（0x2901）
• Characteristic Presentation Format（0x2904）

---

3. 有些 Descriptor 会自动生成

Apple 还专门说明：

The Characteristic Extended Properties and Client Characteristic Configuration descriptors will be created automatically upon publication of the parent service, depending on the properties of the characteristic itself.

这句话的意思非常重要：

• Characteristic Extended Properties（0x2900）
• Client Characteristic Configuration（0x2902）

这两类描述符会在父 Service 发布时，由系统根据 Characteristic 自身的属性自动创建。

例如，一个 Characteristic 如果支持 Notify 或 Indicate，那么系统就有可能自动为它生成 CCCD；开发者通常不需要自己手动去构造 0x2902。

---

十六、initWithType:value: 应该怎么理解

CBMutableDescriptor 的初始化方法是：

- (instancetype)initWithType:(CBUUID *)UUID value:(nullable id)value;

Apple 对它的说明是：

• 传入 Descriptor 的 UUID
• 传入 Descriptor 的值
• 这个 value 是必需的
• 一旦父 Service 发布后，这个 value 就不能动态更新

这说明 CBMutableDescriptor 的设计思路很明确：
它更适合创建一种发布前确定、发布后固定的描述符内容。

例如，一个用户描述符 0x2901，你可以在创建时给它一个固定字符串：

CBMutableDescriptor *descriptor =
[[CBMutableDescriptor alloc] initWithType:[CBUUID UUIDWithString:CBUUIDCharacteristicUserDescriptionString]
                                    value:@"Temperature"];

但你不能指望它在发布之后像 Characteristic Value 那样频繁动态变化。

---

十七、从 Apple 的定义反推：Descriptor 在 CoreBluetooth 中的几个本质特征

把 CBAttribute.h、CBDescriptor.h 和 CBUUID.h 结合起来看，我们其实可以总结出 Descriptor 在 CoreBluetooth 里的几个本质特征。

第一，它首先是一个 Attribute

也就是说，它首先具备公共身份：有一个 UUID，是 GATT 属性体系中的一个成员。

第二，它一定从属于某个 Characteristic

这不是一个“可能如此”的设计，而是框架层面明确写出来的对象关系。

第三，不同 Descriptor 的值类型并不统一

这也是为什么 value 被设计成 id，而 Apple 又要在 CBUUID.h 里补充说明不同 Descriptor 的推荐值类型。

第四，标准 Descriptor 在 Apple 框架里是有语义映射的

Apple 没有让你只面对一堆冰冷的 2901、2902 编号，而是通过常量名把它们映射成可读的语义名称。

第五，本地 Descriptor 不是完全自由构造的

CoreBluetooth 对 CBMutableDescriptor 支持是有限制的，尤其是：

• 只支持部分标准 Descriptor 主动创建
• 某些关键 Descriptor 会自动生成
• 发布后不能再动态改

这些限制本身就是 API 行为的一部分，实际开发时必须理解清楚。

---

十八、为什么这部分知识值得单独讲一篇文章

很多 BLE 开发者的注意力主要放在：

• 扫描
• 连接
• 发现服务
• 发现特征
• 读写和通知

而 Descriptor 常常被一笔带过，仿佛只是“读出来顺便看看”。

但实际上，Descriptor 正好处在一个非常有价值的位置上：

一方面，它属于 GATT 的标准知识；
另一方面，它又在 CoreBluetooth 中有明确的 API 映射和继承关系。

如果你只懂得“0x2902 是 Notify 相关”，那只能算入门；
如果你能进一步理解：

• CBAttribute 在 CoreBluetooth 中扮演什么角色
• CBDescriptor 为什么继承自 CBAttribute
• Apple 为哪些标准 Descriptor 定义了常量
• 不同 Descriptor 的 value 应按什么类型理解
• 哪些本地 Descriptor 可以手动创建，哪些会自动生成

那你对 GATT 和 CoreBluetooth 的理解就会明显更扎实。

---

十九、总结

在 CoreBluetooth 中，Descriptor 不是边缘知识，而是 Characteristic 语义和配置的重要补充层。

如果从 Apple 的头文件设计来看，要真正把 Descriptor 理解透，至少要同时看三部分：

• CBAttribute.h
• CBDescriptor.h
• CBUUID.h

其中：

CBAttribute 定义了 Attribute 的公共身份，也就是“这是一个带 Bluetooth UUID 的属性对象”；
CBDescriptor 在这个基础上，进一步表达“这是某个 Characteristic 的 Descriptor，并且它有一个值”；
CBUUID.h 则为一批标准 Descriptor 提供了 UUID 常量和类型说明，让你知道这些 Descriptor 在语义上分别是什么。

通过这套设计，Apple 实际上把 BLE 的 GATT 模型较为清晰地映射到了 CoreBluetooth 中。

其中，最值得重点掌握的仍然是 CCCD，也就是 0x2902，因为它直接关联 Notify / Indicate 的启用状态；而从框架设计角度看，CBAttribute 这层公共抽象同样值得注意，因为它帮助我们从更高一层去理解：Descriptor 并不是零散的特殊对象，而是整个 GATT Attribute 体系中的一部分。

如果你希望自己对 iOS 蓝牙开发的理解不只停留在“会调接口”的层面，而是真正理解 Apple 是如何把 BLE 的 GATT 模型映射到 CoreBluetooth 中的，那么 Descriptor 这一层，值得认真吃透。