本文主要是介绍Android TV连续多次切换信源断电重启 切信源异常，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
问题描述：在TV端 连续多次切换信源后断电重启，TV重启后并没有进入最后一次切到的信源，而是进入了倒数第二次切到的信源。
具体操作：打开信源菜单-选择HDMI1-打开信源菜单-选择HDMI2-打开信源菜单-选择TV，如此循环往复操作数次，倒数第二次的信源是TV，最后一次的信源是HDMI2。随后在HDMI2信源下断电重启。
预期现象：断电重启后，TV当前信源为HDMI2。
实际现象：断电重启后，TV当前信源为DTV。
分析：通过日志信息分析在Android应用层执行的切信源流程是正确的，中间件同事通过LOG分析，中间件的流程也是正确的。中间件断电前后的日志如下：
断电前：
断电后：
可以看到，断电前执行了切换到HDMI2信源的动作，并做了将当前信源保存到db文件的动作。但是断电后从db文件取到的上次的信源却是DTV，这是为什么呢？
从前面的分析，这个问题可以简单归纳一下：切信源后马上断电再开机，数据库中保存的信源读出来还是切换前的信源，导致系统开机执行的还是切换前的信源。
这是操作系统策略问题，操作系统在写flash的时候，为了提高系统效率和减少磁盘写次数，都会有“延迟写”的机制：
当写flash时，首先写入缓存，当达到一定条件，例如缓存满或者重用缓存时，才会真正通过实际I/O写到flash。
所以切换信源后马上断电，数据库中保存的数据有时还没有真正烧到flash中，所以会丢失。
如前面分析，系统延迟写机制的原因，目的是保证系统效率和延长flash寿命，副作用就是会出现这种断电后数据没有及时更新到flash的情况。
上层会保证写数据的原子性，即相关数据要么全部写入，要么全部没有写入，从而使断电开机后即使没有保存上次的数据，也不会出现其他异常。
这篇关于Android TV连续多次切换信源断电重启 切信源异常的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
