赞
踩
蓝牙服务层的使能基础是其初始化完成,也就是AdapterService通过onBind()将AdapterServiceBinder上报给bind该服务的调用者。我们现在应该都知道在安卓系统中bind该服务的为BluetoothManagerService。本篇我们就从蓝牙服务管理收到bind的回调开启蓝牙使能流程的分析。
熟悉安卓系统中bind服务机制的小伙伴应该都知道,该bind调用会连同回调函数ServiceConnection一起下发给系统,这样服务bind成功后通过该回调上报到对应的调用层,在蓝牙系统里就是蓝牙服务管理。通过如下转换蓝牙服务管理就获取到蓝牙服务层AdapterService的函数接口:
IBinder service = (IBinder) msg.obj;
mBluetooth = IBluetooth.Stub.asInterface(Binder.allowBlocking(service));
随着蓝牙服务层接口的取得,就会接着执行蓝牙使能的操作
服务层使能的具体流程可以参照如下时序图:
从以上时序图大概能总结出蓝牙服务层使能基本上分为三个步骤:
蓝牙状态涉及到如下状态值及含义:
集合整个蓝牙打开基本上先打开低功耗蓝牙BLE,再打开传统蓝牙BT,所以蓝牙的状态变化为:
10 -> 14 -> 15 -> 11 ->12
反之,蓝牙关闭的状态变化为:
12 -> 13 -> 15 -> 16 -> 10
因此蓝牙整个的状态机就会根据不同场景和消息来及时切换到正确的状态机下执行相应的处理流程。
蓝牙服务层中定时器的设定有两个,分别对应低功耗BLE使能和传统蓝牙BT使能,超时时间都是4s,所以蓝牙底层在使能过程中耗费太长时间会同样会导致蓝牙打开失败(即使4s超时后底层蓝牙使能成功,也算失败)。
从时序图上可以看到BluetoothManagerService收到4次蓝牙状态的变化回调,但是一般应用在监听蓝牙状态变化的广播时,只能收到两次广播,分别为10 -> 11和11 -> 12 这2次蓝牙状态变化的广播。但这明明和时序图上的4次状态回调不一致啊?
其实是BluetoothManagerService自己做了处理,如果第三方应用是监听如下BLE状态改变的广播,则能完全一致的收到这4次广播。
但如果监听的是传统蓝牙状态改变的广播,则只能收到上述的10 -> 11和11 -> 12这2次广播。
BluetoothManagerService实例对象中对蓝牙状态广播的处理逻辑可以参考该方法bluetoothStateChangeHandler(),安卓系统里蓝牙状态改变的广播都是在这里广播出去的。
经过以上的分析,蓝牙服务层的使能我们已经有了一定的了解。流程是这么设计的,但有时还是会遇到些使能相关的莫名其妙的问题,根据过往的工作经验,我主要总结了如下几种问题:
所以蓝牙开发过程中遇到类似问题,还需一步步分析流程,确定问题根因发生在哪个环节并给出解决方案。
上述的蓝牙服务使能时序图只是简单梳理了下大概流程,其中的知识点甚多,比如各个支持的蓝牙协议服务的初始化我就一笔带过了,感兴趣的小伙伴不妨自己动起手来,一览安卓源码的设计之美,也欢迎私信留言一起讨论。
更多互联互通技术,欢迎关注微信公众号:Connectivity
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。