第七章 系统框架

47.熟悉系统框架

将一系列代码封装为动态库（dynamic library），并在其中放入描述其接口的头文件，这样做出来的东西就叫框架。有时为iOS平台构建的第三方框架所使用的是静态库（static library），这是因为iOS应用程序不允许在其中包含动态库。这些东西严格来讲并不是真正的框架，然而也经常视为框架。不过，所有iOS平台的系统框架仍然使用动态库。

在为Mac OS X或iOS系统开发“带图形界面的应用程序”时，会用到名为Cocoa的框架，在iOS上成为Cocoa Touch。其实Cocoa本身并不是框架，但是里面继承了一批创建应用程序时经常会用到的框架。

开发者会碰到的主要框架就是Foundation，像是NSObject、NSArray、NSDictionary等类都在其中。Foundation框架是所有Objective-C应用程序的“基础”。

Foundation框架不仅提供了collection等基础核心功能，而且还提供了字符串处理这样的复杂功能。比方说，NSLinguisticTagger可以解析字符串并找到其中的全部名词、动词、代词等。

还有个与Foundation相伴的框架，叫做CoreFoundation。虽然从技术上讲，CoreFoundation框架不是Objective-C框架，但它确实编写Objective-C应用程序所应熟悉的重要框架，Foundation框架中的许多功能，都可以在此框架中找到对应的C语言API。CoreFoundation与Foundation不仅名字相似，而且还有更为紧密的联系。有个功能叫做“无缝桥接”（toll-free bridging），可以把CoreFoundation中的C语言数据结构平滑转换为Foundation中的Objective-C对象，也可以反向转换。比方说，Foundation框架中的字符串是NSString，而它可以转换为CoreFoundation里与之等效的CFString对象。无缝桥接技术是用某些相当复杂的代码实现出来的，这些代码可以使运行期系统把CoreFoundation框架中的对象视为普通的Objective-C对象。

除了Foundation与CoreFoundation之外，还有很多系统库，其中包括但不限于下面列出的这些：

• CFNetwork 此框架提供了C语言级别的网络通信能力，它将“BSD套接字”（BSD socket）抽象成易于使用的网络接口。而Foundation则将该框架里的部分内容封装为Objective-C语言的接口，以便进行网络通信，例如可以用NSURLConnection从URL下载数据。
• CoreAudio 该框架所提供的C语言API可用来操作设备上的音频文件。这个框架属于比较难用的，因为音频处理本身就很复杂。所幸由这套API可以抽象出另外一套Objective-C式API，用后者来处理音频问题会更简单些。
• CoreData 此框架所提供的Objective-C接口可将对象放入数据库，便于持久保存。CoreData会处理数据的获取及存储事宜，而且可以跨越Mac OS X及iOS平台。
• CoreText 此框架提供的C语言接口可以高效执行文字排版及渲染操作。

Objective-C编程时会经常需要使用底层的C语言级API。用C语言来实现API的好处是，可以绕过Objective-C的运行期系统，从而提升执行速度。当然，由于ARC只负责Objective-C的对象，所以使用这些API时尤其要注意内存管理问题。

Mac OS X与iOS平台的核心UI框架分别叫AppKit及UIKit，它们都提供了构建在Foundation与CoreFoundation之上的Objective-C类。在这些主要的UI框架之下，是CoreAnimation与CoreGraphics框架。

CoreAnimation是用Objective-C语言写成的，它提供了一些工具，而UI框架则用这些工具来渲染图形并播放动画。CoreAnimation本身并不是框架，它是QuartzCore框架的一部分。

CoreGraphics框架是用C语言写成的，其中提供了2D渲染所必备的数据结构与函数。例如，其中定义了CGPoint、CGSize、CGRect等数据结构，而UIKit框架中的UIView类在确定视图控件之间的相对位置时，这些数据结构都要用到。

还有很多框架构建在UI框架之上，比如MapKit框架，它为iOS程序提供地图功能。又比如Social框架，它为Mac OS X及iOS程序提供了社交网络功能。

要点：

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

---

48.多用块枚举，少用for循环

在编程中经常需要列举collection中的元素，当前的Objective-C语言有很多种办法实现此功能，可以用标准的C语言循环，也可以用Objective-C 1.0的NSEnumerator以及Objective-C 2.0的快速遍历。语言中引入“块”这一特性后，又多出来几种新的遍历方式，采用这几种新方式遍历collection时，可以传入块，而collection中的每个元素都可能会放在块里运行一遍，这种做法通常会大幅度简化编码过程。

