iOS BLE 开发小记[1] - CoreBluetooth 是什么

现在我们都知道，很多智能硬件设备都已经集成了低功耗蓝牙模块，这样我们就可以开发一个 iOS 或者 Mac APP 与它们进行交互。从 macOS 109 和 iOS 6 以后，Mac 和 iOS 设备就支持 低功耗蓝牙技术了，我们可以通过 CoreBluetooth 这个框架与底层的各种蓝牙协议栈进行交互，比如 GATT、ATT 和 L2CAP 等。

与底层交互的过程如下图所示：

开始下文之前，我们需要了解几个概念。对蓝牙不够了解的可以看一下维基百科关于 蓝牙 的简介。

Bluetooth 40 : 蓝牙 40 是 Bluetooth SIG 于2010年7月7日推出的新的规范，其最重要的特性是功耗低，省电！

BLE : Bluetooth low energy wireless technology,也就是低功耗无线蓝牙技术。

BLE 是关于蓝牙40 的详细说明，它定义了一套用于低功耗设备之间通信的协议。而CoreBluetooth 则是对 BLE 协议栈的抽象。也就是说，它隐藏了许多底层的详细实现细节，这样对我们开发者来说，开发一个 APP 与 BLE 设备进行交互将会很便捷。

CoreBluetooth 中最关键的两个角色就是 Central(中心) 和 Peripheral（周边）, Peripheral 一般是提供数据的一方，而 Central 一般获取 Peripheral 提供的数据然后来完成特定的任务。举个例子，一个集成 BLE 的数字室温计可能提供房间中的实时温度，我们通过 APP 就可以读取、分析和显示房间中的温度。

Peripheral 通过向空中广播数据的方式来使我们能感知到它的存在。Central 通过扫描搜索来发现周围正在广播数据的 Peripheral, 找到指定的 Peripheral 后，发送连接请求进行连接，连接成功后则与 Peripheral 进行一些数据交互， Peripheral 则会通过合适的方式对 Central 进行响应。

CoreBluetooth 对通用的蓝牙任务进行了简化处理，你在 App 中通过 CoreBluetooth 来集成 BLE 功能将会变得简单，如果你开发的 APP 遵循了 Centrals 的开发规范，CoreBluetooth 将会帮你处理与 Peripheral 的扫描、连接以及数据交互的过程，除此之外，通过 CoreBluetooth 将你的设备设置为 本地 Peripheral 也会很便捷。

iOS APP 的状态也会影响蓝牙的行为，当你的 APP 在后台运行或者处于暂停状态中，蓝牙的行为将会受到影响。默认情况下，当你的 APP 在后台运行时或者处于暂停状态中，你的 APP 是不能与 BLE 进行数据通信的，也就是说，当 APP 后台运行时，你需要与 BLE 进行数据通信，你需要声明你的 APP 支持蓝牙后台运行模式，即使你声明了支持后台运行模式，蓝牙在后台运行模式下的数据处理方式也会变得不同，当开发你的 BLE APP 时，你需要注意这些不同点。

即使 APP 在后台运行时，当系统内存过低时也会杀掉 APP 的后台进程，对于 iOS 7，CoreBluetooth 支持 Central 和 Peripheral 的状态信息的保存和恢复。可以通过这个功能来实现与 BLE 设备的长期交互。

CoreBluetooth 框架为你的 APP 与许多常见的 BLE 设备进行交互提供了交互接口，通过合理的利用和实践将会提高用户的体验。

举个例子，当你实现 Central 或 Peripheral 的功能时，会利用设备携带的无线电广播设备（Radio）向空中广播信号，这样就会影响到电池的续航时间，因此当你设计 APP 时，需要尽可能的减少 Radio 的使用频率。

重要提醒： 在 iOS 10以后，通过 CoreBluetooth 与 BLE 设备进行数据通信时，必须在项目的 Infoplist 文件中包含关于 NSBluetoothPerpheralUsageDescription 的描述,否则会导致 APP 闪退，详情见 NSBluetoothPerpheralUsageDescription 。

