《Effictive Objective-C 2.0》读书摘要（下）

《Effictive Objective-C 2.0》读书摘要（下）

《Effictive Objctive-C》一书（以下简称EOC），为每个iOS开发人员必读之经典。书中所提到的7大板块，52个OC语言编程心得，让我获益颇深。自接触来零零散散看了三四遍，也未曾将书中所述完全领悟。闻有句话叫”好记性，不如烂博客”，固提笔记录一下书中知识点。之后会抽时间再将个人心得与动手实践附上。

第5章 内存管理

第29条：理解引用计数

*引用计数机制通过可以递增递减的计数器来管理内存。对象创建好之后，其保留计数至少1.若保留计数为正，则对象继续存活。当保留计数降为0，对象就被销毁了。
*在对象生命期中，其余对象通过引用来保留或释放此对象。保留与释放操作分别会递增及递减保留计数。

第30条：以ARC简化引用计数

*有ARC之后，程序员就无须担心内存管理问题了。使用ARC来编程，可省去类中的许多“样板代码”。
*ARC管理对象生命期的办法基本上就是:在合适的地方插入”保留”及”释放”操作。在ARC环境下，变量的内存管理管理语义可以通过修饰符指明，而原来则需要手工执行”保留”及”释放”操作。
*由方法所返回的对象，其内存管理语义总是通过方法名来体现。ARC将此确定为开始着必须遵守的规则。
*ARC只负责管理Objective-C对象的内存。尤其要注意:CoreFoundation 对象不归ARC管理，开发者必须适时调用CFRetain/CFRelease。

第31条：在dealloc方法中只释放引用并解除监听

*在dealloc方法里，应该做的事情就是释放指向其他对象的引用，并取消原来订阅的”键值观测”（KVO）或NSNotificationCenter等通知，不要做其他事情。
*如果对象持有文件描述符等系统资源，那么应该专门编写一个方法来释放此种资源。这样的类要和其使用者约定:用完资源后必须调用close方法。
*执行异步任务的方法不应再dealloc里调用;只能在正常状态下执行的那些方法也不应在dealloc里调用，因此此时对象已处于正在回收的状态了。

第32条：编写”异常安全代码”时留意内存管理问题

*捕获异常时，一定要注意将try块内所创立的对象清理干净。
*在默认情况下，ARC不生成安全处理异常所需的清理代码。开启编译器标志后，可生成这种代码，不过会导致应用程序变大，而且会降低运行效率。

第33条：以弱引用避免保留环

*将某些引用设为weak,可避免出现”保留环”。
weak引用可以自动清空，也可以不自动清空。自动清空(autonilling)是随着ARC而引入的新特性，由运行期系统来实现。在具备自动清空功能的弱引用上，可以随意读取其数据，以为这种引用不会指向已经回收过的对象。

第34条：以”自动释放池块”降低内存峰值

*自动释放池排布在栈中，对象收到autorelease消息后，系统将其放入最顶端的池里。
*合理运用自动释放池，可降低应用的内存峰值。
*@autoreleasepool这种新式写法能创建出更为轻便的自动释放池。

第35条：用”僵尸对象”调试内存管理问题

*系统在回收对象时，可以不将其真的回收，而是把它转化为僵尸对象。通过环境变量NSZombieEnabled可开启此功能。
*系统会修改对象的isa指针，令其指向特殊的僵尸类，从而使该对象变为僵尸对象。僵尸类能够响应所有的选择子，响应方式为:打印一条包含消息内容及其接收者的消息，然后终止应用程序。

第36条 ：不要使用retainCount

*对象的保留计数看似有用，实则不然，因为任何给定时间点上的”绝对保留计数”(absolute retain count)都无法反映对象生命期的全貌。
引入ARC之后，retainCount方法就正式废止了，在ARC下调用该方法会导致编译器报错。

第六章 块与大中枢派发

第37条:理解”块”这一概念

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第46条：不要使用dispatch_get_current_queue

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

第7章 系统框架

第47条：熟悉系统框架

*许多系统框架都可以直接使用。其中最重要的是Foundation和CoreFoundation,这俩个框架提供了构建应用程序所需的许多核心功能。
*很多常见任务都能用框架来做，例如音频与视频处理、网络通信、数据管理等。
*请记住：用纯C写成的框架与用Objective-C写成到 一样重要，若想成为优秀的Objective-C开发者，应该掌握C语言的核心概念。

第48条：多用块枚举，少用for循环

*遍历collection有四种方式。最基本的办法是for循环，其次是NSEnumerator遍历法及快速遍历法，最新、最先进的方式则是”块枚举法”。
“块枚举法”本身就能通过GCD来并发执行遍历操作，无须另行编写代码。而采用其他遍历方式则无法轻易实现这一点。
若提前只带待遍历的collection含有何种对象，则应修改块签名，指出对象的具体类型。

第49条:对自定义其内存管理语义的collection使用无缝桥接

*通过无缝桥接计数，可以在Foundation框架中的Objective-C对象与CoreFoundation框架中的C语言数据结构之间来回转换。
在CoreFoundation层面创建collection时，可以指定许多回调函数，这些函数表示此collection应如何处理其元素。然后，可运用无缝桥接技术，将其转换成具备特殊内存管理语义的Objective-Ccollection。

第50条：构建缓存时选用NSCache而并非NSDictionary

*实现缓存时应选用NSCache而非NSDictionary对象。因为NSCache可以提供优雅的自动删减功能，而且是”线程安全的”,此外，它与字典不同，并不会拷贝键.
*可以给NSCache对象设置上限，用以限制缓存中的对象总个数及”总成本”,而这些尺度则定义了缓存删减其中对象的时机。但是绝对不要把这些尺度当成可靠的”硬限制”(hard limit)， 它们仅对NSCache起指导作用。
*将NSPurgeableData与NSCache搭配使用，可实现自动清除数据的功能，也就是说，当NSPurgeableData对象所占内存为系统所丢弃时，该对象自身也会从缓存中移除。
*如果缓存使用得当，那么应用程序的响应速度就能提高。只有那种”重新计算起来很费事的”数据，才值得放入缓存，比如那些需要从网络获取或从磁盘读取的数据。

第51条：精简initialize与load的实现代码

*在加载阶段，如果类实现了load方法,那么系统就会调用它。分类里也可以定义此方法，类的load方法要比分类中的先调用。与其他方法不同，load方法不参与覆写机制。
*首次使用某个类之前，系统会向起发送initialize消息。由于此方法遵从普通的覆写规则，所以通常应该在里面判断当前要初始化的是哪个类。
*load与initialize方法都应该实现得精简一些，这有助于保持应用程序的响应能力，也能减少引入”依赖环”(interdependency cycle)的几率。
*无法再编译器设定的全局常量，可以放在initialize 方法里初始化。

第52条：别忘了NSTimer会保留其目标对象

*NSTimer对象会保留其目标，知道计时器本身失效为止，调用invalidate方法可令计时器失效，另外一次性的计时器在触发完任务之后也会失效。
*反复执行任务的计时器(repeation timer)，很容易引入保留环，如果这种计时器的目标对象又保留了计时器本身，那肯定会导致保留环。这种环状保留关系，可能是直接发生的，也可能是通过对象图里的其他对象间接发生的。
*可以扩充NSTimer的功能，用”块”来打破保留环。不过除非NSTimer将来在公共接口里提供此功能，否则必须创建分类，将相关实现代码加入其中。