• 使用Objective-C 1.0的NSEnumerator来遍历

NSEnumerator是个抽象基类，其中只定义了两个方法，供其具体子类来实现：

  - (NSArray*)allObjects;
- (nullable ObjectType)nextObject;

其中关键的方法是nextObject，它返回枚举里的下个对象。每次调用该方法时，其内部数据结构都会更新，使得下次调用方法时能返回下个对象。等到枚举中的全部对象都已返回之后，再调用就将返回nil，这表示达到枚举末端了。

• 快速遍历

Objective-C 2.0引入了快速遍历这一功能。它为for循环开设了in关键字。这个关键字大幅简化了遍历collection所需的语法。

如果某个类的对象支持快速遍历，那么就可以宣称自己遵从名为NSFastEnumeration的协议，从而令开发者可以采用此语法来迭代该对象。此协议只定义了一个方法：

- (NSUInteger)countByEnumeratingWithState:(NSFastEnumerationState *)state 
    objects:(id __unsafe_unretained [])buffer 
    count:(NSUInteger)len;

该方法允许类实例同时返回多个对象，这就使得循环遍历操作更为高效了。

• 基于块的遍历方式

在当前的Objective-C语言中，最新引入的一种做法就是基于块来遍历。NSArray中定义了下面这个方法，它可以实现最基本的遍历功能：

- (void)enumerateObjectsUsingBlock:
- (void (^)(ObjectType obj, NSUInteger idx, BOOL *stop))block ;

此方法提供了一种优雅的机制，用于终止遍历操作，开发者可以通过设定stop变量值来实现。

- (void)enumerateObjectsWithOptions:
    (NSEnumerationOptions)opts 
    usingBlock:
(void (^)(ObjectType obj, NSUInteger idx, BOOL *stop))block;

- (void)enumerateKeysAndObjectsWithOptions:
   (NSEnumerationOptions)opts 
   usingBlock:
(void (^)(KeyType key, ObjectType obj, BOOL *stop))block;

NSEnumerationOptions类型是个enum，其各种取值可用“按位或”连接，用以表明遍历方式。例如，开发者可以请求以并发方式执行各轮迭代，也就是说，如果当前系统资源状况允许，那么执行每次迭代所用的块就可以并行执行了。通过NSEnumerationConcurrent选项即可开启此功能。如果使用此选项，那么底层会通过GCD来处理并发执行事宜，具体实现时很可能会用到dispatch group。反向遍历是通过NSEnumerationReverse选项来实现的。

总体来看，块枚举法拥有其他遍历方式都具备的又是，而且还能带来更多好处。与快速遍历法相比，它更多用一些代码，可是却能提供遍历时所针对的下标，在遍历字典时也能同时提供键与值，而且还有选项可以开启并发迭代功能。

要点：

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

---

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

使用“无缝桥接”技术，可以在定义于Foundation框架中的Objective-C类和定义与CoreFoundation框架中的C数据结构之间互相转换。

下列代码演示了简单的无缝桥接：

NSArray *anNSArray = @[@1,@2,@3,@4,@5];
CFArrayRef aCFArray = (__bridge CFArrayRef)anNSArray;
NSLog(@"Size of array = %li",CFArrayGetCount(aCFArray));

转换中的__bridge告诉ARC如何处理转换所涉及的Objective-C对象。__bridge本身的意思是：ARC仍然具备这个Objective-C对象的所有权。而__bridge_retained则与之相反，意味着ARC将交出对象的所有权。若是前面那段代码改用它来实现，那么用完数组之后就要加上CFRelease(aCFArray)以释放其内存。与之相似，反向转换可通过__bridge_transfer来实现。比方说，想把CFArrayRef转换为NSArray，并且想令ARC获得对象所有权，那么就可以采用此种转换方式。这三种转换方式成为”桥式转换“（bridged cast）。*

以纯Objective-C来编写应用程序时，为何要用到这种功能呢？这是因为：Foundation框架中的Objective-C类所具备的某些功能，是CoreFoundation框架中的C语言数据结构所不具备的，反之亦然。在使用Foundation框架中的字典对象时会遇到一个大问题，那就是其键的内存管理语义为”拷贝“，而值的语义却是”保留“。除非使用强大的无缝桥接技术，否则无法改变其语义。