在 BLE 通信中主要包含两种角色：Central（中心）和 Peripheral（周边），基于传统的客户-服务器架构，Peripheral 通常会提供其他设备需要的数据，Central 通常利用通过 Peripheral 获取的信息来完成特定的任务，如图所示，心率监视器 提供数据给 Mac 或 iOS APP，然后来显示用户的心率数据。

Peripheral 以广播数据包的形式广播服务中的数据，广播数据包指的是包含 Peripheral 有用信息的一个较小数据包，比如 Peripheral 的名字和主要功能数据。比如，一个数字室温计广播的数据中可能包括当前室温，对于 BLE，广播是显示它们存在的主要方式。

如图，对于一个 Central 来说，它能够搜索和获取到它想要的 Peripheral 的广播信息。

连接 Peripheral 的目的就是和 Peripheral 提供的数据进行交互，在你理解这一点后，可以更好的明白 Peripheral 的数据组成结构。

Peripheral 包含一个或多个 Service(服务)和连接信号强度的有用信息。Service 可以理解成是一个完成指定功能的数据集合。举个例子，一个心率监测服务的功能就是可能就是从心率传感器中读取心率数据。

Service 是由 Characteristic（特征） 组成的，Characteristic 为 Peripheral 的 Service 提供更详细的信息，举个例子，心率服务可能包含一个测量不同体位的心率数据的 Characteristic 和一个传输心率数据的 Characteristic，下图所示的是一个心率监测设备的数据组成结构。

当 Central 与 Peripheral 建立成功的连接后，Central 可以发现 Peripheral 提供的全系列的 Service 和 Characteristic，广播数据包中的数据仅仅是可用服务的一小部分而已。

Central 可以通过读取或写入 Service Characteristic 值的方式与 Service 进行交互。你的 APP 也许需要从数字室温计中获取当前室内的温度或者设置一个温度值到数字室温计中。

BLE 通信过程中涉及到的主要角色和数据处理已经简单的集成到 CoreBluetooth 框架中了。

当你通过本地 Central 与周边 Peripheral 进行交互时，你只需要调用 Central 方面的方法就可以了，除非你设置一个本地 Peripheral，并用它来响应其他的 Central 的交互请求，实际运用中，你的蓝牙处理大部分会在 Central 方面。

在 Central 方面，用 CBCentralManager 对象来表示一个Local Central 设备，这个对象被用来管理 Remote Peripheral 设备（用 CBPeripheral 对象来表示），包括搜索和连接正在广播数据的 Peripheral。如图所示的是 CoreBluetooth 框架中如何表示 Local Central 和 Remote Peripheral。

当你与 Remote Peripheral 进行数据交互时，你将处理它的 Service 和 Characteristic，在 CoreBluetooth 框架中，用 CBService 对象来表示 Peripheral 中的服务，同样地，用 CBCharacteristic 对象来表示 Service 中的特征。下图所示的是 Remote Peripheral 的服务特征结构树。

对于 macOS 109 和 iOS 6， Mac 和 iOS 设备可以实现 BLE Peripheral 的功能，如为其他设备（包括 Mac，iPhone，和 iPad）提供数据。当你遵循 Peripheral 的开发规范时，就可以调用 BLE 通信的 Peripheral 方面的方法。

在 Peripheral 方面，一个 Local Peripheral 可以用 CBPeripheralManager 对象来表示，这个对象被用来管理发布包含的服务，包括组织构建 Peripheral 的数据结构以及向中心设备广播数据，Peripheral Manager 也对 Remote Central的读写交互请求做出响应。如图所示的是一个 Local Peripheral 和 Remote Central。

当你设置并与 Local Peripheral 进行数据交互时，你处理的是它的可变的 Service 和 Characteristic，在 CoreBluetooth 框架中，用 CBMutableService 对象来表示 Local Peripheral 中的服务，同样地，用 CBMutableCharacteristic 对象来表示Local Peripheral 服务中的特征。下图表示的是一个 Local Peripheral 中的服务特征结构树。

