最近一个多月在疯狂赶版本，写了大量的代码，用了大量的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对代码块中对象的强引用。如下图：
第三部分 多回调时，代理协议更好
block既然这么好用，那是不是任何情况都可以用block呢？当然不是。试想一下，如果一个管理器，需要有很多回调，这时block就没法完成多回调的高效管理。像tableView那样多的回调方法，最好的选择还是代理协议。在现在的项目里，也出现了很多回调方法的类，比如自定义控件，以及下面如图所示的SNS平台相关功能的回调：
以上就是自己使用block的一些体会。当一个问题在量级小时也许怎么解决都不会有太大的负面代价，但当一段代码、一种问题的解决过程，需要在很多地方使用时，代码的健壮性表露无遗，因此根据使用场景确定技术方案非常关键。
没有最好的技术，只有最合适的技术。