CoreFoundation框架中的字典类型叫做CFDictionary。其可变版本称为CFMutableDictionary。创建CFMutableDictionary时，可以通过下列方法来指定键和值的内存管理语义：

CFDictionaryRef CFDictionaryCreate(
CFAllocatorRef allocator, 
const void **keys, 
const void **values, 
CFIndex numValues, 
const CFDictionaryKeyCallBacks *keyCallBacks, 
const CFDictionaryValueCallBacks *valueCallBacks);

首个参数表示将要使用的内存分配器。CoreFoundation对象里的数据结构需要占用内存，而分配器负责分配及回收这些内存。开发者通常为这个参数传入NULL，表示采用默认的分配器。

第二个参数定义了字典的初始化大小。它并不会限制字典的最大容量，只是向分配器提示了一开始应该分配多少内存。加入要创建的字典含有10个对象，那就向该参数传入10。

最后两个参数值得注意。它们定义了许多回调函数，用于指示字典中的键和值在遇到各种事件时应该执行何种操作。这两个参数都是指向结构体的指针，二者所对应的结构体如下：

typedef struct {
    CFIndex             version;
    CFDictionaryRetainCallBack      retain;
    CFDictionaryReleaseCallBack     release;
    CFDictionaryCopyDescriptionCallBack copyDescription;
    CFDictionaryEqualCallBack       equal;
    CFDictionaryHashCallBack        hash;
} CFDictionaryKeyCallBacks;


typedef struct {
    CFIndex             version;
    CFDictionaryRetainCallBack      retain;
    CFDictionaryReleaseCallBack     release;
    CFDictionaryCopyDescriptionCallBack copyDescription;
    CFDictionaryEqualCallBack       equal;
} CFDictionaryValueCallBacks;

version参数目前应设为0。当前编程时总是取这个值，不过将来苹果公司也许会修改此结构体，所以要预留该值以表示版本号。这个参数可以用于检测新版与旧版数据结构之间是否兼容。结构体中的其余成员都是函数指针，它们定义了各种事件发生时应该采用哪个函数来执行相关任务。比方说，如果字典中加入了新的键与值，那么就会调用retain函数。此参数的类型定义如下：

typedef const void *    (*CFDictionaryRetainCallBack)
(CFAllocatorRef allocator, 
const void *value);

由此可见retain是个函数指针，其所指向的函数接受两个参数，其类型分别是CFAllocatorRef与const void 。传给此函数的value参数表示即将加入字典中的键或值。而返回的void则表示要加到字典里的最终值。开发者可以用下列代码实现这个回调函数：

const void * CustomCallback(CFAllocatorRef allocator,
                            const void *value)
{
    return value;
}

这么写只是把将加入字典中的值照原样返回。于是，如果用它充当retain回调函数来创建字典，那么该字典就不会“保留”键与值了。将此种写法与无缝桥接搭配起来，就可以创建出特殊的NSDictionary对象，而其行为与用Objective-C创建出来的普通字典不同。

下面的代码演示了这种字典的创建步骤：

#import <Foundation/Foundation.h>
#import <CoreFoundation/CoreFoundation.h>

const void* EOCRetainCallback(CFAllocatorRef allocator,
                              const void *value)
{
    return value;
}

void EOCReleaseCallback(CFAllocatorRef allocator,
                        const void *value)
{
    CFRelease(value);
}

CFDictionaryKeyCallBacks keyCallbacks = {
    0,
    EOCRetainCallback,
    EOCReleaseCallback,
    NULL,
    CFEqual,
    CFHash
};

CFDictionaryValueCallBacks valueCallbacks = {
    0,
    EOCRetainCallback,
    EOCReleaseCallback,
    NULL,
    CFEqual
};



CFMutableDictionaryRef aCFDictionary =
        CFDictionaryCreateMutable(NULL,
                              0,
                              &keyCallbacks,
                              &valueCallbacks);
    
NSMutableDictionary *anNSDictinary =
    (__bridge_transfer NSMutableDictionary *)aCFDictionary;

在设定回调函数时，copyDescription取值为NULL，因为采用默认实现就很好，而equal与hash回调函数分别设为CFEqual与CFHash，因为这二者所采用的做法与NSMutableDictionary的默认实现相。CFEqual最终会调用NSObject的“isEqual:”方法，而CFHash则会调用hash方法。由此可以看出无缝桥接技术更为强大的一面。

