问题描述
根据 BLE GATT 配置文件的规范，特征是可以在 GATT 服务器或客户端之间交换的最小数据单位。 GATT 客户端可以请求读取或写入 GATT 服务器上服务下的特性值。但是在迄今为止我看到的大多数 GATT 实现（Windows 和 Android）中，都有针对服务器端特征的事件处理程序，用于诸如 ReadRequested 或 WriteRequested 事件之类的事件，这些事件在客户端请求读取或写入时触发那个特征。在事件处理程序中，我们可以随心所欲地发送响应（特征不包含除 UUID 或其属性之外的任何数据）。在写入请求的情况下，服务器从客户端接收数据并选择用它做任何它想做的事情，特性永远不会改变。这些特征在技术上没有被读取或写入。我的问题是为什么不使用读取或写入特征的原始概念？
PS：这里我附上了如何在 UWP 应用程序中创建 GATT Server 和 Client 的链接。
服务器：https://docs.microsoft.com/en-us/windows/uwp/devices-sensors/gatt-server
客户：https://docs.microsoft.com/en-us/windows/uwp/devices-sensors/gatt-client
解决方法
这只是术语。如果您认为这样更好，您可以将其称为“接收”/“发送”给自己，而不是“读取”/“写入”。
最初的想法是将值附加到特征上，并由客户端直接读取/写入。或者由服务器更新，然后向客户端发送包含新值的“通知”（例如温度传感器）。
但是对于所有配置文件来说，这个模型是不够的。例如，固件更新不适合此模型。 HID 也不行。因此，允许仅使用特征作为传输数据的一种方式。由每个配置文件定义如何处理特征的读取和写入。例如，GAP 服务中的“名称”和“外观”特征通常返回一个常量值，该值可能存储在特征对象中。但是对于 HID，我们具有“控制点”特征，其中值实际上并不存储在任何地方。
我已经看到这些 API 变体用于定义不同蓝牙堆栈的特征：
- 将特征值嵌入到特征对象中，让蓝牙堆栈在内部处理读/写。
- 不要嵌入任何特征值，而是公开读/写处理程序。
- 在特征对象中为值保留一些空间，但具有读/写处理程序，可以在从存储写入/读取特征值之前/之后处理数据。
选项 2 是最灵活的，例如与 Android 的应用实现的 gatt 服务一起使用。