闭包与代理,编程内功二者兼修

最近一个多月在疯狂赶版本,写了大量的代码,用了大量的block。回过头来看,我认为自己过于依赖block了,于是以此文给后来人点建议和参考。

第一部分 局部作用域block

block本身是个好东西,它可以方便地将一段回调代码当成参数传入一个方法,在只需要一个回调调用时尤其高效,省去了定义class级别的protocol的繁琐。为调整坐标代码块加动画,统一时长,如下所示:


  这样的block永远不存在内存问题。因为从参数传入的block,在回调完后就释放了,生命周期同局部变量。

第二部分 有管理器专门维护引用的block

    CZKLoadingView.showInContextView(AppDelegate.instance().window, withLoadingText: StrLoginning)
    RequestLogin().request(phone, passwd: passwd, type: LoginType.Phone, successCallback: { (code, msg) in
        CZKLoadingView.dismiss()
        if code == 0 {
            self.passwordTextField.text = ""
            NSNotificationCenter.defaultCenter().postNotificationName(NotificationLoginSuccessfully, object: self)
            delay(1) {
                self.navigationController?.popToRootViewControllerAnimated(false)
            }
        } else {
            if !isEmptyString(msg) {
                SVProgressHUD.showErrorWithStatus(msg)
            }
        }
        
        }, failureCallback: { (errorMsg) in
            CZKLoadingView.dismiss()
            SVProgressHUD.showErrorWithStatus(errorMsg)
    })

上面那段代码,虽然请求是局部变量,但请求会被加入到sessionManager的队列中,请求完成才会被移出队列。因此可以直接在block中使用self,生命周期不会出现循环引用的问题。但下面这段代码不同:

    weak var weakSelf = self
    SingleImagePickerAdapter.pickSingleImage(contextVC) { (image) in
        //获取图片后,进入裁剪步骤
        let imageCropTool = ImageCrop()
        imageCropTool.delegate = weakSelf
        imageCropTool.ratioOfWidthAndHeight = 320.0 / 320.0
        imageCropTool.image = image
        imageCropTool.showWithAnimation(false)
    }

上述代码的目的,是为了封装请求一张图片到拿到一张图片的处理过程,那么问题来了,先看需求。
  app需要支持从相册选择和拍照两种方式获取图片,而这两种方法都需要在发起操作后等待系统UIImagePickerController异步回调,回调中才能知道是拍照还是选择相册里的图片,以及相册访问权限申请结果是成功还是失败。如果在“我的”界面上传头像时写一遍完整的UIImagePickerControllerDelegate实现;然后相册上传时来一遍;哈哈,还有聊天页面发送图片时,再来一遍;什么,使用某些功能前还需要确保自己有头像,支持快捷上传?
  聪明的软件设计,在此处绝对需要祭出“封装”这个大杀器,把这些重复操作归集到一个逻辑单元中,我将其命名为“adapter适配器”。上述代码中的SingleImagePickerAdapter就是一个适配器,发起操作后,只需要接收一个回调,回调中带来产生的一张图片,就可以方便的完成高内聚低耦合、减少重复工作的目的。
  但是这里有个问题,adapter不像请求那样,有专门的SessionManager去管理队列中的请求,完成就移出队列
;adapter没有任何更大的容器来引用它,当发起操作弹出UIImagePickerController后,局部变量adapter的生命周期就已经结束了,它会立即释放分配给它的内存,于是乎UIImagePickerController回调时,接收回调的对象没有了。
  这时有人就会说,你可以把adapter作为实例变量声明,哪里使用就在哪里保留强引用,像下面这样写:

//定义选取头像adapter变量
private var adatper: SingleImagePickerAdapter?

//开始选取头像的过程
func startHeadImagePickProcess(contextVC: CZKBaseViewController) {
    //打开照片选取来源提示框
    weak var weakSelf = self
    adatper = SingleImagePickerAdapter()
    adatper.pickSingleImage(contextVC) { (image) in
        weakSelf?.adatper = nil
        //获取图片后,进入裁剪步骤
        let imageCropTool = ImageCrop()
        imageCropTool.delegate = weakSelf
        imageCropTool.ratioOfWidthAndHeight = 320.0 / 320.0
        imageCropTool.image = image
        imageCropTool.showWithAnimation(false)
    }
}

没错,这样确实可以避免问题,但是使用时需要非常小心。第一,每次调用adapter的方法,都需要先声明变量、管理adapter的生命周期,使用成本增加了;第二,block代码块中,一定不能出现self,因为block如果对self有引用,那adapter一定要先释放,self才会释放,一旦遗漏就会出现内存泄露。最后,我在不断尝试中,发现了一个绝佳的解决方案,外部代码块定义中可以随便用self或weakSelf。这个方案的特点就是在adapter内部做繁琐的callback生命周期管理,但外部调用非常简单。就是在adapter类定义中,使用静态变量引用当前正在生效的adapter,一旦不再需要这个adapter,就置它为nil。设计思想类似于几年前Objective-C中的MRC内存管理原则。这样一旦RunTime检测到adapter对象不再有强引用指向它,就会立即释放adatper,从而切断adapter的callback对代码块中对象的强引用。如下图:

声明类方法,支持快速发起获取图片操作,并保持adapter引用
UIImagePickerController回调完成清空adapter

第三部分 多回调时,代理协议更好

block既然这么好用,那是不是任何情况都可以用block呢?当然不是。试想一下,如果一个管理器,需要有很多回调,这时block就没法完成多回调的高效管理。像tableView那样多的回调方法,最好的选择还是代理协议。在现在的项目里,也出现了很多回调方法的类,比如自定义控件,以及下面如图所示的SNS平台相关功能的回调:

SNS管理器的回调

以上就是自己使用block的一些体会。当一个问题在量级小时也许怎么解决都不会有太大的负面代价,但当一段代码、一种问题的解决过程,需要在很多地方使用时,代码的健壮性表露无遗,因此根据使用场景确定技术方案非常关键。
  没有最好的技术,只有最合适的技术。

推荐阅读更多精彩内容