重新学习《Effective Objective-C 2.0 编写高质量iOS与OS X代码的52个有效方法》
并做个学习笔记，第 5 - 6 章
目录：
第5章 内存管理
第29条：理解引用计数
第30条：以ARC简化引用计数
第31条：在dealloc方法中只释放引用并解除监听
第32条：编写"异常安全代码"时留意内存管理问题
第33条：以弱引用避免保留环
第34条：以"自动释放池块"降低内存峰值
第35条：用"僵尸对象"调试内存管理问题
第36条：不要使用retainCount
第6章 块与大中枢派发
第37条：理解"块"这一概念
第38条：为常用的块类型创建typedef
第39条：用handler块降低代码分散程度
第40条：用块引用其所属对象时不要出现保留环
第41条：多用派发队列，少用同步锁
第42条：多用GCD，少用performSelector系列方法
第43条：掌握GCD及操作队列的使用时机
第44条：通过Dispatch Group机制，根据系统资源状况来执行任务
第45条：使用dispatch_once来执行只需运行一次的线程安全代码
第46条：不要使用dispatch_get_current_queue
第 5 章 内存管理
第 29 条 理解引用计数
1）引用计数机制通过可以递增递减的计数器来管理内存。对象创建好之后，其保留计数至少为1.若保留计数为正，则对象继续存活。当保留计数降为0时，对象就被销毁了。
2）在对象生命期中，其余对象通过引用来保留或释放此对象。保留与释放操作分别会递增递减保留计数。
第 30 条 以 ARC 简化引用计数
1）有 ARC 之后，程序员就无须担心内存管理问题了。使用 ARC 来编程，可省去类中的许多“样板代码”。
2）ARC 管理对象生命期的办法基本上就是：在合适的地方插入“保留”及“释放”操作。在 ARC 环境下，变量的内存管理语义可以通过修饰符指明，而原来则需要手工执行“保留”及“释放”操作。
3）由方法所返回的对象，其内存管理语义总是通过方法名来实现。ARC 将此确定为开发者必须遵守的规则。
4）ARC 只负责管理 Objective-C 对象的内存。尤其要注意：CoreFoundation 对象不归 ARC 管理，开发者必须适时调用 CFRetain/CFRelease。
第 31 条 在 dealloc 方法中只释放引用并解除监听
1）在 dealloc 方法里，应该做的事情就是释放指向其他对象的引用，并取消原来订阅的“键值观测”（KVO）或NSNotivicationCenter等通知，不要做其他事情。
2）如果对象持有文件描述符等系统资源，那么应该专门编写一个方法来释放此种资源。这样的类要和其使用者约定：用完资源后必须调用 close 方法。
3）执行异步任务的方法不应在 dealloc 里调用；只能在正常状态下执行的那些方法也不应在 dealloc 里调用，因为此时对象已正在回收的状态了。
第 32 条 编写“异常安全代码”时留意内存管理问题
1）捕获异常时，一定要注意将 try 块内所创立的对象清理干净。
2）在默认情况下，ARC 不生成安全处理异常所需的清理代码。开启编译器标志后，可生成这种代码，不过会导致应用程序变大，而且会降低支行效率。
第 33 条 以弱引用避免保留环
1）将某些引用设为 weak，可避免出现“保留环”。
2）weak 引用可以自动清空，也可以不自动清空。自动清空是随着 ARC 而引入的新特性，由运行期系统来实现。在具备自动清空功能的弱引用上，可以随意读取其数据，因为这种引用不会指向已经回收过的对象。
第 34 条 以“自动释放池块”降低内存峰值
1）自动释放池排布在栈中，对象收到 autorelease 消息后，系统将其放入最顶端的池里。
2）合理运用自动释放池，可降低应用程序的内存峰值。
3）@autoreleasepool 这种新式写法能创建出更为轻便的自动释放池。
第 35 条 用“僵尸对象”调试内存管理问题
1）系统在回收对象时，可以不将其真的回收，而是把它转化为僵尸对象。通过环境变量 NSZombieEnabled 可开启此功能。
2）系统会修改对象的 isa 指针，令其指向特殊的僵尸类，从而使该对象变为僵尸对象。僵尸类能够响应所有的选择子，响应方式为：打印一条包含消息内容及其接收者的消息，然后终止应用程序。
第 36 条 不要使用 retainCount
1）对象的保留计数看似有用，实则不然，因为任何给定时间点上的“绝对你试计数”（absolute retain count）都无法反映对象生命的全貌。
2）引入 ARC 之后，retainCount 方法就正式废止了，在 ARC 下调用该方法会导致编译器报错。
第 6 章 块与大中枢派发
第 37 条 理解“块”这一概念
说明：块，即 block；大中枢派发，即 Grand Central Dispatch, GCD。
1）块是 C、C++、Objective-C 中的词法闭包。
2）块可接受参数，也可返回值。
3）块可以分配在栈或堆上，也可以是全局的。分配在栈上的块可拷贝到堆里，这样的话，就和标准的 Objective-C 对象一样，具备引用计数了。
第 38 条 为常用的块类型创建 typedef
1）以 typedef 重新定义块类型，可令块变量用起来更加简单。
2）定义新类型时应遵从现有的命名习惯，勿使其名称与别的类型相冲突。
3）不妨为同一个块签名定义多个类型别名。如果要重构的代码使用了块类型的某个别名，那么只需修改相应 typedef 中的块签名即可，无须改动其他 typedef。
第 39 条 用 handler 块降低代码分散程度
1）在创建对象时，可以使用内联的 handler 块将业务逻辑一并声明。
2）在有多个实例需要监控时，如果采用委托模式，那么经常需要根据传入的对象来切换，而若改用 handler 块来实现，则可直接将块与相关对象放在一起。
3）设计 API 时如果用到了 handler 块，那么可以增加一个参数，使调用者可通过此参数来决定应该把块安排在哪个队列上执行。
第 40 条 用块引用其所属对象时不要出现保留环
1）如果块所捕获的对象直接或间接的保留了块本身，那么就得当心保留环（循环引用）问题。
2）一定要找个适当的时机解除保留环，而不能把责任推给 API 的调用者。
第 41 条 多用派发队列，少用同步锁
说明：派发队列，即 GCD；同步锁，即 @synchronized
1）派发队列可用来表述同步语义（synchronization semantic），这种做法要比使用 @synchronized 块或 NSLock 对象更简单。
2）将同步与异步派发结合起来，可以实现与普通加锁机制一样的同步行为，而这么做却不会阻塞执行异步派发的线程。
3）使用同步队列及栅栏块（dispatch_barrier_async），可以令同步行为更加高效。
第 42 条 多用 GCD，少用 performSelector 系列方法
1）performSelector 系统方法在内存管理方面容易有疏失。它无法确定将要执行的选择子具体是什么，因而 ARC 编译器也就无法插入适当的内存管理方法。
2）performSelector 系列方法所能处理的选择子太过局限了，选择子的返回值类型及发送给方法的参数个数都受到限制。
3）如果想把任务放在另一个线程上执行，那么最好不要用 performSelector 系列方法，而是应该把任务封装到块里，然后调用 GCD 的相关方法来实现。
第 43 条 掌握 GCD 及操作队列的使用时机
说明：操作队列，即 NSOperationQueue
1）在解决多线程与任务管理问题时，派发队列并非唯一文案。
2）操作队列提供了一套高层的 Objective-C API，能实现纯 GCD 所具备的绝大部分功能，而且还能完成一些更为复杂的操作，那些操作若改用 GCD 来实现，则需另外编写代码。
第 44 条 通过 Dispatch Group 机制，根据系统资源状况来执行任务
1）一系列任务可归入一个 dispatch group 之中。开发者可以在这组任务执行完毕时获得通知。
2）通过 dispatch group，可以在并发式派发队列里同时执行多项任务。此时 GCD 会根据系统资源状况来调度这些并发执行的任务。开发者若自己来实现此功能，则需编写大量代码。
第 45 条 使用 dispatch_one 来执行只需运行一次的线程安全代码
1）经常需要编写“只需执行一次的线程安全代码”。通过 GCD 所提供的 dispatch_once 函数，很容易就能实现此功能。
2）标记应该声明在 static 或 global 作用域中，这样的话，在把只需执行一次的块传给 dispatch_once 函数时，传进去的标记也是相同的。
第 46 条 不要使用 dispatch_get_current_queue
1）dispatch_get_current_queue 函数的行为常常与开发者所预期的不同。此函数已经废弃，只应做调试之用。
2）由于派发队列是按层级来组织的，所以无法单用某个队列对象来描述“当前队列”这一概念。
3）dispatch_get_current_queue 函数用于解决由不可重入的代码所引发的死锁，然而能用此函数解决的问题，通常也能改用“队列特定数据”来解决。
未完待续，传送门：
