iOS 后台机制探索

    iOS后台开发一直是比较头疼的问题。大部分的app是不需要考虑运行在后台的情况，推送已经满足绝大部分的需求。但是如果是做智能设备就需要考虑到这一块的功能。目前大部分语音类产品有app在后台运行的要求，需要app在后台的时候能进行人机对话或数据的处理，这个需求很正常，但是实现起来流程很长而且具有误导性。网上有很多关于后台保活的文章，大部分的方法都是通过voip，实时定位的方式来实现的，这些方式有很强的功能性，对于语音类产品几乎不通用。前段时间在做智能语音外设开发的时候，花了很长的事件进行了实验调研，踩了很多的坑，得出了以下的总结。

    首先，iOS的Background Mode一共有图1几种模式，使用场景也是显而易见。与语音相关的功能有2个，第1个和第3个，第一个用来听音乐，第三个是voip网络电话，我们的场景显然与这两种模式都不匹配。由于我的需求是可以通过外设去唤醒app去执行一些操作。所以流程是外设把音频传给app，app将反馈语音从耳机中播放出来。具体的流程如图2所示：

图1

图2

这是最简单的一种交互方式。一般外设与iphone的通讯都是通过ble或者是iap协议，这两者对于app层的模式基本一致，而且在图1中，这两种模式也对应各自的一种后台模式，ble对应第5个，iap对应4个。有了这个后台模式，我天然以为就是支持app保活了，不然这个模式有啥用，所以就觉得支持了这两种模式，语音在后台就跟在前台一样能正常经常语音交互的。然后就抱着这种错误的概念，一直在蹚坑。下面开始不同场景的测试。

1.由于一次意外，开始测试的是播放音乐兼语音打断对话场景。由于app里面支持音乐播放，第一个mode肯定是要勾选上，然后app到后台开始测试，分别5分钟，10分钟，20分钟的语音对话测试。结果意料之中的正常，过了1，2个小时也是正常的，天然以为事情到此为止了，一切理论正常。

2.测试不播放音乐，后台待机语音对话的场景。分别测试5分钟，10分钟，20分钟。结果5分钟正常，10分钟就没有回复了，还是有问题。

测试结果表示后台mode开启了还是有问题，可是问题触发的一系列链路很长，每个步骤都会出现问题，下面开始漫长的排查问题过程，要从以下几个方面去排查：

1).app是否被杀掉，是否是一直保活

2).app是否接受到语音指令，是否正确解析出来，送入语音识别sdk中

3).语音识别sdk有没有问题

针对第一个case，首先保活是个什么概念，当时的理解很浅显，每次进去不走启动页，在哪个页面一直在，这算是保活吧，事实上这是一种伪保活，属于低层次的保活。为了测试这个case，将外设连接手机，app在后台一个晚上后，发现进入app不走启动页，这就是理解中的保活，第一个case没问题，勾选mode确实能保活。

针对第二个case，只有去看日志，通过mac 上面的控制台可以看到连接的设备打印出来的所有日志，这里面还有坑的，swift的print不能打印出来，只有NSLog能打印出来。通过日志可以一目了然看到，后台的10分钟之后还是可以接收到外设发的信息，并且调用到了对应的开启对话的方法，那就说第二种case没有问题，那就只有第三种case。

针对第三种case，这时候我有理由怀疑是sdk里面的问题了，但是sdk开发人员说，你那不是真正的保活，你看看你后台起个定时器打印日志，看看定时器是不是一直都活着，我噎住了，定时器肯定在一定时间内也是会被kill掉的，我也写了代码去验证这个想法，事实确实如此，所以sdk开发人员说，如果定时器都不工作了，就不能保证你这个app是保活的。这确实是我的困惑，为什么在上面的第一种测试场景下，语音对话长时间就是可以的，这个怎么解释？

我们在网上搜索后台保活的机制的时候，好多人都说后台播放音频，当时理解的这个保活的概念与开启ble和iap的后台mode之后的保活应该是一致的。但是问题就来了，为啥第一种场景和第二种场景的测试会有区别。通过控制台的日志看出，每过10分钟，语音sdk的socket就会断开，我怀疑这个是不可控的，唯一可控的就是一个重连机制。但是无人认可，所以搭了一个websocket后台，就开始测试这种方式下后台的请求会不会有问题。通过测试发现刚进入后台10分钟的websocket都是可以正常请求到的，然后10分钟之后断开了，然后通过重连机制，连接上了，继续请求没有问题，如此来了几个回合，确实是正常的，这就可以得出结论了，网络连接在后台的断开是不可控的，可控的是 在断开的时候能主动连接上，这是一个很重要的结论，用来说服语音sdk开发人员。

但是还有一个问题就是播放音乐的时候，为啥能正常语音通话？  这是因为在播放音乐的时候，苹果是不会关闭socket连接的，这是一个例外，而且不仅仅是播放网络音乐，播放本地音乐也不会断开网络连接的，这算是苹果的一种机制。想到这个，所有的问题都通了，瞬间放晴。

所以下面来总结以下：

1.图1的后台模式确实能让app保活，但是这是一个浅保活，这种状态下app确实不会被kill掉，也能履行相应的职责，比如说在ble模式和iap模式下，能接收到传输过来的数据，但是网络请求都会被干掉，只保留这一种单一的职责，但是接受到了相应的数据之后，会有几十秒时间去执行网络连接或者数据处理的操作。

2.第一种后台模式能保持后台socket不断，源源不断请求数据。

补充以下：

在后台外设能进行语音对话，一共有两种模式

1.就是上面所说的，语音数据通过ble或iap传输到app端，进行数据处理

2.开启语音的指令通过ble的事件发送，纯粹发送指令，在app接受到指令时，后台切换音频模式为record，这样可以通过手机端录音获取到音频，结束之后再切换音频模式为playback，这种模式是可行的，万魔耳机就是这种模式，但是在ios12以上，权限变了，后台开启record模式会失败，所以说高版本这种方式是不可行的。

结语：

在这个过程中，试过各种方法，添加后台任务，不可行，后台任务确实会让app多存活一段时间，不同机型不一样，一般最高10分钟左右，超过10分钟，苹果的watch dog就会全部kill掉，所以说不要对apple的后台机制存有各种幻想，我之前就是幻想太多了。