键与值所对应的retain与release回调函数指针分别指向EOCRetainCallback与EOCReleaseCallback函数。如果用作键的对象不支持拷贝操作，此时就不能使用普通的NSMutableDictionary了，因为对象所属的类不支持NSCopying协议，因为“copyWithZone:”方法未实现。开发者可以直接在CoreFoundation层创建字典，于是就能修改内存管理语义，对键执行“保留”而非“拷贝”操作了。

要点：

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

---

50.构建缓存时选用NSCache而非NSDictionary

NSCache是Foundation框架专为处理缓存任务而设计的。

NSCache胜过NSDictionary之处在于，当系统资源将要耗尽时，它可以自动删减缓存。如果采用普通的字典，那么就要自己编写挂钩，在系统发出“低内存”（low memory）通知时手工删减缓存。而NSCache则会自动删减，由于其是NSFoundation框架的一部分，所以与开发者相比，它能在更深的层面上插入挂钩。此外，NSCache还会先行删减”最久未使用的”对象。若想自己编写代码来为字典添加此功能，则会十分复杂。

NSCache并不会“拷贝”键，而是会“保留”它。此行为用NSDictionary也可以实现，然而需要编写相当复杂的代码。NSCache对象不拷贝键的原因在于：很多时候，键都是由不支持拷贝操作的对象来充当的。因此，NSCache不会自动拷贝键，所以说，在键不支持拷贝操作的情况下，该类用起来比字典更方便。另外，NSCache是线程安全的。而NSDictionary则绝对不具备此优势，意思就是：在开发者自己不编写加锁代码的前提下，多个线程便可以同时访问NSCache。对缓存来说，线程安全通常很重要，因为开发者可能要在某个线程中读取数据，此时如果发现缓存里找不到指定的键，那么就要下载该键所对应的数据了。而下载完数据之后所要执行的回调函数，有可能会放在背景线程中运行，这样的话，就等于是用另外一个线程来写入缓存了。

开发者可以操控缓存删减其内容的时机。有两个与系统资源相关的尺度可供调整，其一是缓存中的对象总数，其二是所有对象的”总开销“。开发者在将对象加入缓存时，可为其指定”开销值“。当对象总数或总开销超过上限时，缓存就可能会删减其中的对象了，在可用的系统资源趋于紧张时，也会这么做。然而要注意，是”可能“会删减某个对象，而不是”一定“会删减某个对象。删减对象时所遵照的顺序，由具体实现来定。

向缓存中添加对象时，只有在能很快计算出”开销值“的情况下，才应该考虑采用这个尺度。若计算过程很复杂，那么照这种方式来使用缓存就达不到最佳效果了。

下面演示了缓存的用法：

//Network fetcher class
typedef void(^EOCNetworkFetcherCompletionHandler) (NSData *data);
@interface EOCNetworkFetcher : NSObject
-(instancetype)initWithURL:(NSURL *)url;
-(void)startWithCompletionHandler:
(EOCNetworkFetcherCompletionHandler)handler;

@end


@interface CacheTest()
{
    NSCache *_cache;
}
@end

@implementation CacheTest
-(instancetype)init{
    if(self = [super init]){
        _cache = [NSCache new];
        
        //Cache a maximum of 100 URLs
        _cache.countLimit = 100;
        
        //The size in bytes of data is used as the cost
        _cache.totalCostLimit = 5*1025*1024;//5MB
    }
    return self;
}

-(void)downloadDataForURL:(NSURL *)url{
    NSData *cachedData = [_cache objectForKey:url];
    if(cachedData){
        //Cache hit
        [self useData:cachedData];
    }else{
        //Cache miss
        EOCNetworkFetcher *fetcher = [[EOCNetworkFetcher alloc]initWithURL:url];
        [fetcher startWithCompletionHandler:^(NSData *data) {
            [_cache setObject:data forKey:url cost:data.length];
            [self useData:data];
        }];
    }
}
@end

本例中，下载数据所用的URL，就是缓存的键。若缓存未命中，则下载数据并将其放入缓存。而数据的开销值则为其长度。创建NSCache时，将其中可缓存的总对象数目上限设为100，将总开销上限设置为5MB。

还有个类叫NSPurgeableData，和NSCache搭配起来用，效果很好，此类事NSMutableData的子类，而且实现了NSDiscardableContent协议。如果某个对象所占的内存能够根据需要随时丢弃，那么就可以实现该协议所定义的接口。这就是说，当系统资源紧张时，可以把保存NSPurgeableData对象的那块内存释放掉。NSDiscardableContent协议里定义了名为isContentDiscarded的方法，可用来查询相关内存是否已释放。

