编写高质量OC代码的52个有效方法（要点）

第1章 熟悉Objective-C

第1条：了解Objective-C语言的起源

1. Objective-C 为C语言添加了面向对象特性，是其超集。Objective-C使用动态绑定的消息结构，也就是说，在运行时才会检查对象类型。
   接收一条消息后，究竟应执行何种代码，由运行期环境而非编译器决定。
2. 理解C语言的核心概念有助于写好Objective-C程序。尤其要掌握内存模型与指针。

第2条：在类的头文件中尽量少引入其他头文件

1. 除非有必要，否则不要引入头文件。一般来说，应在某个类的头文件中使用向前声明来提及别的类别，并在实现文件中引入那些类的头文件。
   这样做可以尽量降低类之间的耦合。
2. 有时无法使用向前声明(@class,@protocol等，可防止头文件的循环引用)，比如要声明某个类遵循一项协议。
   这种情况下，尽量把“该类遵循某协议”的这条声明移至”class-continuation分类”中。如果不行的话，就把协议单独放在一个头文件中，然后将其引入。

第3条：多用字面量语法，少用与之等价的方法

1. 应该使用字面量语法来创建字符串、数值、数组、字典。与创建此类对象的常规方法相比，这么做更加简明扼要。
2. 应该通过取下标操作来访问数组下标或者字典中的键所对应的元素（可变数组和字典也可通过下标来修改）。
3. 用字面量语法创建数组或字典时，值中不能有nil，否则会抛出异常。

第4条：多用类型常量，少用#define预处理指令

1. 不要用预处理指令定义常量。这样定义出来的常量不含类型信息，编译器只是会在编译前据此执行查找和替换操作。即时有人重新定义了常量值，
   编译器也不会产生警告信息，导致常量值不一致。
2. 在实现文件中使用static const来定义“只在编译单元内可见的常量”。由于此类常量不在全局符号表中，所以无需为其名称加前缀。
3. 在头文件中使用extern来声明全局常量，并在相关实现文件中定义其值。这种常量要出现在全局符号表中，所以其名称应加以区隔，通常用与之相关的类名做前缀。

第5条：用枚举表示状态、选项、状态码

1. 应该用枚举来表示状态机的状态、传递给方法的选项以及状态码等值，给这些值起个易懂的名字。
2. 如果把传递给某个方法的选项表示为枚举类型，而多个选项又可同时使用，那么就将各选项值定义为2的幂，以便通过按位或操作将其组合起来。
3. 用NS_ENUM与NS_OPTIONS宏来定义枚举类型，并指明其底层数据类型。这样做可以确保枚举是用开发者所选的底层数据类型实现出来的，而不会采用编译器所选的类型。
4. 在处理枚举类型的switch语句中不要实现default分支。这样的话，加入新枚举之后，编译器就会提示开发者：switch语句并未处理所有枚举。

第2章 对象、消息、运行期

第6条：理解“属性”这一概念

1. 可以用@property语法来定义对象中所封装的数据
2. 通过“特质”来指定存储数据所需的正确语义
3. 在设置属性所对应的实例变量时，一定要遵从该属性所声明的语义
4. 开发iOS程序时应该使用nonatomic属性，因为atomic属性会严重影响性能。

第7条：在对象内部尽量直接访问实例变量

1. 在对象内部读取数据时，应该直接通过实例变量来读，而写入数据时，则应通过属性来写。
2. 在初始化方法及dealloc方法中，总是应该直接通过实例变量来读取数据。
3. 有时会使用惰性初始化技术配置某份数据，这种情况下，需要通过属性来读取数据。

第8条：理解“对象等同性”这一概念

1. 若想检测对象的等同性，请提供“isEqual:”与hash方法。
2. 相同的对象那个必须具有相同的哈希码，但是两个哈希码相同的对象却未必相同。
3. 不要盲目地逐个检测每条属性，而是应该依照具体需求来制定检测方案。
4. 编写hash方法时，应该使用计算速度快而且哈希码碰撞几率低的算法。

第9条：以“类族模式”隐藏实现细节

1. 类族模式可以把实现细节隐藏在一套简单的公共接口后面。
2. 系统框架中经常使用类族。
3. 从类族的公共抽象基类中继承子类时要当心，若有开发文档，则应首先阅读。

第10条：在既有类中使用关联对象存放自定义数据

1. 可以通过“关联对象”机制来把两个对象连起来。
2. 定义关联对象时可指定内存管理语义，用以模仿定义属性时所采用的“拥有关系”与“非拥有关系”。
3. 只有在其他做法不可时才选用关联对象，因为这种做法通常会引入难以查找的bug。

第11条：理解objc_msgSend的作用

1. 消息由接收者、选择子及参数构成。给某对象“发送消息”也就相当于在该对象上“调用方法”。
2. 发给某对象的全部消息都要由“动态消息派发系统”来处理，该系统会查出对应的方法，并执行其代码。

第12条：理解消息转发机制

1. 若对象无法响应某个选择子，则进入消息转发流程。
2. 通过运行期的动态方法解析功能，我们可以在需要用到某个方法时再将其加入类中。
3. 对象可以把其无法解读的某些选择子转交给其他对象来处理。
4. 经过上述两步之后，如果还是没办法处理选择子，那就启动完整的消息转发机制。

第13条：用“方法调配技术”调试“黑盒方法”

1. 在运行期，可以向类中新增或替换选择子所对应的方法实现。
2. 使用另一份实现来替换原有的方法实现，这道工序叫做“方法调配”，开发者常用此技术向原有实现中添加新功能。
3. 一般来说，只有调试程序的时候才需要在运行期修改方法实现，这种做法不易滥用。

