iOS蓝牙开发相关知识点和注意事项

总结一下蓝牙开发相关的知识点和注意事项，做个笔记，也希望你们能少踩坑

(公司部分蓝牙项目为混编项目，蓝牙相关处理均采用了Objective-C，故本文均采用OC，Swift处理相同)

蓝牙4.0BLE和传统蓝牙

蓝牙4.0包含两个蓝牙标准，它是一个是双模的标准，它包含传统蓝牙部分(也称经典蓝牙)和低功耗蓝牙部分(BLE), 二者适用于不同的应用场景和应用条件。他们的特点如下

传统蓝牙： 传统蓝牙可以用与数据量比较大的传输，如语音，音乐，较高数据量传输等
低功耗蓝牙： 低功耗蓝牙这样应用于实时性要求比较高，但是数据速率比较低的产品，如遥控类的，如鼠标，键盘，遥控鼠标(Air Mouse)，传感设备的数据发送，如心跳带，血压计，温度传感器等

所以蓝牙4.0是集成了传统蓝牙和低功耗蓝牙两个标准的，并不只是低功耗蓝牙

蓝牙4.0支持两种部署方式：双模式和单模式，双模同时支持经典蓝牙和低功耗蓝牙，而单模则只支持其中一种。

二者更多细节详见：传统蓝牙和低功耗蓝牙的区别

API字段描述

iOS中蓝牙相关功能都封装进了CoreBluetooth类中,其中有几个常见的参数和概念

参数	描述
Center	中心设备，发起蓝牙连接的设备(一般是手机)
Peripheral	外设，被蓝牙连接的设备(某些情况下外设也可以作为中心设备，中心设备也可以作为外设)
Serice and Characteristic	服务和特征，每个设备会提供服务和特征，类似于服务端的API，但是结构不同，每个设备会有很多服务，每个服务中包含很多特征，这些特征的权限一般分为读(read)，写(write)，通知(notify)几种，就是我们连接设备后具体需要操作的内容
Description	描述，每个Characteristic可以对应一个或者多个Description用于描述Characteristic的信息或属性

具体API参考CoreBluetooth蓝牙开发

Mac地址：

保存到数组中的设备可通过UUID来进行区分。从 iOS7之后苹果不提供外设的mac地址，外设的唯一标识换成了由mac封装加密后的UUID，需要注意的是不同的手机获取同一个外设的UUID是不同的，所以在不同手机之间UUID不是唯一的，但在本机上可以作为唯一标识(特殊情况手机刷机后也会改变UUID)。

如何获取Mac地址

连接前：可通过广播包里的特定字段来获取，前提是和硬件工程师协商好

- (void)centralManager:(CBCentralManager *)central didDiscoverPeripheral:(CBPeripheral *)peripheral advertisementData:(NSDictionary *)advertisementData RSSI:(NSNumber *)RSSI

根据上面代理方法中的 advertisementData,它是一个广播包，里面会有一些设备的属性，但都被苹果给限制了，只有一个kCBAdvDataManufacturerData幸免，它是可以修改的，所以要跟硬件工程师协商好，将mac地址写入这个key里面去

连接后：连接成功后可通过外设的特征值的属性截取，或者通过设备侧返回的数据包获取。详见iOS 蓝牙连接获取MAC地址的方法

一般使用场景是根据Mac地址区分某个外设

写入数据