如果需要访问某个NSPurgeableData对象，可以调用其beginContentAccess方法，告诉它现在还不应丢弃自己所占的内存。用完之后，调用endContentAccess方法，告诉它在必要时可以丢弃自己所占的内存了。这些调用可以嵌套，所以说，它们就像递增与递减引用计数所用的方法那样。只有对象的”引用计数“为0时才可以丢弃。

如果将NSPurgeableData对象加入NSCache，那么当该对象为系统所丢弃时，也会自动从缓存中移除。通过NSCache的evictsObjectsWithDiscardedContent属性，可以开启或关闭此功能。

刚才那个例子可以用NSPurgeableData改写如下：

-(void)downloadDataForURL:(NSURL *)url{
    NSPurgeableData *cachedData = [_cache objectForKey:url];
    if(cachedData){
        //Stop the data being purged
        [cachedData beginContentAccess];
        
        //Use the cached data
        [self useData:cachedData];
        
        //Mark that the data may be purged again
        [cachedData endContentAccess];
    }else{
        //Cache miss
        EOCNetworkFetcher *fetcher = [[EOCNetworkFetcher alloc]initWithURL:url];
        [fetcher startWithCompletionHandler:^(NSData *data) {
            NSPurgeableData *purgeableData = [NSPurgeableData dataWithData:data];
            [_cache setObject:purgeableData forKey:url cost:data.length];
            
            //Don't need to beginContentAccess as it begins
            //with access already marked
            
            //Use the retrieved data
            [self useData:data];
            
            //Mark that the data may be purged now
            [purgeableData endContentAccess];
        }];
    }
}

注意，创建好NSPurgeableData对象之后，其”purge引用计数“会多1，所以无须再调用beginContentAccess了，然而气候必须调用endContentAccess，将多出来的这个”1“抵消掉。

要点：

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

---

51.精简initialize与load的实现代码

有时候，类必须先执行某些初始化操作，然后才能正常使用。NSObject类有两个方法，可用来实现这种初始化操作。

load方法原型：

+ (void)load;

对于加入运行期系统中的每个类及分类来说，必定会调用此方法，而且仅调用一次。当包含类或分类的程序库载入系统时，就会执行此方法，而这通常就是指应用程序启动的时候，若程序是为iOS平台设计的，则肯定会在此时执行。Mac OS X应用程序更自由一些，它们可以使用”动态加载“之类的特性，等应用程序启动好之后再去加载程序库。如果分类和其他所属的类都定义了load方法，则先调用类里的，再调用分类里的。

load方法的问题在于，执行该方法时，运行期系统处于”脆弱状态“。在执行子类的load方法之前，必定会先执行所有超类的load方法，而如果代码还依赖了其他程序库，那么程序库里相关类的load方法也必定会先执行。然而，根据某个给定的程序库，却无法判断出其中各个类的载入顺序。因此，在load方法中使用其他类是不安全的。

比方说：

  #import <Foundation/Foundation.h>
  #import "EOCClassA.h"// From the same library

@interface EOCClassB : NSObject

@end


@implementation EOCClassB
+(void)load
{
    NSLog(@"Loading EOCClassB");
    EOCClassA *object = [EOCClassA new];
    //Use 'object'
}
@end

此处使用NSLog没问题，而且相关字符串也会照常记录，因为Foundation框架肯定在运行load方法之前就已经载入系统了。但是，在EOCClassB的load方法里使用EOCClassA却不太安全，因为无法确定在执行EOCClassB的load方法之前，EOCClassA是不是已经记载好了。可以想见：EOCClassA这个类，也许会在其load方法中执行某些重要操作，只有执行完这些操作之后，该类实例才能正常使用。

有个重要的事情需注意，那就是load方法并不像普通的方法那样，它并不遵从那套继承规则，如果某个类本身没实现load方法，那么不管其各级超类是否实现此方法，系统都不会调用。此外，分类和其所属的类里，都可能出现load方法。此时两种实现代码都会调用，类的实现要比分类的实现先执行。

而且load方法务必实现得精简一些，也就是要尽量减少其所执行的操作，因为整个应用程序在执行load方法时都会阻塞。如果load方法中包含繁杂的代码，那么应用程序在执行期间就会变得无响应。不要在里面等待锁，也不要调用可能会加锁的方法。总之，能不做的事情就别做。