后续章节会进一步补充关于 BLE 开发的知识。

1、 TP40013257-CH1-SW1

2、 CoreBluetoothOverview

欢迎在本文下面留言一起交流心得

这篇文章将包含以下几个主题：

1BLE的实际吞吐量是多少？

2蓝牙5的新2M PHY用于数据传输

3影响/确定数据吞吐量的因素有哪些？

4如何计算应用程序中的数据吞吐量？

5如何最大化数据吞吐量？

蓝牙5定义的 LE 2M PHY以及蓝牙4x协议 LE 1M PHY都称为未编码PHY，因为它们每位数据使用1个符号表示（与使用S=2或S=8的新LE编码PHY相比）。

我们需要明白各大芯片厂商数据手册宣传的速度（1 Mbps和新的2 Mbps）仅仅只是理论值(空中速率)，并且在应用程序中吞吐量会被削减。原因有多种，我们将在下面一一介绍。

蓝牙5“2x速度”需要硬件支持，因此老的设备/芯片/模块将不支持蓝牙5 2M PHY（市面已经有手机支持蓝牙5 2M PHY）。要注意，为了实现更高吞吐量，需要两个BLE设备相互都支持LE 2M PHY。

另一个需要明确的是，当使用更高速度的PHY时，实际上功耗可以做的更低（传输相同数量的数据，时间短功耗低）。这是因为减少了芯片工作时间而又没有增加发射功率。反过来这样做改善了与24 GHz频谱内的其他无线技术的共存（也是由于减少了无线电工作时间，减少2,4G带宽的占用）。

为什么不可能达到BLE的理论速度？

1 Mbps（LE 1M PHY），2 Mbps（LE 2M PHY），125 kbps和500 kbps（均使用LE编码PHY，S = 8和S = 2）的数据速率是无线电在空中的速率传输数据，但由于以下原因，应用程序吞吐量是达不到该理论值：

1蓝牙规范限制每个连接间隔的数据包数量

2数据包之间的帧间间隔（IFS）延迟（150 us）

3即使没有可用于传输的数据，也需要从设备发送空数据包

4数据包开销 - 并非数据包中的所有字节都用于有效负载

为了更好地理解这些因素并了解影响应用程序吞吐量的因素，我们必须深入了解数据包格式。 下图显示了LE 1M PHY和2M PHY数据包的外观：

我们感兴趣的部分（真正定义应用程序数据的部分）是ATT Payload。 从图中可以看出，蓝牙低功耗中的每一层都使用了许多额外开销字节。

在40和41中，最大ATT有效载荷为20个字节。

在42和50中，称为数据长度扩展（DLE）的新功能允许ATT有效载荷最多可容纳244个字节的数据。

蓝牙5速：使用新的2M PHY实现2倍速

首先了解下蓝牙5中使用新LE 2M PHY的局限性：

1不能用于主要广播信道（37，38，39）。

2可用于与数据包在同一通道上发送的辅助“辅助数据包”（37个通道：0-36）。

要了解有关主要和次要广告的更多信息，请参阅我之前的文章细说BLUETOOTH 5 2X 数据吞吐量

蓝牙5规格书有说明，LE 1M PHY是强制性的，而LE 2M PHY是可选的，因此，并非所有声称支持蓝牙5的芯片都必须能够处理更高的吞吐量。

LE 2M PHY上可以发生从端广播模式和主端扫描模式，然后使用LE 2M PHY在第二广告信道上进行连接。

用户交互数据从一个设备传输到另一个设备是发生在两个设备的连接阶段。连接的设备可以通过更新PHY来协商使用不同PHY。它可以在建立连接后由从设备或主设备发起，但主设备最终将决定哪个PHY（基于从设备的请求和主设备支持的PHY）。

下面一些因素会影响BLE应用程序的数据吞吐量：

1使用的PHY（LE 1M vs LE 2M与LE编码（S = 2或S = 8））

2连接间隔

3每个连接间隔的最大数据包数

4ATT最大传输单元（ATT MTU）

5数据长度扩展（DLE）