MARK: 发送数据
-(void)sendDataToBLE:(NSData *)data{
    if(nil != self.characteristic){
        // data: 数据data
        // characteristic: 发送给哪个特征
        // type:     CBCharacteristicWriteWithResponse,  CBCharacteristicWriteWithoutResponse,
        // 这里要跟硬件确认好，写入的特征是否有允许写入，允许用withResponse 不允许只能强行写入，用withoutResponse
        // 或者根据 回调的error查看一下是否允许写入，下面说
        // 比如这里是不允许写入的，所以用 WithoutResponse
        [self.peripheral writeValue:data forCharacteristic:self.characteristic type:CBCharacteristicWriteWithoutResponse];
}

//MARK: 发送数据成功回调
-(void)peripheral:(CBPeripheral *)peripheral didWriteValueForCharacteristic:(CBCharacteristic *)characteristic error:(NSError *)error{
    if (error) {
        NSLog(@"写入数据失败:(%@)\n error:%@",characteristic,error.userInfo);
        // 这里用withResponse如果报错："Writing is not permitted."说明设备不允许写入，这个时候要用 WithoutResponse
        // 使用 WithoutResponse的时候，不走这个代理。
        return;
    }
    NSLog(@"写入数据成功:%@",characteristic);
    [peripheral readValueForCharacteristic:characteristic];
}

注意点：

这里要跟硬件确认好，写入的特征是否有允许写入，允许用withResponse, 不允许只能用withoutResponse强行写入, 或者查看回调中error,如果返回 "Writing is not permitted." 则表示不允许写入，那么使用withoutResponse。
如果是使用withoutResponse写入的，不走这个回调。

写入数据时可能会遇到需要分包发送的情况，我们可以通过下面的API或许当前特征支持的最大的单条写入长度


if (@available(iOS 9.0, *)) {
        // type:这里和上面一样，
        maxLength =(int)[self.peripheral maximumWriteValueLengthForType:CBCharacteristicWriteWithoutResponse];
    } else {
        // 默认是20字节
        maxLength =20;
    }

maxLength一般取决于蓝牙模块内部接收缓冲区的大小，很多硬件设备这个缓冲区的大小是20字节, 这个大小也和特征的写入权限有关，像具有写入权限withResponse类的特征其大小一般为512字节，当然这些都是取决于设备测的设置；

当我们单次发送的数据字节长度大于maxLength时，我们就需要采用分包的方式来发送数据了,

分包发送的逻辑类似于下面

 for (int i = 0; i < [data length]; i += maxValue) {
        // 预加 最大包长度，如果依然小于总数据长度，可以取最大包数据大小
        if ((i + maxValue) < [data length]) {
            NSString *rangeStr = [NSString stringWithFormat:@"%i,%i", i, maxValue];
            NSData *subData = [data subdataWithRange:NSRangeFromString(rangeStr)];
            [self sendDataToBLE:subData];
            // 根据接收模块的处理能力做相应延时
            usleep(10 * 1000);
        }
        else {
            NSString *rangeStr = [NSString stringWithFormat:@"%i,%i", i, (int)([data length] - i)];
            NSData *subData = [data subdataWithRange:NSRangeFromString(rangeStr)];
            [self sendDataToBLE:subData];
            usleep(10 * 1000);
        }
    }

这边延时主要是设备侧的接收模块接收数据以及处理能力有限

心跳包

外围设备测和中心设备(大部分情况下是手机)保持蓝牙连接的状态下，如果长时间不产生交互，蓝牙就会断开，所以为了保持两者持续的连接状态，需要做保活处理，也就是需要持续的发送心跳包(watchdog)。相应的处理是使用一个定时器定时向设备侧发送符合设备协议格式的心跳包。

断开&重连：

断开连接很简单，只需要调用[self.centralManager cancelPeripheralConnection:peripheral]传入需要断开连接的设备对象就行了。断开连接时会自动调用centralManager:didDisconnectPeripheral:error:代理方法。
按照之前的惯例，当error为nil时表示断开成功，error不为nil时断开失败。这种理解是错误的。

当你调用cancelPeripheralConnection:方法（主动断开）断开连接时error为nil ; 没有调用这个方法（异常断开）而断开时error返回的是异常断开的原因。也可以理解为主动调用断开连接方法一定会断开

接下来就是断开重连的问题了，对蓝牙功能进行封装时肯定少不了断开重连。首先断开时可通过上面的代理方法的error是否为nil判断是否是异常断开，一般情况下异常断开时是需要重连的

重新连接后发现读写数据时没效果了？？？

原因就是当设备断开连接后peripheral.services为nil了，当然service.characteristics也是nil，所以需要在断开连接时把保存这个设备对应的服务和特征全部清除，然后在连接成功时重新过一遍发现服务和发现特征的流程就好了。

iBeacon

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技术初探