总结一下蓝牙开发相关的知识点和注意事项，做个笔记，也希望你们能少踩坑
创新互联-专业网站定制、快速模板网站建设、高性价比城区网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式城区网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖城区地区。费用合理售后完善，十余年实体公司更值得信赖。
(公司部分蓝牙项目为混编项目，蓝牙相关处理均采用了Objective-C，故本文????均采用OC，Swift处理相同)
蓝牙4.0包含两个蓝牙标准，它是一个是 双模 的标准，它包含 传统蓝牙部分(也称经典蓝牙) 和 低功耗蓝牙部分(BLE) , 二者适用于不同的应用场景和应用条件。他们的特点如下
所以蓝牙4.0是集成了传统蓝牙和低功耗蓝牙两个标准的，并不只是低功耗蓝牙
蓝牙4.0支持两种部署方式： 双模式 和 单模式 ，双模同时支持经典蓝牙和低功耗蓝牙，而单模则只支持其中一种。
二者更多细节详见： 传统蓝牙和低功耗蓝牙的区别
iOS中蓝牙相关功能都封装进了 CoreBluetooth 类中,其中有几个常见的参数和概念
具体API参考 CoreBluetooth蓝牙开发
保存到数组中的设备可通过 UUID 来进行区分。从 iOS7之后苹果不提供外设的mac地址，外设的唯一标识换成了由mac封装加密后的UUID，需要注意的是不同的手机获取同一个外设的UUID是不同的，所以在不同手机之间UUID不是唯一的，但在本机上可以作为唯一标识(特殊情况手机刷机后也会改变UUID)。
如何获取Mac地址
一般使用场景是根据Mac地址区分某个外设
注意点：
写入数据时可能会遇到需要分包发送的情况，我们可以通过下面的API或许当前特征支持的最大的单条写入长度
maxLength 一般取决于蓝牙模块内部接收 缓冲区 的大小，很多硬件设备这个缓冲区的大小是 20 字节, 这个大小也和特征的写入权限有关，像具有写入权限 withResponse 类的特征其大小一般为 512 字节，当然这些都是取决于设备测的设置；
当我们单次发送的数据字节长度大于 maxLength 时，我们就需要采用分包的方式来发送数据了,
分包发送的逻辑类似于下面
这边延时主要是设备侧的接收模块接收数据以及处理能力有限
外围设备测和中心设备(大部分情况下是手机)保持蓝牙连接的状态下，如果长时间不产生交互，蓝牙就会断开，所以为了保持两者持续的连接状态，需要做保活处理，也就是需要持续的发送心跳包(watchdog)。相应的处理是使用一个定时器定时向设备侧发送符合设备协议格式的心跳包。
断开连接很简单，只需要调用 [self.centralManager cancelPeripheralConnection:peripheral] 传入需要断开连接的设备对象就行了。断开连接时会自动调用 centralManager:didDisconnectPeripheral:error: 代理方法。
按照之前的惯例，当error为nil时表示断开成功，error不为nil时断开失败。这种理解是错误的。
当你调用 cancelPeripheralConnection: 方法（主动断开）断开连接时error为nil ; 没有调用这个方法（异常断开）而断开时error返回的是异常断开的原因。也可以理解为主动调用断开连接方法一定会断开
接下来就是断开重连的问题了，对蓝牙功能进行封装时肯定少不了断开重连。首先断开时可通过上面的代理方法的error是否为nil判断是否是异常断开，一般情况下异常断开时是需要重连的
原因就是当设备断开连接后 peripheral.services 为nil了，当然 service.characteristics 也是nil，所以需要在断开连接时把保存这个设备对应的服务和特征全部清除，然后在连接成功时重新过一遍发现服务和发现特征的流程就好了。
iOS7 开始，Apple加入了Beacon围栏检测的API, ( iBeacon-维基百科 ), 其工作方式是，配备有低功耗蓝牙（BLE）通信功能的设备使用 BLE 技术向周围发送自己特有的 ID，接收到该 ID 的应用软件会根据该 ID 采取一些行动。比如，在店铺里设置 iBeacon 通信模块的话，便可让 iPhone 和 iPad 上运行一资讯告知服务器，或者由服务器向顾客发送折扣券及进店积分, 或者公司的手机打卡，只要手机靠近打卡器一定范围，手机测就向打开器发送打卡信息，从而自动打卡。这种场景还有很多。 其中一个最重要的功能就是App的唤醒功能(杀死后也能唤醒)
举一个我们的例子，我们的产品业务场景就是在进入车辆以后，需要使用蓝牙连接我们的后装车载设备以采集车辆信息和驾驶行为行程等，这里有一个问题就是在App被杀死的情况下如何唤醒App, 因为不可能要求用户每次都主动去打开App，这样体验太差。我们的做法是通过iBeacon，当我们的车辆点火以后，设备测通电，发出 iBeacon广播 ，App实现监听iBeacon相关功能后就可以唤醒我们App，然后在相应的回调的处理一些事情，比如通过蓝牙连接设备。这里的前提条件是我们的硬件设备测包含iBeacon模块，具有iBeacon功能，而且对iBeacon的广播频率也有一定的要求，长了可能唤醒的功能会不稳定，官方建议的好像是100ms，频率超高越耗电，但可以让手机或其它监听设备越快地发现iBeacon。标准的BLE广播距离是100m，这使Beacon在室内位置跟踪场景下的效果更理想。
关于iBeacon更多的使用及介绍请参考
苹果核 - iOS端近场围栏检测（一） ——iBeacon
iBeacon技术初探
GAP（Generic Access Profile）：它用来控制设备连接和广播，GAP 使你的设备被其他设备可见，并决定了你的设备是否可以或者怎样与合同设备进行交互。
GATT(Generic Attribute Profile)：BLE连接都是建立在GATT协议之上的。GATT 是一个在蓝牙连接之上的发送和接收很短的数据段的通用规范，这些很短的数据段被称为属性（Attribute）。
BLE中主要有两个角色：外围设备（Peripheral）和中心设备（Central）。一个中心设备可以连接多个外围设备，一个外围设备包含一个或多个服务（services）,一个服务包含一个或多个特征（characteristics）。
使用CoreBluetooth库，创建CBPeripheralManager，实现CBPeripheralManagerDelegate代理
创建完该对象，会回调peripheralManagerDidUpdateState:方法判断蓝牙状态，蓝牙可用，给外设配置服务和特征
注意CBAttributePermissions
当中心设备读写设置CBAttributePermissionsReadEncryptionRequired/CBAttributePermissionsWriteEncryptionRequired权限的Characteristic时，会弹出弹框，请求建立安全连接
给外设配置服务特征后，会调用peripheralManager:didAddService:error: 服务特征全部添加完后发起广播，如果在广播时设置CBAdvertisementDataServiceUUIDsKey，会把该service广播出去，中心设备在扫描时可根据该uuid找到该设备。外围设备靠不断发广播，使中心设备发现它。
当中央端连接上了此设备并订阅了特征时会回调 didSubscribeToCharacteristic:
当接收到中央端读的请求时会调用didReceiveReadRequest:
创建CBCentralManager对象，实现CBCentralManagerDelegate代理
回调centralManagerDidUpdateState:代理方法，当central.state==CBManagerStatePoweredOn时，开启扫描，设置serviceUUIDs可扫描特定外设，CBCentralManagerScanOptionAllowDuplicatesKey设为NO不重复扫描已发现设备，YES是允许
扫描到设备会回调centralManager:didDiscoverPeripheral:advertisementData:RSSI:，RSS绝对值越大，表示信号越差，设备离的越远
关闭扫描
连接设备
发现服务
发现特征
最近一直在开发通过ble进行设备与App交互的产品。在开发过程中，手机一直作为中央设备，负责主动发起扫描连接，而设备作为边缘设备。需求需要两者发送指令，传输文件。文件的传输就是将设备中的文件拆解成一包一包的数据通过ble发送给App。在设备与App定义了一套通用的协议的基础上，两者的指令发送很正常，因为指令的发送简短而且单一，双方处理没有问题。但是在发送文件时，遇到了严重的丢包问题。当时设置的设备发送数据到App，拆分的数据包大小是180个字节，这在iphone6s上已经达到上限了。但是在发送文件时，App上接受的数据会出现丢包，首先怀疑的是设备端没有将数据发送出来，后来设备端改了发送逻辑，在每一包数据发送之后，在收到底层的发送成功回调之后再发送下一包数据，在这种模式下，App端接受到的数据还是会丢。当时问题很困扰，App端觉得是设备端的问题，设备端觉得是App端的问题。后来我想到了一种场景，在那种场景的启发下，我觉得现在这种场景是之前那种场景的反向。
之前我在做一款AI 语音耳机时，也是通过ble传输实时音频以及进行OTA（固件升级）的。当时在传输OTA数据包时，由于耳机的内存不够，在我一直发送文件包时，耳机会crash，后来固件排查下来由于内存不够，在疯狂发送数据时，把内存撑爆了，导致了耳机的奔溃，最后的解决方案是我对发送的每一包数据都设置了合适的长度外，还在每一包的发送过程中进行sleep，给固件时间去进行处理，这样问题就解决了。
然后我联想到这次的问题，由于不同的手机采用的蓝牙芯片参差不齐，不同的蓝牙芯片的处理能力又不同，所以我怀疑在固件疯狂发送数据到手机上时，根据不同手机的蓝牙芯片的处理能力，会出现丢包的大小也不一样。针对这种怀疑，我们测试了iphone6s，iphonex，iphone11，发现后两台设备的丢包率明显小很多。我们又测试了不同价位的Android手机，也发现低端Android手机的丢包率也明显大于中高端手机。在基于这种测试基础上，提出了解决方案：1.降低每个数据包的大小，2.每个数据包间隔时间发送，这个时间需要测试。在经过测试之后，单纯第一点解决方案和第二点解决方案都不会达到最理想的结果，所以合适的方案就是两者结合，将丢包率降到更低。所以最终的解决方案就是降低每一包的大小的同时，也保证每包数据包的发送间隔，这两者的数据我们是通过测试之后拿到的平衡值，针对不同的固件的蓝牙芯片这个数据可能都是不同的。
兜兜转转了一圈查到了丢包问题的原因，其实这个原因不难想，我跟固件开发当时都觉得是对方处理的问题，导致一直没有从全局去看这个问题，记录一下。
1.什么是蓝牙4.0，蓝牙其它标准又是什么？
详细描述：低功耗蓝牙(Low Energy; LE)，又视为Bluetooth Smart或蓝牙核心规格4.0版本。其特点具备节能、便于采用，是蓝牙技术专为物联网(Internet of Things; IOT)开发的技术版本。所以它最主要的特点是低功耗，普及率高。现在所说的蓝牙设备，大部分都是在说4.0设备，ble也特指4.0设备。 在4.0之前重要的版本有 2.1版本-基本速率／增强数据率(BR/EDR) 和 3.0 高速蓝牙 版本，这些统称为经典蓝牙。4.0还有4.1和4.2的小版本，其中4.2版本对传输速率做了进一步他提升，提高了2.5倍，苹果从iphone6开始使用4.2，最新的蓝牙标准为蓝牙5.0，其中最大的特点连接范围扩大了4倍，速度又提高了2倍，无连接数据广播能力提高了8倍，增加了蓝牙组网的能力。
2.蓝牙开发必须知道的概念。
2.1.1 central和peripheral：
蓝牙应用开发中，存在两种角色，分别是central和peripheral(pə’rɪfərəl) ,中文就是中心和外设。比如手机去连接智能设备，那手机就是central，智能设备就是peripheral。大多时候都是central去连接peripheral的场景。
2.1.2 广播和连接:
peripheral会发出广播,central扫描到广播后，可以对设备进行连接，发出connect请求，peripheral接收到请求后，同意连接后，central和peripheral就建立了连接。
2.1.3 连接后的操作:
write，read，notify，indecate， response or not …
indecate和notify的区别就在于，indecate是一定会收到数据，notify有可能会丢失数据（不会有central收到数据的回应），write也分为response和noresponse，如果是response，那么write成功回收到peripheral的确认消息，但是会降低写入的速率。
2.1.4 协议:
每个具体的智能设备，都约定了一组数据格式，这个就是数据协议，例如手环中获取到数据0X001023，其中第2位到第5位表示步数，那么就2310就是步数的16进制的数据，转换成10进制就是8976步，需要注意的是，设备端都是小端模式，所以取4位时候，高字节在前低字节在后。
3. iOS蓝牙应用的一般开发流程。
4. 蓝牙的数据交互。
write，read，notify，indecate， response or not … 都是容易理解的，indecate和notify对应的是长连接，建立indecate后，peripheral可以随时往central发送数据。
indecate和notify的区别就在于，indecate是一定会收到数据，notify有可能会丢失数据（不会有central收到数据的回应），write也分为response和noresponse，如果是response，那么write成功回收到peripheral的确认消息，但是会降低写入的速率。
对于一个charateristic，他的读写订阅的权限是peripheral决定的，熟悉可以被同时设置，一般会根据外设的功能来决定。
5.蓝牙ota DFU。
蓝牙ota,DFU（Device Firmware Update）指的是蓝牙设备的固件升级，其实是一整套流程，不同的蓝牙芯片，ota的流程有不同之处，我这里用ti的芯片举例。步骤为：切系统(bootloader mode)，重启，传输数据，验证数据，切系统，重启，完成。
其中数据传输也会分成很多节去发送，没法送一段数据，做一次数据校验。
6.ota存在的问题。
每个智能设备的速率，功耗，存储都会有很多限制，导致很多设备会自己去实现ota的功能，自定义流程和数据传输方式，导致许多设备都是有自己私有的ota模式和协议，所以在做开发的时候，要仔细阅读设备协议中对ota的描述。
7.如何做自动重连。
只需要在设备断开连接的委托方法中，重新调用gatt.connet或者是centralManager.connet方法就可以了，无论当时设备是否有点，是否在周围，当设备再次开会或者连接到可连接范围内，都会自动被连上。
8.连接失败处理。
分两个平台来说，iOS端也有连接失败的委托，但是好像几乎不会发生这种情况，而对于同款设备，android常常会出现连接失败的情况，status != BluetoothGatt.GATT_SUCCESS，android端开发请不要把连接失败和断开连接放在一块处理，因为断开连接可以直接尝试重新连接，而连接失败后尝试重新连接，需要加一些延时，并且需要gatt.close，清空一下状态，否则会把gatt阻塞导致手机不重启蓝牙就再也无法连接任何设备的情况 。
9.后台运行。
iOS后来运行，需要设备中info.Plist权限，key:Required background modes ,value: bluetooth-central(手机作为central) , bluetooth-peripheral。
10.同时连接多个设备。
使用同一个CBCentralManager，通过进入委托的peripheral的identifier区分不同的设备，进行不同的操作和处理。
11.扫描广播包。
所有外设，只有在发出广播包的情况下，才能被central发现，绝大多数情况下，外设被连接后就不会发出广播（也有例外），很多人遇到无法找到设备的问题，大多属于这种情况。
12.提高蓝牙连接速度。
无论是iOS，还是android，都可以通过已绑定的设备，在不开启扫描的情况下进行快速连接，iOS需要的参数是peripheral的identifier，android需要mac地址。但android和iOS还是有一些区别的，比如iOS不能拿到已绑定的设备list，但是可以通过UUID去拿到peripheral的实例。而android可以拿到已绑定的设备list。android绑定过程需要手动调用createBond的方法，而iOS在连接成功一次后会自动绑定。 android在处理createBond时，常常会应为不同手机平台，不同设备，会产生兼容性的问题，这点需要注意。
13.定向扫描。
在扫描时候可以传入serviceUUID，这样可以扫描到特定条件的设备，提高扫描的速度，排除干扰。
14.如何获取mac地址。
而iOS出于苹果的安全策略问题，无法直接获得mac地址，只能得到一个mac地址换算出来的identifier。
现在我们都知道，很多智能硬件设备都已经集成了低功耗蓝牙模块，这样我们就可以开发一个 iOS 或者 Mac APP 与它们进行交互。从 macOS 10.9 和 iOS 6 以后，Mac 和 iOS 设备就支持 低功耗蓝牙技术了，我们可以通过 CoreBluetooth 这个框架与底层的各种蓝牙协议栈进行交互，比如 GATT、ATT 和 L2CAP 等。
与底层交互的过程如下图所示：
开始下文之前，我们需要了解几个概念。对蓝牙不够了解的可以看一下维基百科关于 蓝牙 的简介。
Bluetooth 4.0 : 蓝牙 4.0 是 Bluetooth SIG 于2010年7月7日推出的新的规范，其最重要的特性是功耗低，省电！
BLE : Bluetooth low energy wireless technology,也就是低功耗无线蓝牙技术。
BLE 是关于蓝牙4.0 的详细说明，它定义了一套用于低功耗设备之间通信的协议。而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 设备进行数据通信时，必须在项目的 Info.plist 文件中包含关于 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 10.9 和 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
欢迎在本文下面留言一起交流心得...
在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 8.0之下）。如果是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设备的发射范围，确定用户当前的状态：进入、持续监听、离开。然后做出不同的响应
蓝牙扫一扫；区域推送；活动现场互动（配对，寻宝等）；签到，蓝牙锁（应用内手动签到、开锁或者点亮屏幕即可签到、开锁）。
蓝牙连接打印机