6 *** 作类型：写入响应与写入无响应，指示与通知

7帧间间隔（IFS）：后续数据包之间的时间间隔（150 us）

8传输空包

9数据包开销 - 并非数据包中的所有字节都用于应用程序有效负载

根据这9点，我们一点一点详细地讨论。

PHY

蓝牙5中基本上有三种PHY：原始的1 Mbps PHY，新的2 Mbps和编码的PHY（S = 2或S = 8）。所使用的PHY将直接影响您可以实现的最大数据吞吐量，因为它确定了通过无线方式发送数据包的实际原始数据速率。

每个连接事件的连接间隔和最大数据包

连接间隔有效地确定在一个连接事件期间可以发送多少数据包。值越高，在一个连接事件中可以发送的数据包越多（某些设备达到某个限制）。

BLE连接间隔和事件

每个连接事件的数据包数量取决于设备和BLE堆栈，因此它受到限制，并且在特定设备上的设备和堆栈版本之间有所不同。此值还取决于设备的 *** 作，因此无线电可能必须处理其他事件，并且每个连接事件发送的数据包数量可能达不到堆栈允许的最大值。例如，iOS和Android之间的数量不同，也会根据设备上运行的 *** 作系统版本而有所不同。

数据长度扩展（DLE）

此功能允许数据包大小保持更大的有效负载（最多251个字节，而禁用时为27个字节）。此功能是在蓝牙规范42版中引入的。

ATT最大传输单元（ATT MTU）

ATT MTU确定发送器和接收器可以处理的最大数据量以及它们可以保存在缓冲器中的数据量。

MTU值影响开销数据量（特别是3个字节的ATT头）。允许的最小ATT MTU是27个字节。这允许最多20个字节的ATT有效载荷（3个字节用于ATT报头，4个字节用于L2CAP报头）。

对于MTU值有多高，每个规范没有限制，但使用中的特定堆栈可能有其自身的局限性。例如，如果启用DLE，则最多可以传输251 - 4 = 247个字节（扣除L2CAP标头大小后）。在考虑ATT报头（3个字节）之后，我们留下了244个字节用于实际的ATT有效载荷数据。如果MTU至少为247字节，则MTU将适合一个单独的数据包。如果MTU大于247字节，则MTU将跨越多个分组，导致吞吐量下降（由于分组开销和分组之间的定时）。

有效MTU由客户端和服务器支持的ATT MTU的最小值确定。例如，如果客户端支持100字节的ATT MTU并且服务器响应它支持150字节的ATT MTU，则客户端将决定用于从其上进行连接的ATT MTU是100字节。

*** 作类型：写入响应与写入无响应，指示与通知

如果需要高吞吐量，那么我们可以使用Write without response或Notifications将数据从客户端传输到服务器以及从服务器传输到客户端。这些 *** 作不需要其他设备确认收到数据并在下一个数据块发送之前做出响应。

帧间间隔（IFS）：连续数据包之间的时间延迟（150 us）

从蓝牙规范：

传输空包

如果接收数据的设备没有要发回的数据，则仍需要按照蓝牙规范发送空数据包。

数据包开销

正如我们在数据包格式图中看到的那样，数据包包含一些不计入应用程序数据（ATT数据）的开销数据。基本上，这些字节将消耗部分传输数据速率，而不考虑作为应用程序数据的一部分发送的任何字节。

计算应用程序数据吞吐量

敲黑板，画重点，正如我们之前提到的，有如下些因数会影响数据吞吐量：

1使用蓝牙版本和PHY

2DLE：数据长度扩展 - 启用与否

3ATT MTU值

4连接间隔

5每个连接事件的最大数据包数

6 *** 作（写入响应与写入没有响应，以及通知与指示）

7帧间间隔（IFS）：150微秒

蓝牙版本和PHY确定原始数据传输速率。例如，如果我们使用蓝牙版本42和LE 1M PHY，则传输速率为1 Mbps。另一方面，如果我们使用蓝牙5 S = 8的 LE编码PHY，则数据速率降至125 kbps。

