在IOS 的开发中iBeacon和BLE的区别

区分3个概念beacon、BLE、iBeacon

BLE

全称为Bluetooth Low Energy，蓝牙低功耗技术。现在的蓝牙技术所消耗的功耗很低，并不像传闻中不使用蓝牙需要关闭省电，手机上长期打开蓝牙所消耗的电量可以忽略不计。

beacon

是用于室内定位，基于 BLE协议的在 广播搜索 上 稍作变化 变更了数据类型 实现的一个 应用场景。

广播搜索协议 位于标准的 蓝牙协议的GAP层，设备通过这个层的协议进行交互沟通数据。

所以可以理解为 beacon是非标准BLE的一个应用场景，因为他不符合 GAP规范(《Supplement to the Bluetooth Core Specification V6》 Part A 14 July 2015) 采用了未定义的数据类型。

iBeacon

它是apple提出的，对beacon的变种。
同类型的变种有：

1. apple iBeacon
2. Radius Networks ： AltBeacon
3. google : Eddystone

iOS中 iBeacon 和 BLE

在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在BLE、iBeacon开发过程中与Android的区别

1. 在ios中所有的数据都是通过API获取的，也就是说在IOS中不会看到蓝牙模块的裸数据（在这里的裸数据就代表蓝牙模块发送的16进制的数据），只能拿到苹果公司提供的极个别的API中的数据。
2. ble、ibeacon各使用各自的API，他们之间没有任何对应关系。如果想使用ble就不可能获取到ibeacon的major、minor、uuid等信息，如果使用ibeacon，没有办法发起链接请求获取服务。
3. 在ios中ibeacon通信数据只有

//设备的唯一ID，一般是自定义；
open var proximityUUID: UUID { get }
//主要区域标识，可定义（例如：xxx商场的标记）；
@NSCopying open var major: NSNumber { get }
//次要区域标识，可定义（例如：xxx商场的xxx店铺）；
@NSCopying open var minor: NSNumber { get }
// 设备的信标距离
open var proximity: CLProximity { get }
// accuracy表示相对距离，是一个float类型数据。
open var accuracy: CLLocationAccuracy { get }
// RSSI就是信号强度。
open var rssi: Int { get }

这个六个属性，其分别含义是：
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根据协议截取响应的信息。也可以放到其他的信息中，这要看公司的策略。

如果有一款iOS BLE的巡检App（非iBeacon的App）可以用BLE扫描出iBeacon的信息，他的App肯定不是直接扫描iBeacon，这一点可以从两个方面进行验证
第一：是否使用用户的地理位置，
第二：拿一个其他厂家的标准iBeacon，（iBeacon的uuid一定不要一样，因为iOS在扫描 iBeacon 的时候一定要指定需要扫描的uuid，换一个uuid app都不可能扫描到）。
通过上面两点可以很好的判定app是巡检BLE还是iBeacon。
总结上面所有的观点，如果想使用ios的app巡检ble又能巡检iBeacon，一定要在蓝牙模块的广播数据中做文章。怎么做文章需要各厂商自己权衡。

iBeacon的设计逻辑：

iPhone用户可以在未打开App情况下（App被用户开启过，并且授权使用蓝牙以及定位，并且蓝牙处于开启状态），收到iBeacon设备（蓝牙外设设备）广播的信息，系统短暂的激活该App （约10秒）去执行一些方法。
根据iBeacon设备的发射范围，确定用户当前的状态：进入、持续监听、离开。然后做出不同的响应。

应用场景：

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