iOS —— APP长时间后台
来源:互联网 发布:数据库union用法 编辑:程序博客网 时间:2024/05/17 06:20
这样久了,便是一种习惯。
iOS后台任务后最多600秒的执行时间,若在后台下载或与服务器保持连接的App需要突破600秒限制。
iOS长时间后台运行:VOIP、Audio、GPS。
1、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播放器进程,然后把被打断的程序重新置回前台)。这样经常导致的结果,就是你开心地发现程序没问题,然后在放进生产环境中发现各种时不时的崩溃或启动失败。
2、VOIPsocket
VOIPSocket可以在后台运行。当程序进入后台时,事实上整个程序被暂停运行,但VOIPsocket因为受系统控制而不在此列。我的观察是,每次有新的数据来临时,程序会被唤醒并执行大约几秒钟,然后再次进入休眠。Stackoverflow上的说法是10秒钟。
参考资料:知乎 StackOverFlow
- iOS —— APP长时间后台
- GCD 保持iOS app后台长时间运行
- ios 长时间后台
- iOS后台长时间执行
- ios后台长时间运行
- ios实现长时间后台运行
- ios实现长时间后台运行
- ios实现长时间后台运行
- ios实现长时间后台运行
- ios实现长时间后台运行
- iOS后台长时间运行解决方案
- iOS实现长时间后台运行
- iOS进入后台长时间运行后台任务
- IOS后台长时间运行的多种方法
- 关于iOS后台长时间挂起的方法
- iOS 程序后台运行保持程序后台长时间运行
- ios7以后如何实现App长时间后台运行
- IOS App 后台运行
- TCP 三次握手
- Python build-in大全
- 我太执著,把双方都逼到了绝路上
- maven编译时指定jdk版本
- 求单向链表第K个节点
- iOS —— APP长时间后台
- iOS:安全判断 respondsToSelector
- Android开发_Camera应用
- nginx学习之rewrite(重写)
- webservice 接口的实现和实现过程所遇到的问题!!
- 【整理】MySQL引擎
- 指针应用多维数组指针笔记
- FAQ
- ios安全小结