《Effective Objective-C 2.0》读书笔记（

第6章 块与大中枢派发

提到块，建议去看看block的内部原理这个自己百度吧。
block时如何捕获变量的。不使用__block如何改变局部变量。

第37条：理解“块”这一概念

      如果想在block中改变block 外的局部变量需要使用__block。如果是成员变量则不需要，但是要注意在block捕获成员变量的同时，self这个对象也被捕获了。
      块分为全局块、栈块、堆块。

void(^block)(void);
    if (sss) {
        block = ^(){
            NSLog(@"Block A");
        };
    }else{
        block = ^(){
            NSLog(@"Block B");
        };
    }
    block();

//定义在if及else语句中的连个块都分配在栈中，编译器会给每个块分配好栈内存，然而等离开了相应的范围之后，编译器有可能把分配给块的内存覆写掉。有可能引发崩溃
void(^block)(void);
    if (sss) {
        block = [^(){
            NSLog(@"Block A");
        } copy];
    }else{
        block = [^(){
            NSLog(@"Block B");
        } copy];
    }
    block();
//为解决以上问题 使用copy把在栈中的block拷贝到堆中，一旦复制到堆中，block的内存就不再由系统分配了，加入了ARC的引用计数，当引用计数将为0时，bock才会被回收。

全局块，这种块不会捕捉任何状态（比如外围的变量等）。运行时也无需有状态来参与。块所使用的整个内存区域，在编译期已经完全确定了，因此全局块可以声明在全局内存中里，而不需要在每次用到的时候于栈中创建，另外全局块的拷贝是个空操作，因为全局块决不可能为系统所回收。这种块实际相当于单例。

void(^block)(void)= ^(){
        NSLog(@"This is a block");
    };

由于运行该块所需的全部信息都能在编译期确定，所以可把它做成全局块。这完全是中优化技术：若把如此简单的块当成复杂的块来处理，那就回在复制及丢弃该块时执行一些无谓的操作。

要点

• 块是C、C++、Objcet-C中的词法闭包。
• 块可接受参数、也可返回值。
• 块可以分配在栈或者堆上，也可以是全局的。分配在栈上的块可拷贝到堆里，这样的话，就和标准的Object-C对象一样，具备引用计数了。

第38条：为常用的块类型创建typedef

要点

• 以typedef重新定义块类型，可以令块变量用起来更加简单。
• 定义新类型时应遵从现有的命名习惯，勿使用其名称与别的类别的类型相冲突。
• 不妨为同一个块签名定义多个类型别名。如果要重构的代码使用了块类型的某个别名，那么只需修改相应typedef中的块签名即可，无需改动其他typedef。

第39条：用handler块降低代码分散程度

与委托模式的代码相比，用块写出来的代码显然更整洁。
要点

• 在创建对象时，可使用内联的handler块将相关业务逻辑一并声明。
• 在有多个实例需要监控时，如果采用委托模式，那么经常要根据传入的对象来切换，而若改用handler块来实现，则可以直接将块与相关对象放在一起。
• 设计API时如果要用到了handler块，那么可以增加一个参数，使调用者可通过此参数来决定应该把该块安排在哪个队列上执行。

第40条：用块引用其所属对象时不要出现保留环

要点

• 如果块所捕获的对象直接或间接地保留了块本身，那么就得当心保留环问题。
• 一定要找个适当的时机解除保留环，而不能把责任推给API的调用者。

第41条：多样派发队列，少使用同步锁

执行异步派发时，需要拷贝块。若拷贝块所用的时间明显超过执行块所用的时间，这种方法将比原来更慢。

要点

• 派发队列可用来表述同步语义（synchronization semantic），这种做法要比使用@synchronized块或NSLock对象更简单。
• 将同步与异步派发结合起来，可以实现与普通加锁机制一样的同步行为，而这么做却不会阻塞异步派发线程。
• 使用同步队列及栅栏块，可以令同步行为更高效。

第42条：多用GCD，少用performSelector系列方法

Object-C是一门动态语言，使用performseletor方法与直接调用方法的区别是，直接调用需要在编译期提前声明好该方法，如果未声明会报错。而performseletor这是在运行期动态调用方法。
要点

• performSeletor系列方法在内存管理方面容有疏失。它无法去定将要执行的选择子具体是什么，因而ARC编译器也就无法插入适当的内存管理方法。
• performSeletor系列方法所能处理的选择子太过局限了，选择子的返回值类型及发送给方法的参数个数都收到限制。
• 如果想把任务放在另一个线程上执行，那么最好不要用performSeletor系列方法，而是应该能把任务封装到块里，然后调用大中枢派发机制的相关方法来实现。

第43条：掌握GCD及操作队列的使用时机

使用NSOperation及NSOperationQueue的好处如下：

• 取消某个操作
• 指定操作间的关系
• 通过键值观察机制监控NSOpertaion对象的属性
• 指定操作的优先级

要点

• 在解决多线程与任务管理问题时，派发队列并非唯一方案。
• 操作队列提供了一套高层的Object-C API，能实现纯GCD所具备的绝大部分功能，而且还能完成一些更为复杂的操作，那些操作若该用GCD来实现，则另外编写代码。

第44条：通过Dispatch Group机制，根据系统资源状况来执行任务

要点

• 一系列任务可归入一个dispatch group中。开发者可以在这组任务执行完毕时获得通知。
• 通过dispatch group，可以在并发式派发队列里同时执行多项任务。此时GCD会根据系统资源状况来调度这些并发执行的任务。开发者若自己来实现此功能，则需编写大量代码。

第45条：使用dispatch_once 来执行只需要运行一次的线程安全代码

要点

• 经常需要编写“只需要执行一次的线程安全代码”。通过GCD所提供的dispathc_once函数，很容易就能实现此功能。
• 标记应该声明在static或global作用于中，这样的话，在把只需执行一次的块传给dispath_once函数时，传进去的标记也是相同的。

第46条：不要使用dispath_get_current_queue

要点

• dispatch_get_current_queue函数的行为常常与开发者所预期的不同。此函数已经废弃，只应该做调试用。
• 由于派发队列是按层级来组织的，所以无法单用某个队列对象来描述“当前队列”这一概念
• dispatch_get_current_queue函数用于解决由不可重入的代码所引发的死锁，然而能用此函数解决的问题，通常也能改用“队列特定数据”来解决。