H5+与BLE处理之路+uni-app

不好之处请批评指正

首先，这不是我第一次填坑之路，但出于对各平台特性的不了解,造成的坑坑洼洼算是比较惨淡的一次！将近20天，虽然期间也有处理别的事情。最后还是把使用心得以及结果给大家分享下。如有不对之处，欢迎广大网友批评指正，谢谢！

缘由

老板一句话，刀山火海任我闯。Android、IOS、小程序如此大任加身，奈何奈何！终于，皇天不负有心人，意外发现了uni-app这么个小东西，完全是救命稻草的节奏啊。一键编译，无障碍跨越多平台、终端，好吧！说干就干（毕竟基础在哪，上手还不是分分钟）。然而是我太天真，BUG组队而来。

多平台上 BLE 处理之路

简简单单

Android端：畅通无阻+安卓真好
一股无脑操作，纵你千变万化，也是手到擒来，哈哈哈！高兴了好一阵。

微信小程序端：方便快捷+就是慢了点点
不知道为什么，小程序在连接过程中，乃至整个数据传输过程显示有点慢（较直接APP上而言），也许是因为他是基于程序之上的程序吧。

IOS端：有点小坑响应最快自己不熟悉
因为IOS端与Android端的不同，也因为自己以前从未接触过IOS的开发，导致在这出现了各种问题，什么搜不到设备、连接失败、服务获取失败等等。刚开始也是难受得紧。

码码呼呼

废话也差不多了，直接上过程

1. 平台校验，初始化开始=>uni.openBluetoothAdapter
   准备工作是必须的，一开始就得初始化蓝牙适配器。当然，前提是你的蓝牙已经处于打开状态。
2. 监听结果=>uni.getBluetoothAdapterState
3. 开始搜索设备=>uni.startBluetoothDevicesDiscovery
   这儿很重要，比较消耗性能，一定记得回调关闭它。在这儿我用的比较直接

    setTimeout(（）=>{
    	uni.stopBluetoothDevicesDiscovery();
    }, time);

4. 发现设备=> uni.onBluetoothDeviceFound
   （1）到这儿其实也没有出现什么问题，我是直接在这儿发现一个就辨别一个设备的（设备的辨别可以用服务的UUID或者直接name）。
   （2）很无脑的是获取到的设备在Andoird平台上和IOS平台的deviceId居然各自为阵。Android是MAC地址，IOS则是UUID（连接却也是用它）。
   （3）当然为了有效也可以从advertisData中解析MAC地址！
5. 连接设备=>uni.createBLEConnection
   （1）这儿坑就来了。
   （2）想不通的是安卓可以直接利用得到的deviceId连接成功。
   （3）而IOS下却需要先uni.getBluetoothDevices（获取已搜索到的设备信息）再去执行conn操作。
   （4）为了这个要不是因为有前朝案例，我怕是要坑在这儿。
6. 获取服务=>uni.getBLEDeviceServices
   （1）这儿也是比较尴尬的，整个连接成功后，按理来说直接getServices没有任何毛病，但偏偏让我在此停留一段时间。
   （2）在这儿如果你直接getServices那么恭喜你，可能入坑了。因为他十之八九获取不到任何服务，总之我是这样的。
   （3）解决办法就是，在此弥留之际，咱休息片刻，如下。看来机器也是要休息的。真是尴尬，time随实际情况而定哦。但是不知道为什么，我在这儿每次连接首次获取基本都是失败，第二次reConn却百试不爽。真是让人恼火得紧。

		// 延迟获取服务
		setTimeout(function() {
			that.getBLEDeviceServices();
		}, time);
		
		//如果没有获取到服务，就重新连接一次
		if (services.length < 1) {
			setTimeout(function() {
				reConn();
			}, time);
		}

7. 获取特征值=>uni.getBLEDeviceCharacteristics
   到这儿基本就没什么问题了，算是成功大半。只需要找到对应的write与read就万事大吉咯。一般来说都在characteristics[0]上。
8. 订阅=>uni.notifyBLECharacteristicValueChange
   说白了就是监听值变化，如果有改变那就这样咯。从中取出值即可。

uni.onBLECharacteristicValueChange

9. 写入操作=> uni.writeBLECharacteristicValue
   这里没什么说的，唯一要注意的是【value】不是字符串哦，一定要是byte 。我这儿就比较简单粗暴了，直接 new Uint8Array（）的。道理都一样，怎么用看自己喜好。

	uni.writeBLECharacteristicValue({
		// 这里的 deviceId 需要已经通过 createBLEConnection 与对应设备建立链接
		deviceId: deviceId,
		// 这里的 serviceId 需要在 getBLEDeviceServices 接口中获取
		serviceId: serviceId,
		// 这里的 characteristicId 需要在 getBLEDeviceCharacteristics 接口中获取
		characteristicId: characteristicId,
		value: value,
		success(res) {
			// console.log('写入的数据是:' + wdata);
		},
		fail(res) {
			console.log('写入数据失败了:' + JSON.stringify(res));
			initTypes(res.errCode);
		}
	});

10. 释放资源=> uni.closeBLEConnection
    这儿呢，请记住最好就是合理的释放它，因为资源是有限的，总有穷尽之时。因此我也建议大家在任何时候做这些消耗性高的内容，最好考虑到释放资源的问题，不然有我们受的。

挖了什么坑就得想好怎么埋

1. 因为这是统一编译的，Android和IOS平台化差异很大，因此在整个开发过程中遇到的问题也是层出不容。我们在没有理解好开发所涉及的内容的情况下去做这些事情的时候，着实遇到的问题也是各种询问、百度，虽然最终90%能找到答案，但终究不是自己的。
2. 填坑汇总
   （1）搜索之坑：在Android平台下搜索过程显得很正常，而IOS下却发现有一个时间间隔，不知道是我自己的问题，还是什么原因。
   （2）连接之坑：Android平台下可以直接conn，而IOS中需要先getBluetoothDevices一次。虽然不是很理解为什么，但我这么做确实也是成功了！
   （3）获取服务之坑：conn成功后请手速慢一下，延迟一会儿，再去获取服务会显得优雅些。处于对这些的不怎么理解，所以也只能想到这么个愚蠢的解决方法了。
   （4）读取/写入数据之坑：对于这个不用多说，必须考虑其冲突性，我的项目初始化一次就得获取N条数据，这是比较尴尬的。写入写出依赖于设备和终端的响应，所以请求过程中为避免连续操作造成数据丢失，建议每一条指令之间追加一个时间间隔。
   （5）微信小程序之坑：这个其实想想也很正常，在微信小程序中，ble显得不是那么稳定，处理过程加长，数据丢失几率也会增加，建议在处理过程中重复尝试几次以保证数据有效性。

最后的话语

（1）这是我第一次发布内容，内容难免有些冗余甚至错误。在此对于出错之处望广大网页批评指正。
（2）由于这是个人感悟，作品属于公司，在此无法贴出完整源码与之分享，望谅解！