We know that IOS can get a maximum execution time of 600 seconds after enabling background tasks. How do some apps that need to be downloaded in the background or kept connected to the server exceed the limit of 600 seconds? For example, Netease open classes can be used for continuous download in the background, and Youku can also continue caching in the background. How does this happen? Generally, to enable Ios to run in the background for a long time, you need to declare VoIP, audio, or GPS. The audiosession implementation method is very simple, that is, playing a silent music file in the background, which is equivalent to declaring audio, and can easily break through the limit of 600 seconds. The practice of enabling programs to execute in the background by playing the "silent" sound (that is, using the kaudiounitrenderaction_outputissilence flag in the audiounit callback function). Although it can indeed implement background execution, there are many restrictions in practice. The biggest problem is that the audiosession of the program cannot be interrupted. When the program is executed in the background, the program will be immediately interrupted as long as another program uses kaudiosessioncategory_recordandplay (such as Skype) or kaudiosessioncategory_soloambientsound (not many sessions are used in the impression. Interrupt itself is not a problem, but when the playing program is interrupted, only a short period of time can be obtained for processing audiosessioninterruption. My experiment test is about 3 to 5 seconds, but because the program is immediately paused and cannot be mounted to the debugger, it is difficult to accurately estimate, and then the program will be immediately transferred to the sleep state. This time is roughly the same as the time used by the applicationdidenterbackground callback function, but the interrupt is accompanied by a broadcasting callback action, and the program structure is not very well organized, in many cases, on-site storage is not enough. It is not recommended to play silent sound. Another problem is that it is very troublesome to Resume playback. For example, when an iOS program is awakened by VoIP in the background, it cannot directly obtain audiounit and start broadcasting again. If you call audiooutputunitstart () at this time, an error code is returned, even if no program is running at the front end. At this time, you cannot re-enter the stable running state of the program. Some inexperienced programmers like to use audiosessioninterruptionhandler for automatic playback recovery. However, they do not notice that the callback of audiosessioninterruption status is not guaranteed to be called. Currently, only built-in dialing programs and some special scenarios can be automatically resumed. For example, you can use an MP3 player to interrupt the audiosession and then kill the MP3 player process, then, reset the interrupted program to the front-end ). The result is that you are happy to find that the program is okay, and then you can find various crashes or startup failures from time to time in the production environment. Voipsocket can be run in the background. When the program enters the background, the entire program is actually suspended, but voipsocket is not included in this column because it is controlled by the system. My observation is that every time new data comes to the fore, the program will be awakened and executed for about a few seconds, and then enter sleep again. The statement on stackoverflow is 10 seconds, but I'm not sure, maybe because my experiment is not accurate enough. Reference: zhihu stackoverflow appledevcenter
Http://www.cocoachina.com/applenews/devnews/2012/1212/5313.html