DLE，ATT MTU，连接间隔，每个连接间隔的最大数据包数， *** 作和IFS都是用于实际数据传输时间。

数据包格式在传输的数据量是实际应用程序数据方面起着重要作用。 LE 1M PHY和LE 2M PHY都具有类似的数据包格式。 LE编码PHY具有明显不同的数据包格式，因此我们将分别查看这两种情况。

LE 1M PHY和LE 2M PHY计算

返回参考LE未编码PHY的数据包格式：

针对不同PHY，数据开销略有不同。 对于1M PHY，前导码是1字节，而对于2M PHY，前导码是2字节。 MIC字段是可选字段，仅用于加密连接。 为简单起见，我们只考虑未加密的连接 - 对于加密的情况，它只是增加了4个字节的开销。

对于LE编码PHY，数据包格式如下所示（来自蓝牙50规范第6卷，第B部分，第22节）：

计算吞吐量的步骤（以Mbps为单位）：

为简单起见，我们做假设如下：

1未启用加密（数据包中不包含MIC字段）。

2我们感兴趣的是单方向的吞吐量（例如Master to Slave），所以我们假设另一个方向只传输空数据包。

3写入时，对方无需响应（No Ack）。

步骤：

确定正在使用的PHY并记下原始数据传输速率

例如。 对于1M PHY - > 1 Mbps，对于编码PHY和S = 8 - > 125 kbps

确定从接收器发送一个数据包和空包的时间。

可以发送一个数据包的时间包括以下内容：

Data_Packet_Time =发送空包的时间+ IFS +发送实际数据包+ IFS的时间。

空包传输时间可以如下计算：传输空包的时间=空包大小/原始数据速率

空包将包含以下字段：前导 + 访问地址(access address)+ LL头+ CRC。

对于1M PHY，前导将为1字节，因此空包的总大小= 1 + 4 + 2 + 3字节= 10字节=80位。

（对于2M PHY，空数据包的大小将为88位，因为Premable是2个字节而不是1个字节）。基于此，传输空1M PHY数据包的时间将是：

传输空数据包的时间=空数据包大小/原始数据速率= 80位/ 1兆位/秒= 80微秒数据包将包含数据包格式图中列出的所有字段，但MIC字段除外（加密禁用）。传输数据包的时间=数据包size / raw data rate如果我们启用了DLE并且ATT MTU等于一个数据包中允许的最大字节数：247个字节，那么我们可以将数据包大小计算为：

数据包大小= 1 + 4 + 2 + 4 + 247 + 3字节= 265字节= 265 8位= 2088 bit

发送数据包的时间= 2088位/ 1 Mbps = 2,088us

Data_Packet_Time =发送空包的时间+ IFS +发送实际数据包的时间+ IFS = 80 + 2 150 + 2088 = 2,468us

为了比较，在2M PHY的情况下，它将是：

Data_Packet_Time =发送空包的时间+ IFS +发送实际数据包的时间+ IFS = 88/2 + 2 150 +（2 + 4 + 2 + 4 + 247 + 3） 8/2 = 1,392us

当启用DLE并且ATT MTU设置为小于247时，会产生更多开销（因为现在大于ATT MTU的数据被分成更多数据包）。例如，假设我们将ATT MTU设置为158，那么为了传输244个字节的应用程序数据，我们需要两个数据包而不是一个，导致吞吐量因字节开销增加而增加而增加数据包之间的IFS。

在另一种情况下，我们可以禁用DLE（有效负载大小最多27个字节）和ATT MTU大于27个字节。在这里，这也将导致需要为相同数量的数据发送更多数据包，从而导致吞吐量下降。

注意：用于计算上面使用的数据和空数据包大小的方法可以用于计算LE编码PHY。

确定在一个连接间隔期间可以传输多少数据包

前一篇文章讲过，这种计算并不总是纯粹的数学计算 - 需要考虑使用的堆栈和设备的限制。在蓝牙芯片供应商的SDK中，通常在其文档中会列出最大值。iOS和Android的最大值随 *** 作系统版本而变化，所以要弄清楚并不容易。