想执行与类相关的初始化操作，还有个办法，就是覆写下列方法：

+ (void)initialize;

对于每个类来说，该方法会在程序首次用该类之前调用，且只调用一次。它是由运行期系统来调用的，绝不应该通过代码直接调用。其虽与load相似，但却有几个非常重要的微妙区别。首先，它是”惰性调用的“，也就是说，只有当程序用到了相关的类时，才会调用。因此，如果某个类一直都没有使用，那么其initialize方法就一直不会运行。这也就是说，应用程序无须先把每个类的initialize都执行一遍，这与load方法不同，对于load来说，应用程序必须则色并等着所有类的load都执行完，才能继续。

此方法与load还有个区别，就是运行期系统在执行该方法时，是处于正常状态的，因此，从运行期系统完整度上来讲，此时可以安全使用并调用任意类中的任意方法。而且，运行期系统也能保证initialize方法一定会在”线程安全的环境“中执行，这就是说，只有执行initialize的那个线程可以操作类或类的实例。其他线程都要先则色，等着initialize执行完。

最后一个区别是：initialize方法与其他消息一样，如果某个类未实现它，而其超类实现了，那么就会运行超类的实现代码。

initialize也遵循通常的继承规则，通常都会这么来实现initialize方法：

+(void)initialize
{
    if(self = [EOCBaseClass class])
    {
        NSLog(@"%@ initialized",self);
    }
}

加上这条检测语句之后，只有当开发者所期望的那个类载入系统时，才会执行相关的初始化操作。

在load和initialize方法中尽量精简代码，在里面设置一些状态，使本类能够正常运作就可以了，不要执行那种耗时太久或需要加锁的任务。

开发者无法控制类的初始化时机。类在首次使用之前，肯定要初始化，但编写程序时不能令代码依赖特定的时间点，否则会很危险。运行期系统将来更新了之后，可能会略微改变类的初始化方式，这样的话，开发者原来如果假设某个类必定会在某个具体时间点初始化，那么现在这条假设可能就不成立了。

如果某个类的实现代码很复杂，那么其中可能会直接或间接用到其他类。若那些类尚未初始化，则系统会迫使其初始化。然而，本类的初始化方法此时尚未运行完毕。其他类在运行其initialize方法时，有可能会依赖本类中的某些数据，而这些数据此时也许还未初始化好。

若某个全局状态无法在编译期初始化，则可以在initialize里来做：

  #import "EOCClass.h"

static const int kInterval = 10;
static NSMutableArray *kSomeObjects;


+(void)initialize
{
    if(self = [EOCClass class])
    {
        kSomeObjects = [NSMutableArray new];
    }
}

要点：

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

---

52.别忘了NSTimer回保留其目标对象

计时器要和“运行循环”（run loop）相关联，运行循环到时候会触发任务。创建NSTimer时，可以将其“预先安排”在当前的运行循环中，也可以先创建好，然后由开发者自己来调度。无论采用哪种方式，只有把计时器放在运行循环里，它才能正常触发任务。

例如下面这个方法可以创建计时器，并将其预先安排在当前运行循环中：

+ (NSTimer *)timerWithTimeInterval:(NSTimeInterval)ti 
                              target:(id)aTarget 
                            selector:(SEL)aSelector 
                            userInfo:(nullable id)userInfo repeats:(BOOL)yesOrNo;

要点：

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

---

写在最后：

到此，终于读完了《Effective Objective-C 2.0》这本书，其实从去年就计划读这本书了，因为赶项目就没抽出时间好好读书。在阅读过程中发现，书中的有些知识点是自己知道的；有些是自己了解一点点并知道如何用，但是不知道为什么可以这么用的；还有些是自己平常没注意或者没用过的知识点。有时候读到某个知识点，然后联想到自己曾经使用过程中遇到的问题或者不理解的地方，就有种豁然开朗的感觉，这种感觉真的很棒、很兴奋。这种兴奋的感觉可以激发自己继续阅读下去的欲望，真是不得不佩服作者在iOS开发上的造诣。同时，也认识到了自己的不足，以后还得更加努力。最后，非常感觉作者Matt Galloway为我们分享了他的这些开发经验。

---

转载请注明出处：第七章 系统框架

参考：《Effective Objective-C 2.0》