实现iOS长时间后台的两种方法：Audiosession和VOIP

我们知道iOS开启后台任务后可以获得最多600秒的执行时间，而一些需要在后台下载或者与服务器保持连接的App是如何突破600秒的限制的呢？像网易公开课就可以在后台持续下载，优酷也可以在后台持续缓存，这是怎么做到的呢？一般来说，要实现iOS长时间后台运行，需要声明VOIP、Audio或GPS。

 

Audiosession

 

实现方法很简单，就是在后台一直播放一个无声的音乐文件，这样就相当于声明了Audio，就可以轻松突破600秒的限制了。

 

通过播放“静默”音让程序在后台执行的做法（即在audiounit回调函数中使用kAudioUnitRenderAction_OutputIsSilence标志位），虽然确实可以实现后台执行，但实践中限制很多。最大的问题就在于程序的audiosession不能被打断。当程序执行在后台时，只要另一个程序使用kAudioSessionCategory_RecordAndPlay（比如Skype）或者kAudioSessionCategory_SoloAmbientSound（印象中使用这个session的不多），那么本程序就会被立即打断。

 

打断本身不是问题，但当播放程序被打断时，唯一能够获得的只有处理audiosessioninterruption的很短一段时间。我的实验测试大概是3到5秒，但因为程序随后立即暂停，无法挂调试器，所以很难准确估计，然后程序就会被立即转入休眠状态。这点时间和applicationDidEnterBackground回调函数所用的时间大体相当，但是因为这个打断中间还伴随一个播音的回调动作，程序结构不是很好组织，在很多情况下是不够做现场保存工作的。

 

不推荐播放“静默”音的另一个问题它的恢复播放需要的场景非常麻烦。比如当一个iOS程序在后台被VOIP唤醒时，它是不能直接获得audiounit重新开始播音的。如果此时调用AudioOutputUnitStart()，会返回一个错误码，哪怕前台没有任何一个程序在运行也是如此。此时你不可能让程序重新进入稳定运行状态。有些没经验的程序员喜欢利用audiosessioninterruptionhandler做所谓的自动播放恢复，但他们其实都没有注意到audiosessioninterruption的状态恢复回调并不会保证被调用。目前实测能自动恢复调用的，大概也就只有内建的电话拨号程序，以及一些非常特殊的场景（比如你用一个MP3播放器打断audiosession，然后杀掉MP3播放器进程，然后把被打断的程序重新置回前台）。这样经常导致的结果，就是你开心地发现程序没问题，然后在放进生产环境中发现各种时不时的崩溃或启动失败。

 

VOIPsocket

 

VOIPSocket可以在后台运行。当程序进入后台时，事实上整个程序被暂停运行，但VOIPsocket因为受系统控制而不在此列。我的观察是，每次有新的数据来临时，程序会被唤醒并执行大约几秒钟，然后再次进入休眠。Stackoverflow上的说法是10秒钟，但我不确定，可能是我的试验不够精确。

 

参考资料：知乎   StackOverFlow   AppleDevCenter