一旦计算出最大值，就可以计算出适合所选连接间隔的最大理论数据包数。例如，如果我们的连接间隔为75毫秒（规范允许的最低值），则对于上面的示例（使用1M PHY，启用DLE）：

每个连接间隔的最大数据包数= [连接间隔/ Data_Packet_Time]，其中[]舍入到最大整数（整数）。

每个连接间隔的最大数据包数= [75 1,000微秒/ 2,468微秒] = 3个数据包

通常，这个数字是不现实的，因为在连续的连接事件上发送的数据包之间存在时间延迟。因此，对于我们的示例，我们将使用2个数据包而不是3个数据包。

一旦我们计算出每个连接间隔可以传输的最大数据包数，我们就可以计算出数据吞吐量：

数据吞吐量 = 每个连接间隔的数据/连接间隔 = 每个连接间隔的数据包数量每个数据包/连接间隔的数据大小

= 2 244 8位/75毫秒= 520,533位/秒〜= 508kbps

大家会认为，连接间隔越小，速率肯定更高，然，并不是。

下面就根据真实测试数据和计算理论值一一对比。

如有需要理论测试值计算推导的朋友，可以后台跟我联系。

总结：

路由器，蓝牙，手机wifi等24G的设备干扰，测试设备主从之间的距离，设备之间存在障碍等因数都会影响测试结果。上面列出的测试值和理论值，可能实际环境中的测量数据吞吐量不一致。干扰和传输/接收错误会影响数据吞吐量（重试，数据丢失和连接事件关闭会导致吞吐量降低）。 但本文详细分析了所有和速率相关的因素，在实际使用中，大家可以自由DIY

在ios中ibeacon是基于地理位置的微定位技术（从这句话中可以得出Introduced in iOS 7, iBeacon is an exciting technology enabling new location awareness possibilities for apps），虽然借助手机蓝牙进行接收Majro、Minor，但是他们在开发工程中没有任何关系。

ibeacon使用苹果提供CoreLocation库，然而在BLE在开发过程中使用CoreBluetooth库。从上面提供的库来看就很清楚了，特别是在IOS8之上的时候如果想使用ibeacon，必须让用户点击是否允许“App使用地理位置”。如果在第一次使用ios app扫描ibeacon的时候没有提示这句话是不可能接收到ibeacon的信号（除非ios 80之下）。如果是BLE则的开发过程中之需要提示用户打开蓝牙，并不要求其他的地理位置任何信息。

第一：在ios中所有的数据都是通过API获取的，也就是说在IOS中不会看到蓝牙模块的裸数据（在这里的裸数据就代表蓝牙模块发送的16进制的数据），只能拿到苹果公司提供的极个别的API中的数据。

第二：ble、ibeacon各使用各自的API，他们之间没有任何对应关系。如果想使用ble就不可能获取到ibeacon的major、minor、uuid等信息，如果使用ibeacon，没有办法发起链接请求获取服务。

第三：在ios中ibeacon通信数据只有

这个六个属性，其分别含义是“ proximityUUID major、minor表示ibeacon的uuid，major、minor；proximity就是苹果提供的几个表示距离的属性CLProximityUnknown（没有数据）,CLProximityImmediate（十厘米以内）,CLProximityNear（一米以内）,CLProximityFar（一米以外）”。

“在很多硬件人员的眼中认为，ibeacon和ble没有区别啊，我们都是在同一个模块上面开发的，只是发送的数据格式不一样，ibeacon应该和ble没有区别，ios可以获取数据按照我们给的通信协议进行解析就可以啊。”这个就犯了我刚才所说的一个错误，在ios的开发过程中ibeacon和ble是两个不同的东西，所有的数据都被苹果拦截了，只给开发者特定的api可以调用。虽然从硬件上面来看没有任何区别但是在开发过程中确实两个不同的东西。但是有很多的厂商又想让ble具有ibeacon的类似的功能，比如可以让app获取到major、minor这个又怎么办？让ios的app获取ble的MAC地址等等功能（说明一下，ios是不能直接获取ble的mac地址的）？在这里（只是我个人的意见也是我在工作中得到的一些方法）是我的建议，一般很多ble正在发送发现广播的时候携带了“kCBAdvDataServiceData”信息，可以把ibeacon的major、minor放在kCBAdvDataServiceData的数据区域，然后让app根据协议截取响应的信息。也可以放到其他的信息中，这要看公司的策略。

