以前的电视都是红外遥控器来进行电视的遥控，主要依托于电视上的红外模块和遥控器上的红外模块进行通信，进行按键的接收。
随着技术的演进，蓝牙遥控器已经成为主流。得益于功耗低，操作更灵敏，续航时间久等优点，目前市面上主流的电视基本都是蓝牙遥控器并且带语音操作功能。
另外，最强大的是市面上的部分电视已经用上全蓝牙遥控器的解决方案，电视已经完全取消了红外接收，全靠蓝牙通路进行遥控。
产品痛点和可靠性要求：因为电视如果取消掉红外接收头后，没有蓝牙遥控器进行连接的时候，电视是无法进行正常使用的，所以就需要在电视没有蓝牙遥控器配对信息的时候去提示用户进行遥控器的连接操作，正常使用时如发现有异常断开也需要有对应的提示，对此功能的依赖非常强，如果遥控器无法连接，则电视变砖。
最近在做全蓝牙遥控器的时候，有下面两个核心问题需要解决掉：
1、电视开机后如果没有蓝牙遥控器连接，此时的电视无法进行操作，需要弹出蓝牙的配对界面提示用户去进行遥控器的连接；（主动自检）
2、在蓝牙遥控器已经连接上电视后，如果在平时的使用过程中发生蓝牙遥控器断开，或者电视端配对信息异常丢失的时候，需要有提示或者弹出配对界面让用户重新连接。（被动检测）
在处理问题1时，开机后发现随机出现无法唤起配对界面。
常驻Service A（Mainfest含有Persist属性）会在在开机完成后自启动，启动时会去检测系统有无蓝牙遥控器进行连接，如果没有连接的话会去启动APP B中的配对界面中让用户去进行蓝牙遥控器的连接。
最初的思路是Service A发隐式广播出去，APPB 收到此广播后，然后做逻辑去决定是否要启动配对界面。但此种方式实验后，发现经常在开机的时候广播发出来后会一直会卡住，无法正常分发出去，往往过上很久APP B才会收到去启动配对界面B。刚开机完成后，自己手动用命令发送广播发现也是这种现象。
猜测可能是开机的时候系统CPU比较繁忙，导致处理不过来，广播也会卡好久。
果断重新换了一种方法，通过隐式调用Action启动配对界面。
将APP B中决定是否需要启动配对界面的逻辑挪到Service A中去，Service A做完逻辑后通过发配对界面对应的Action来启动APP B中的配对界面。Action方式实验后开机配对界面启动正常。（不太建议直接用包名+类名启动，显示调用导致后面维护起来难度增大）
问题2 出现蓝牙遥控器断开后检测流程会跑很多次，导致状态混乱。
a. 开机后首先会在Service A中注册蓝牙遥控器连接状态改变的广播在后台监测遥控器的状态变化。因为蓝牙遥控器符合蓝牙的HID协议，我们可以
利用广播android.bluetooth.input.profile.action.CONNECTION_STATE_CHANGED
和BluetoothProfile.ServiceListener 监听者的回调来检查遥控器是否有正常连接。
b.检测蓝牙遥控器有无连接的时候会利用HandlerThread开启一个线程来进行遥控器相关状态的处理，连接成功后注销掉此线程。发现在遥控器状态发生变化的时候会重复多次调用此线程导致检测线程经常多跑几次，比较混乱，本来想利用变量控制是否有在线程中，发现效果并不好。
后面改进了一下，如果发现HandlerThread已经在isAlive运行的时候，就不再做重复的检测动作，验证可以满足条件。
自己验证了一下基础功能基本稳定，经过测试同事的测试后，就看后面的稳定性和可靠性了~