ios开发中蓝牙开发,ios蓝牙开发对硬件的要求

iOS 蓝牙开发（三）

iOS 蓝牙开发（一）

iOS 蓝牙开发（二）

iOS 蓝牙开发（四）

前面记录了蓝牙如何进行扫描、链接、以及获取外设的服务和特征，本篇笔记我将记录如何实现 与外设做数据交互(explore and interact) 。

构建方法流程：链接成功-获取指定的服务与特征-订阅指定的特征值-通过具有写权限的特征值来写数据-最后在函数 didUpdateValueForCharacteristic 中获取蓝牙的反馈信息；

总结：

本篇笔记大概就是在接收到服务和特征后对数据进行写入的操作的过程，笔记中的重点在于要熟悉构建特征和服务的方法流程。熟悉流程，我们就能清楚知道当在写入数据时，系统蓝牙会在函数 didUpdateValueForCharacteristic 方法中给我们反馈写入是否成功的反馈信息。

相关问答

Q1: iOS 蓝牙开发(一)

iOS 蓝牙开发（二）

iOS 蓝牙开发（三）

iOS 蓝牙开发（四）

在iOS中蓝牙相关实现都是在CoreBluetooth这个framework中的，所以我们创建一个单例类中需要先导入 #import CoreBluetooth/CoreBluetooth.h ，再后即可使用这个单例类进行管理我们蓝牙的扫描、连接、状态等实现。

当 central.state 为CBManagerStatePoweredOn即可开始扫描， 具体方法 [self.centralManager scanForPeripheralsWithServices:nil options:nil] 当调用 scanForPeripheralsWithServices：options: 函数时就会实时调用其代理方法 - (void)centralManager:(CBCentralManager *)central didDiscoverPeripheral:(CBPeripheral *)peripheral advertisementData:(NSDictionary *)advertisementData RSSI:(NSNumber *)RSSI

peripheral 是外设类 advertisementData 是广播的值，一般携带设备名， serviceUUID 等信息。 RSSI 绝对值越大，表示信号越差，设备离的越远。如果想装换成百分比强度， （RSSI+100）/1001 （这是一个约数，蓝牙信号值并不一定是-100 - 0的值）

蓝牙的连接是当中心设备扫描到可用外设后， 利用函数 [self.centralManager connectPeripheral:peripheral options:nil]; 进行链接， 当函数被调用后， 就会回调其对应的代理函数。

本篇笔记主要是记录如何初始化蓝牙的 CBCentralManager 的中心管理类，并记录如何实现扫描周边外设、如何链接、获取蓝牙当前状态。

Q2: iOS蓝牙开发实战

开发前提介绍  : 1. XCode  2.蓝牙手环(60)  3.苹果手机一部(1000)

规矩我懂 先上图

2014.12.2 蓝牙技术联盟发布

具备更低功耗， 更高的传输速度。 唤醒速度可以和zigbee媲美

蓝牙2.0 需要MIFI 认证，这个大家都知道 。 MIFI ： Make for ipad , iphone , itouch  专门为苹果设备制作的设备

蓝牙4.0 ： 本文章的主讲

开发框架 ： CoreBluetooth

           

central: 中心，连接硬件设备（手机端连接蓝牙手环 等等智能设备）

peripheral: 外设， 被连接的设备（仅当外设在不断广播的时候 才能被发现）

service: 服务

characteristic: 特征

               

_manager = [[CBCentralManager alloc] initWithDelegate: self queue: nil];

在调用这个方法的时候 带来会调用

- （void)centralManagerDidUpdataState:(CBCentralManager *)central

返回 ：

当前蓝牙的状态 ：

if (central.state != CBManagerStatePoweredOn) // 就代表返回失败了  当然自己看一下这个枚举

[_manager scanForPeripheralsWithServices:#你的特征值# options: nil];

# : 如果特征值写的是nil  那么当前所以可以被连接管理的蓝牙都可以扫描到

但是这里有个坑 ， 已经连接上的蓝牙 不会在代理里面被返回

对应代理 ：

处理 ：

centralManager: (CBCentralManager *）central didDiscoverPeripheral: (CBPeripheral *)peripheral advertisementData: (NSDictionar *id)advertisementData RSSI: (NSNumber *)RSSI{

if(peripheral.name != nil ![_perilist containsObject: peripheral]){

[_perilist addObject: peripheral];

}

}

连接外设失败 ： disFailToConnectPeripheral

连接断开： didDisconnectPeripheral

连接成功： didConectPeripheral

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

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

(公司部分蓝牙项目为混编项目，蓝牙相关处理均采用了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技术初探