如果有一款iOSble的巡检App（非ibeacon的App）可以用BLE扫描出ibeacon的信息，他的App肯定不是直接扫描ibeacon，这一点可以从两个方面进行验证第一：是否使用用户的地理位置，第二：拿一个其他厂家的标准ibeacon，（ibeacon的uuid一定不要一样，因为ios在扫描ibeacon的时候一定要指定需要扫描的uuid，换一个uuid

app都不可能扫描到）。通过上面两点可以很好的判定app是巡检ble还是ibeacon。

总结上面所有的观点，如果想使用ios的app巡检ble又能巡检ibeacon，一定要在蓝牙模块的广播数据中做文章。怎么做文章需要各厂商自己权衡。

iPhone用户可以在未打开App情况下（App被用户开启过，并且授权使用蓝牙以及定位，并且蓝牙处于开启状态），收到IBeacon设备（蓝牙外设设备）广播的信息，并短暂的激活该App （约10秒）去执行一些方法。

根据IBeacon设备的发射范围，确定用户当前的状态：进入、持续监听、离开。然后做出不同的响应

蓝牙扫一扫；区域推送；活动现场互动（配对，寻宝等）；签到，蓝牙锁（应用内手动签到、开锁或者点亮屏幕即可签到、开锁）。

蓝牙连接打印机

>

Android 43（API Level 18）开始引入Bluetooth Low Energy（BLE，低功耗蓝牙）的核心功能并提供了相应的 API， 应用程序通过这些 API 扫描蓝牙设备、查询 services、读写设备的 characteristics（属性特征）等 *** 作。

详细介绍 GATT 之前，需要了解 GAP（Generic Access Profile） ，它在 用来控制设备连接和广播 。 GAP 使你的设备被其他设备可见，并决定了你的设备是否可以或者怎样与合同设备进行交互 。例如 Beacon 设备就只是向外广播，不支持连接，小米手环就等设备就可以与中心设备连接。

GAP 给设备定义了若干角色，其中主要的两个是： 外围设备（Peripheral） 和 中心设备（Central） 。

在 GAP 中外围设备通过两种方式向外广播数据： Advertising Data Payload（广播数据） 和 Scan Response Data Payload（扫描回复） ，每种数据最长可以包含 31 byte。

这里 广播数据是必需的 ，因为外设必需不停的向外广播，让中心设备知道它的存在。扫描回复是可选的，中心设备可以向外设请求扫描回复，这里包含一些设备额外的信息，例如设备的名字。

GAP 的广播工作流程如下图所示：

外围设备会设定一个广播间隔，每个广播间隔中，它会重新发送自己的广播数据，广播时间越长，越省电，同时也不太容易扫描到。

大部分情况下， 外设通过广播自己来让中心设备发现自己，并建立 GATT 连接，从而进行更多的数据交换。

也有些情况是不需要连接的，只要外设广播自己的数据即可。用这种方式主要目的是让外围设备，把自己的信息发送给多个中心设备。 因为基于 GATT 连接的方式的，只能是一个外设连接一个中心设备。 使用广播这种方式最典型的应用就是苹果的 iBeacon。广播工作模式下的网络拓扑图如下：

查看这篇博客

GATT 的全名是 Generic Attribute Profile，它定义两个 BLE 设备通过叫做 Service 和 Characteristic 的东西进行通信。GATT 就是使用了 ATT（Attribute Protocol）协议，ATT 协议把 Service, Characteristic以及对应的数据保存在一个查找表中，次查找表使用 16 bit ID 作为每一项的索引。

