- 《Effective Objective-C 2.0》之《blo
- Effective Objective-C 2.0笔记(二)
- Effective Objective-C 2.0笔记(一)
- Effective Objective-C 2.0笔记(三)
- Effective Objective-C 2.0笔记(五)
- 《Effective Objective-C 2.0 》 阅读笔
- Effective Objective-C 2.0 无废话精简篇
- Effective Objective-C 2.0 脑图- [O
- Effective Objective-C 2.0 再读笔记(三
- Effective Objective-C 2.0 再读笔记(四
理解“块”这一概念
要点
- 块是C、C++、Objective-C中的词法闭包
- 块可以接受参数、也可返回值
- 块可以分配在栈或堆上,也可以是全局的。分配在栈上的块可以拷贝到堆里,这样的话,就和标准的Objective-C对象是一样的,具备引用计数了
关于块原理的说,可以参加我的文章说说Objective-C中的block
为常用的块类型创建typedef
要点
- 以typedef重新定义块类型,可令块变量用起来更加简单
- 定义新类型时应遵循现有的命名习惯,勿使用其名称与别的类型冲突
注:用当前类名最为block的前缀名,防止block名冲突 - 不妨为同一个块签名定义多个类别名。如果要重构的代码使用了块类型的某个别名,那么只需要修改相应的typedef中的块签名即可,无需改动其他typedef
注:虽然block内容相同,但是为了以后方便修改,根据用途分散block,用不同的别名
用handler块降低代码分散程度
要点
- 在创建对象时,可以使用内联的handler块将相关业务逻辑一并声明
注:相当于使用AFNetworking的block回调 - 在有多个实例需要监控时,如果采用委托模式,那么经常需要根据传入的对象来切换,而若改用handler块来实现,则可直接将块与相关对象放在一起
注:相当于以前使用ASHttpRequest时,如果一个UIController中使用ASI发了多个请求,则需要在其请求回调中,根据请求的tag来区分请求,这样请求回调代理里就会随着请求的增多变得愈发混乱 - 设计API时,如果用到了handler块,那么可以增加一个参数,使调用者可通过此参数来决定应该把块安排在哪个队列上执行
用块引用其所属对象时不要出现循环引用
要点
- 如果块所捕获的对象直接或者间接地保留了块本身,那么就得当心循环引用问题
- 一定要找个适当的时机接触循环引用,而不能把责任推给API的调用者。
注:如可以使用以下代码,回调结束后,强制将completionHandler属性清理干净。
- (void)p_requestCompleted {
if (_completionHandler) {
_completionHandler(_downloadedData);
}
self.completionHandler = nil;
}
关于block循环引用的问题,可见iOS中block的循环引用问题
多用派发队列,少用同步锁
要点
- 派发队列可用来表述同步语义,这种做法要比使用@synchronized块或者NSLock对象更简单
- 将同步与异步派发结合起来,可用实现与普通加锁机制一样的同步行为,而这么做却不会阻塞执行异步派发的线程
- 使用同步队列以及栅栏块,可用令同步行为更加高效。
关于同步问题,可以参加我文档文章更高效的同步锁-GCD 同步锁
多用GCD,少用performSelector系列方法
要点
- performSelector系列方法在内存管理方面容易有疏失。它无法确定将要执行的选择子具体是什么,因而ARC编译器也就无法插入适当的内存管理方法
注:,如下代码ARC编译器就无法插入适当的内存管理方法
SEL selector;
if (/* some condition*/) {
selector = @selector(foo);
} else if (/* some other condition */) {
selector = @selector(bar);
} else {
selector = @selector(baz);
}
id ret = [object performSelector:selector];```
* performSeletor系列方法所能处理的选择子太过局限了,选择子的返回值类型以及发送给方法的参数个数受到限制
* 如果想把任务放在另一个线程上执行,那么最好不要用perfomSelector系列方法,而是应该把任务封装到块里,然后调用GCD相关的方法来实现
**注:**perfomSelector没办法指定执行的线程
####掌握GCD以及操作队列的使用时机
#####要点:
* 在解决多线程与任务管理问题时,派发队列并非唯一解决方案
* 操作队列提供了一套高层的Objective-C API,能实现纯GCD所具备的绝大多数部分功能,而且还能完成一些更为复杂的操作,那些操作若改用GCD来实现,则需要另外编写代码
**针对于NSOperation,可以参见[iOS多线程之NSOperationQueue](http://www.jianshu.com/p/52fe1b85c404)**
####通过Dipatch Group机制,根据系统资源状况来执行任务
#####要点
* 一系列任务可归入一个dispathc group之中。开发者可用在这组任务执行完毕时获得通知
* 通过disaptch group,可以在并发式派发队列里同时执行多项任务。此时GCD会根据系统资源状况来调度这些并发执行的任务。开发者若自己实现此功能,则需要编写大量代码
**关于dispatch group的详细说明,
可以参照[[iOS 多线程GCD之dispatch_group](http://www.jianshu.com/p/6faea7ef35bc)](http://www.jianshu.com/p/6faea7ef35bc)**
####使用dispatch_once来执行只需运行一次的线程安全代码
#####要点
* 经常需要编写”只需要执行一次的线程安全代码“,通过GCD所提供的dispatch_once函数,很容易就能实现此功能
**注:**diapatch_once最常用于单例的创建
* 标记应该声明static或global作用域,这样的话,在把只需要执行一次dispatch_once函数时,传进去的标记也是相同的
**注:**使用static是因为每次调用时都必须使用完全相同的标记,如果不使用static或者global,那就达不到只执行一次的效果了
####不要使用diaptch_get_current_queue
#####要点
* dispatch_get_current_queue函数的行为常常与开发者所预期的不同。此函数已经废弃,只应做调试只用。
* 由于派发队列是按层级来组织的,所以无法单用某个队列队形来描述“当前队列”这一概念
* dispatch_get_current_queue函数用于解决由不可重入的代码所引起的死锁,然而能用此函数解决的问题,通常也能用“队列特定数据”来解决
**关于diaptch_get_current_queue,之后会有专门的文章进行讲解**
网友评论