实现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秒钟,但我不确定,可能是我的试验不够精确。