标签:
SDK并没有提供终止应用程序的方法。要想终止应用程序,苹果推荐的唯一的方式是按下Home按钮。
但是Foundation框架中集成了Darwin框架,从而我们可以使用C函数exit(0)来终止Application。当然这只是对于企业开发者而言。对于个人开发者,你这样做的唯一结果就是,你的应用将会被苹果商店拒绝。
UIApplication的openUrl方法则是退出应用程序的另一种方法。当你在代码中调用OpenURL方法时,你的App进程会被终止(挂起),另一个App则被唤醒。
当然两种退出App的机制和最终效果并不相同。当你使用exit(0)退出程序时,你的App并不仅仅是退出前台,程序所占用的内存也被清除了——这是不可恢复的。如果再次Launch这个App,iOS将重新从磁盘中读取二进制——这是一份全新的App映像。
openURL则不同,它仅仅是把你的程序挂起,这是可恢复的——你的App仅仅是从前台退出,但后台中仍然存在着。用户可以在某个时候“唤醒”它,于是你的App又回来了,此时应用程序的状态仍然唤醒之前的状态。当然,万一你运气不好,iOS也会将你的App彻底从内存中回收,一如exit(0)所做的一样——这一般是系统内存紧张的时候。
这两种方法在某些时候可能需要并存。例如,我们想在App退出之前,唤醒另一个App,比如Safari。同时我们希望自己的App是真正的“退出”,回收App的所有内存。
这是一个“悖论”。因为无论exit(0)还是openURL,一旦执行之后,操作系统就会终止进程的执行。只要执行二者中的任何一句语句,另外一个语句就无法执行——因为进程已经终止了。
但在某种情况下,通过对iOS多任务机制的巧妙利用,这个悖论却是真实成立的。
例如,我们可以利用如下O-C代码来实现这个目的:
[self performSelector:@selector(exitApp)withObject:nil afterDelay:0.5];
[[UIApplication sharedApplication]openURL:
[NSURLURLWithString:@"appScheme://"]];
exitApp方法实际上就是一句代码exit(0)。
这样二者就实现并存了。
首先,我们让exit(0)延迟0.5秒再执行,而在此之前openURL当然早就执行完了。
performSelector:afterDelay方法将会调度一个任务在某个时间后执行。当然,这个时间不能太长,因为iOS允许app在进入后台之后仍然有一段“存活”时间,但是这个时间不能太长,这样即算后面的openURL方法执行后,App仍然处于存活状态,也就有机会去执行所调度任务(即exit(0))。
这段代码在iOS 5以后都工作得很好。但不幸的是,Swift语言来了。
在Swift中,performSelector方法不再存在。
当然,我们立即想到了另一个替代方案,即GCD:
var dispatchTime: dispatch_time_t =dispatch_time(
DISPATCH_TIME_NOW,Int64(0.5 * Double(NSEC_PER_SEC)))
dispatch_after(dispatchTime,
dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND,0),
{
exit(0)
})
UIApplication.sharedApplication().openURL(NSURL(string:"appScheme://")!)
然而,这段代码根本不能工作。原因未知,很能是一个新的Bug,但我至今没有看到有人向苹果Radar过这个问题。
经过一番探索,我发现了让上述代码工作的方法,那就是将上述代码包裹在新的GCD异步块中:
dispatch_async(dispatch_get_main_queue(),{()->Voidin
var dispatchTime: dispatch_time_t = dispatch_time(DISPATCH_TIME_NOW,Int64(0.5 * Double(NSEC_PER_SEC)))
dispatch_after(dispatchTime, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND,0), {
exit(0)
})
UIApplication.sharedApplication().openURL(NSURL(string:"appScheme://")!)
})
标签:
原文地址:http://blog.csdn.net/kmyhy/article/details/42393125