首页 | 开发 | Apple

ios – 关闭与代理模式

2019年12月01日 作者：佚名
我正在使用网络请求类,我担心崩溃.例如,当您将回调方法传递给函数时,使用闭包非常简单： 
// some network client
func executeHttpRequest(#callback: (success: Bool) -> Void) {
    // http request

    callback(true)
}

// View Controller
func reload() {
    networkClient.executeHttpRequest() { (success) -> Void in
        self.myLabel.text = "it succeeded" // NOTE THIS CALL
    }
}

然而,由于应该执行回调的进程是async,当回调与容器类元素(在这种情况下是UIKit类)交互时,它可能容易受到崩溃的影响,例如

>当异步任务仍然执行时,用户导航到另一个视图控制器
>当异步任务仍然执行时,用户按住主页按钮
>等等

所以,当回调最终被触发时,self.myLabel.text可能会导致崩溃,因为自我引用的View Controller可能已被释放.

到这一点.我是对还是快速地在内部执行某些事情,这样就不会发生？

如果我是对的,那么当代理模式派上用场时,代理变量是弱引用,这意味着如果被释放,它们不会保留在内存中.

// some network client

// NOTE this variable is an OPTIONAL and it's also a WEAK REFERENCE
weak var delegate: NetworkClientDelegate?

func executeHttpRequest() {
    // http request

    if let delegate = self.delegate {
        delegate.callback(success: true)
    }
}

注意如何self.delegate,因为它是一个弱引用,如果View Controller(谁实现NetworkClientDelegate协议)被释放,并且在这种情况下不调用回调,它将指向nil.

我的问题是：闭包有什么特别的,使它们在类似于这个场景中成为一个很好的选择,而不是回到委托模式？如果关闭的例子(由于nil指针而不会在崩溃中结束)的情况将是很好的.谢谢.

解决方法

So,when the callback finally gets fired,self.myLabel.text might result in a crash,as the View Controller to whom self was referring could already be deallocated.

如果将自己作为强有力的参考资料导入封闭件,那么保证在关闭完成执行之前,自我不会被释放.也就是说,当调用闭包时,视图控制器仍然存在,即使此时视图不可见.语句self.myLabel.text =“它成功”将被执行,但即使标签不可见,也不会崩溃.

然而,这是一个微妙的问题,在某些情况下可能导致崩溃：

假设闭包具有对视图控制器的最后且唯一的强参考.关闭完成,随后被释放,这也释放了最后强烈的参考视图控制器.这将不可避免地将调用视图控制器的dealloc方法. dealloc方法将在执行关闭的同一个线程上执行.现在,视图控制器是一个UIKit对象,必须保证发送到该对象的所有方法都将在主线程上执行.所以,IFF dealloc实际上会在其他线程上执行,你的代码可能会崩溃.

一个合适的方法将需要“取消”一个异步任务,其视图控制器在“关闭”时不再需要其结果.这当然要求你的“任务”可以取消.

为了减轻前一种方法的一些问题,您可能会在定义关闭时捕获视图控制器的弱引用,而不是强引用.这不会阻止异步任务运行到完成,但是在完成处理程序中,您可以检查视图控制器是否仍然存在,并且如果不再存在,则调用它.

而且,如果您需要在一些可能在某个任意线程上执行的闭包中“保持”一个UIKit对象,请注意这可能是最后一个强引用,并且确保这个最后一个强引用在主线程上被释放.

参见：Using weak self in dispatch_async function

编辑：

My question would be: do closures have anything special that makes them a good choice in scenarios similar to this one,rather than going back to delegate pattern?

我会说,关闭是许多用例中的“更好”的方法：

代表们更倾向于像循环引用这样的问题,而不是闭包(因为它们被一个对象“拥有”,而且这个对象可能被捕获为委托中的一个变量).

关闭作为完成处理程序的经典用例也改进了代码的“局部性”,使其更易于理解：您说明在调用任务的语句之后任务完成时会发生什么 – 无论可能需要多长时间.

关闭与常规“功能”的巨大优势在于,在定义时,闭包会捕获整个“上下文”.也就是说,它可以引用变量并在定义时将它们“导入”到闭包中,并且在执行时使用它,无论发生什么情况,当定义时间的原始“堆栈”消失时已经.

以上是来客网为你收集整理的ios – 关闭与代理模式全部内容，希望文章能够帮你解决ios – 关闭与代理模式所遇到的程序开发问题。

如果觉得来客网网站内容还不错，欢迎将来客网网站推荐给程序员好友。

相关链接