第14条：理解“类对象”的用意

1. 每个实例都有一个指向Class对象的指针，用以表明其类型，而这些Class对象则构成了类的继承体系。
2. 如果对象类型无法在编译期确定，那么就应该使用类型信息查询方法来探知。
3. 尽量使用类型信息查询方法来确定对象类型，而不要直接比较类对象，因为某些对象可能实现了消息转发功能。

第3章 接口与API设计

第15条：用前缀避免命名空间冲突

1. 选择与你的公司、应用程序或二者皆有关联之名称作为类名的前缀，并在所有代码中均使用这一前缀。
2. 若自己所开发的程序中用到了第三方库，则应为其中的名称加上前缀。

第16条：提供“全能初始化方法”

1. 在类中提供一个全能初始化方法，并于文档里指明。其他初始化方法均应调用此方法。
2. 若全能初始化方法与超类不同，则需覆写超类中的对应方法。
3. 如果超类的初始化方法不适应于子类，那么应该覆写这个超类方法，并在其中抛出异常。

第17条：实现description方法

1. 实现description方法返回一个有意义的字符串，用以描述该实例。
2. 若想在调试时打印出更详尽的对象描述信息，则应实现debugDescription方法。

第18条： 尽量使用不可变对象

1. 尽量创建不可变的对象。
2. 若某属性仅可于对象内部修改，则在“class-continuation分类”中将其由readonly属性扩展为readwrite属性。
3. 不要把可变的collection作为属性公开，而应提供相关方法，以此修改对象中的可变collection。

第19条：使用清晰而协调的命名方式

1. 起名时应遵从标准的Objective-C命名规范，这样创建出来的接口更容易为开发者所理解。
2. 方法名要言简意赅，从左只有读起来要像个日常用语中的句子才好。
3. 方法名里不要使用缩略后的类型名称。
4. 给方法起名时的第一要务就是确保其风格与你自己的代码或所要集成的框架相符。

第20条：为私有方法名加前缀

1. 给私有方法的名称加上前缀，这样可以很容易地将其同公共方法区分开。
   2.不要单用一个下划线做私有方法的前缀，因为这种做法是预留给苹果公司用的。

第21条：理解Objective-C错误类型

1. 只有发生了可使整个应用程序崩溃的严重错误时，才应使用异常。
2. 在错误不那么严重的情况下，可以指派“委托方法”来处理错误，也可以吧错误信息放在NSError对象里，经由“输出参数” 返回给调用者。

第22条：理解NSCopying协议

1. 若想令自己所写的对象具有拷贝功能，则需实现NSCopying协议。
2. 如果自定义的对象分为可变版本与不可变版本，那么就要同时实现NSCopying与NSMutableCopying协议。
3. 复制对象时需决定采用浅拷贝还是深拷贝，一般情况下应该尽量执行浅拷贝。
4. 如果你所写的对象需要深拷贝，那么可考虑新增一个专门执行深拷贝的方法。

第4章 协议与分类

第23条：通过委托与数据源洗衣进行对象间通信

1. 委托模式为对象提供了一套接口，使其可由此将相关事件告知其他对象。
2. 将委托对象应该支持的接口定义成协议，在协议中把可能需要处理的事件定义成方法。
3. 当某对象需要从另外一个对象中获取数据时，可以使用委托模式。这种情境下，该模式亦称“数据源协议”
4. 若有必要，可实现含有位段的结构体，将委托对象是否能响应相关协议方法这一信息缓存至其中。

第24条：将类的实现代码分散到便于管理的数个分类之中

1. 使用分类机制把类的实现代码划分为易于管理的小块
2. 将应该视为“私有”的方法名叫Private的分类中，以隐藏实现细节。

第25条：总是为第三方类的分类名称加前缀

1. 向第三方类中添加分类时，总应给其名称加上你专用的前缀。
2. 向第三方类中添加分类是，总应给其中的方法名加上你专用的前缀。

第26条：勿在分类中声明属性

1. 把封装数据所用的全部属性都定义在主接口里。
2. 在“class-continuation分类”之外的其他分类中，可以定义存取方法，但尽量不要定义属性。

第27条：使用“class-continuation分类”隐藏实现细节

1. 通过“class-continuation分类”向类中新增实例变量
2. 如果某属性在主接口中声明为“只读”，而类的内部又要用设置方法修改此属性，那么就在分类中将其扩展为“可读写”
3. 把私有方法的原型声明在分类里面。
4. 若想使类所遵循的协议不为人知，则可于分类中声明。

第28条：通过协议提供匿名对象

1. 协议可在某种程度上提供匿名类型。具体的对象类型可以淡化成遵从某协议的id类型，协议里规定了对象所应实现的方法。
2. 使用匿名对象来隐藏类型名称（或类名）。
3. 如果具体类型不重要，重要的是对象能够响应（定义在协议里的）特定方法，那么可以使用匿名对象来表示。

第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)”或NSNotificationCenter等通知，不要做其他事情。
2. 如果对象持有文件描述符等系统资源，那么应该专门编写一个方法来释放此种资源。
3. 执行异步任务的方法不应在dealloc里调用，只能在正常状态下执行的那些方法也不应再dealloc里调用，因为此时对象已处于正在回收的状态了。

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

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

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

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

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

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

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

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

第36条：不要使用retainCount

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

第6章 块与大中枢派发

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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函数用于解决不可重入的代码所引发的死锁，然而能用此函数解决问题，通常也能改用“队列特定数据”来解决。

第7章 系统框架

第47条：熟悉系统框架

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

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

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

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

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

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

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

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

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

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

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