转载(http://www.cnblogs.com/xiaorenwu702/p/4307380.html)
开发Ble（公司项目，防丢器）已经有一段时间，由于是第一次接触Ble而网上资料又不多，且android平台自身的差异性，遇到了很多问题。为了将来方便查阅，在此做下记录。
1.中兴手机，蓝牙手动断开后，无法再次链接问题。（可能别的手机也存在类似问题）解决办法： 在连接gatt之前，对bluetoothadapter进行一次scan 顺利解决此问题。
2.Gatt链接不稳定（在部分手机上出现过，此问题先排除硬件问题。此处只针对自己遇到的情况，或许有别的方案，待补充）解决办法： 由于用到了gattserver，在启动gattserver和连接gatt之间由于未做顺序的限制，导致了此问题。经过反复调试后，发现只需要先创建gattserver，在serviceadded之后，在去进行gatt链接，此时的gatt连接会比较稳定。
3.小米手机遇到的，在gatt连接之后，手动调用gatt.disconnect 和 close。第二次链接后 自动断开，再次连接会重新绑定。解决办法：也是无意中，看到一篇文章，写的是小米手机在gatt操作的时候 ，最好要做一下sleep操作，可能是因为小米底层对蓝牙的某些东西没有来得及释放(自己猜测)。 于是在gatt 连接上时，在gatt.discoverServices 之前，加上 sleep(500) ，发现断开后在连接 成功率大大提高。
4.蓝牙关闭和打开变得异常缓慢，甚至崩溃此问题可能与当蓝牙关闭时，尚有为关闭的 gatt连接/gattserver。我的解决办法是，注册蓝牙状态的监听，当发现蓝牙状态变为BluetoothAdapter.STATE_TURNING_OFF 时，立刻释放所有的gatt连接，关闭gattserver。经不完全测试发现，蓝牙的关闭速度变得快多了。
5.当批量连接蓝牙时，不进行onConnectionStateChange 回调。这个问题是自己 闲的蛋疼，在测试的时候，用了很多假的mac 地址。于是造成的后果可想而知，肯定的是连不上的。但是同时也发现了问题，当ble去连接一个不存在的mac，或者不在范围内的mac地址时，发现有时候 不会进行onConnectionStateChange的回调，觉得很蛋疼。个人觉得会不会是因为 ，同时发送的connectGatt 请求太多，导致了系统的蓝牙阻塞或者别的什么问题。没办法，既然发现了这个问题，就只好动手解决了。 首先，我在批量连接connectGatt的时候，新增了一个扫描，只有当 要连接的 设备扫描到了，才进行连接。然后，我还对gatt的连接，做了一个同步(每次只能进行一个连接，上一个连接不结束的话，无法开始上一个连接，同时针对连接无回调的情况做了超时处理，超时的话立马释放当前连接)。 这么说可能感受不是很直观。但个人觉得，在操作手机蓝牙的时候，还是做个同步的好。 避免同时发生多个gatt的操作，倒是手机蓝牙奔溃等情况的发生。
6.Gatt链接不稳定 二最近因为在保存gatt连接状态的serveice中，增加了一个后台的lescan，突然发现gatt连接又变的不稳定了，不知道什么原因。走投无路的情况下，把后台的lescan放到另一个service中进行，发现好像gatt又变得稳定多了，目前测试下来 已经连了40分钟没有断开了。 不知道接下去会咋样。 也不知道是不是因为在同一个线程中在gatt连接成功后，开启lescan会导致连接不稳定，或亦是手机本身的原因，希望高人指教。
还是上面的问题，今天早上来，又重试了后台扫描和gatt连接，发现又有两次断开，诶。。。。 郁闷，求高人指教了。以上发现的问题，均为个人开发经验所得，如有不妥或者欠缺错误的地方，请大家指正批评。
来源： http://www.cnblogs.com/xiaorenwu702/p/4307380.html