一旦两个设备建立起了连接，GATT 就开始起作用了，这也意味着，你必需完成前面的 GAP 协议。这里需要说明的是，GATT 连接，必需先经过 GAP 协议。实际上，我们在 Android 开发中，可以直接使用设备的 MAC 地址，发起连接，可以不经过扫描的步骤。这并不意味不需要经过 GAP，实际上在芯片级别已经给你做好了，蓝牙芯片发起连接，总是先扫描设备，扫描到了才会发起连接。

GATT 连接需要特别注意的是： GATT 连接是独占的。也就是一个 BLE 外设同时只能被一个中心设备连接 。一旦外设被连接，它就会马上停止广播，这样它就对其他设备不可见了。当设备断开，它又开始广播。

中心设备和外设需要双向通信的话，唯一的方式就是建立 GATT 连接。

下图展示了 GTT 连接网络拓扑结构。这里很清楚的显示， 一个外设只能连接一个中心设备，而一个中心设备可以连接多个外设。 Connected Topology一旦建立起了连接，通信就是双向的了，对比前面的 GAP 广播的网络拓扑， GAP 通信是单向的。如果你要让两个设备外设能通信，就只能通过中心设备中转。

GATT 通信的双方是 C/S 关系。 外设作为 GATT 服务端（Server），它维持了 ATT 的查找表以及 service 和 characteristic 的定义 。中心设备是 GATT 客户端（Client），它向 Server 发起请求。需要注意的是，所有的通信事件，都是由客户端（也叫主设备，Master）发起，并且接收服务端（也叫从设备，Slave）的响应。

一旦连接建立，外设将会给中心设备建议一个连接间隔（Connection Interval） ，这样，中心设备就会在每个连接间隔尝试去重新连接，检查是否有新的数据。但是，这个连接间隔只是一个建议，你的中心设备可能并不会严格按照这个间隔来执行，例如你的中心设备正在忙于连接其他的外设，或者中心设备资源太忙。

下图展示一个外设（GATT 服务端）和中心设备（GATT 客户端）之间的数据交换流程，可以看到的是，每次都是主设备发起请求：

Bluetooth BR/EDR和BLE是两种不同的蓝牙技术，它们在使用上有一些区别，具体如下：

技术特性：BR/EDR是传统蓝牙技术，主要用于高速数据传输和音频传输，而BLE则是低功耗蓝牙技术，主要用于物联网设备和传感器等低带宽应用。

传输速率：BR/EDR的最高传输速率为3Mbps，而BLE的最高传输速率为1Mbps，但BLE的传输速率在实际应用中通常更低。

范围：BR/EDR的通信范围较广，可达到约100米，而BLE的通信范围较短，通常为10米左右。

能耗：BLE比BR/EDR更节能，因为它的工作方式更为简单，使用的功率更低，因此更适合低功耗设备。

兼容性：BR/EDR是传统蓝牙技术，与大多数蓝牙设备兼容，而BLE只能与支持BLE的设备进行通信。

总之，BR/EDR和BLE各有优缺点，在不同的应用场景中应选择适合的技术。

iBeacon

在ios 中ibeacon是基于地理位置的微定位技术，虽然借助手机蓝牙进行接收Majro、Minor，但是在开发工程中没有任何关系。

ios 在ble、ibeacon 开发过程中与Android 的区别

在ios 中所有的数据都是通过API获取的，也就是说在IOS中不会看到蓝牙模块的裸数据，只能拿到苹果公司提供的极个别的API中的数据。

ble、ibeacon各使用各自的API，之间没有任何对应关系。如果想使用ble就不可能获取到ibeacon的major、minor、uuid 等信息，如果使用ibeacon，没有办法发起链接请求获取服务。

在ios中ibeacon通信数据只有六个属性，就是苹果提供的几个表示距离的属性，是一个float类型数据。

以上就是关于iOS BLE 开发小记[1] - CoreBluetooth 是什么全部的内容，包括:iOS BLE 开发小记[1] - CoreBluetooth 是什么、蓝牙5速率提升方式、在IOS 的开发中iBeacon和BLE的区别等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！