Designated Initializer(指定初始化器)在Objective－C里面是很重要的概念，但是在日常开发中我们往往会忽视它的重要性，以至于我们写出的代码具有潜藏的Bug，且不易发现。保证良好的编写Designated Initializer的风格，可以让我们节约很多时间。 前段时间@吴发伟Ted分享了一篇Twitter团队的一篇博客，里面讲述了Designated Initializer正确的模板以及需要注意的问题。但是里面关于initWithCoder描述不是很清晰，且随后@an00na给出了不同的看法。我会在接下来的文章讲述验证他们给出的编写Designated Initializer的原则，并对initWithCoder的分歧做一个分析，了解其背后的机制。
为了能够跟踪代码的实际调用顺序，在下面的实例分析中，我将会使用Xtrace。这是一个在调试上非常强大的一个库，实现原理是通过Hook的方式跟踪消息。详细可以看Github上的说明。 需要注意的是，Xtrace里面设定了不跟踪initWithCoder，由于我们后面分析的需要我们需要把Xtrace.h里面的一段代码做一些小改动：
| 1 2 3 | #define XTRACE_EXCLUSIONS "^(initWithCoder|_UIAppearance_|"\ "_(initializeFor|performUpdatesForPossibleChangesOf)Idiom:|"\ "timeIntervalSinceReferenceDate)|(WithObjects(AndKeys)?|Format):$" |
这段代码标示了不跟踪的@selector，我们需要将initWithCoder删除，才能跟踪这个方法。
接下来，我们需要在AppDelegate.m里面加入一段代码：
| 1 2 3 4 5 6 7 8 9 10 | - (id)init{ if (self=[super init]){ [Xtrace includeMethods:@"^init"];//1. [Xtrace traceClass:[ViewController class]]; [Xtrace traceClass:[TestInitView class]]; [Xtrace traceClass:[SubTestInitView class]]; [Xtrace traceClass:[NSObject class]];//2. } return self; } |
我会先给出我认为应该遵循的原则，并对每个原则做实际分析。
TestInitView是一个继承于UIView，它重新指定的初始化器为initWithFrame:andName:。现在，假设这个类的初始化器如下：
| 1 2 3 4 5 6 7 8 | //Designated Initializer - (instancetype)initWithFrame:(CGRect)frame andName:(NSString *)name{ //incorrect if (self = [super init]){ self.name=name; } return self; } |
可以看到在里面并没有调用UIView的Designated InitializerinitWithFrame:。那么会有什么后果呢？
我们用这个Designated Initializer生成一个TestInitView对象：
| 1 | TestInitView *testView = [[TestInitView alloc] initWithFrame:CGRectZero andName:@""]; |
运行程序，我们会看到Xtrce的跟踪记录如下：
| 1 2 3 4 5 6 7 8 | | [<TestInitView 0x8c6c840> initWithFrame:{} andName:<__NSCFConstantString 0x6d278>] | [<TestInitView 0x8c6c840>/UIView init] | [<TestInitView 0x8c6c840>/UIView initWithFrame:{}] | [<TestInitView 0x8c6c840>/NSObject init] | -> <TestInitView 0x8c6c840> (init) | -> <TestInitView 0x8c6c840> (initWithFrame:) | -> <TestInitView 0x8c6c840> (init) | -> <TestInitView 0x8c6c840> (initWithFrame:andName:) |
咦，似乎没有问题啊。整个继承链的初始化器都被调用了。等等，如果我们用UIView的Designated Initializer生成一个TestInitView对象会怎样呢？
| 1 | TestInitView *testView = [[TestInitView alloc] initWithFrame:CGRectZero]; |
运行代码后，我们得到的调用过程如下：
| 1 2 3 4 | | [<TestInitView 0xa16cd40>/UIView initWithFrame:{}] | [<TestInitView 0xa16cd40>/NSObject init] | -> <TestInitView 0xa16cd40> (init) | -> <TestInitView 0xa16cd40> (initWithFrame:) |
这时会发现TestInitView的初始化器initWithFrame:andName:没有被调用。
我们再修改下代码：
| 1 2 3 4 5 6 7 8 | //Designated Initializer - (instancetype)initWithFrame:(CGRect)frame andName:(NSString *)name{ //incorrect if (self = [super initWithFrame:frame]){ self.name=name; } return self; } |
我们依然使用UIView的Designated Initializer，然后运行程序得到下面的结果：
| 1 2 3 4 | | [<TestInitView 0xa81d3f0>/UIView initWithFrame:{}] | [<TestInitView 0xa81d3f0>/NSObject init] | -> <TestInitView 0xa81d3f0> (init) | -> <TestInitView 0xa81d3f0> (initWithFrame:) |
TestInitView的初始化器依然没有被调用。原因就是没有我们没有重写父类UIView的Designated Initializer。修改后我们的最终代码如下：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 | //Designated Initializer - (instancetype)initWithFrame:(CGRect)frame andName:(NSString *)name{ //incorrect if (self = [super initWithFrame:frame]){ self.name=name; } return self; } //super override - (id)initWithFrame:(CGRect)frame { return [self initWithFrame:frame andName:@""]; } |
继续测试我们的代码，得到的结果如下：
| 1 2 3 4 5 6 7 8 | | [<TestInitView 0xa549920> initWithFrame:{}] | [<TestInitView 0xa549920> initWithFrame:{} andName:<__NSCFConstantString 0x6ce2c>] | [<TestInitView 0xa549920>/UIView initWithFrame:{}] | [<TestInitView 0xa549920>/NSObject init] | -> <TestInitView 0xa549920> (init) | -> <TestInitView 0xa549920> (initWithFrame:) | -> <TestInitView 0xa549920> (initWithFrame:andName:) | -> <TestInitView 0xa549920> (initWithFrame:) |
OK,运行正确！
也就是说，上面的代码，我们可以不写Designated Initializer，也可以这么修改：
| 1 2 3 4 5 6 7 8 | //Designated Initializer - (instancetype)initWithFrame:(CGRect)frame{ //incorrect if (self = [super initWithFrame:frame]){ self.name=name; } return self; } |
但是下面这样写就是错误的，因为调用的不是直接父类的Designated Initializer
| 1 2 3 4 5 6 7 8 | //Designated Initializer - (instancetype)initWithFrame:(CGRect)frame{ //incorrect if (self = [super init]){ self.name=name; } return self; } |
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 | #import "TestInitView.h" @implementation TestInitView //super override - (id)initWithFrame:(CGRect)frame { return [self initWithFrame:frame andName:@""]; } //Designated Initializer - (instancetype)initWithFrame:(CGRect)frame andName:(NSString *)name{ if (self = [super initWithFrame:frame]){ self.name=name; } return self; } //Instance secondary initializer - (instancetype)initWithName:(NSString *)name{ return [self initWithFrame:CGRectZero andName:name]; } //Instance secondary initializer - (instancetype)initWithName2:(NSString *)name{ return [self initWithName:name]; } //Class secondary initializer + (instancetype)testInitViewWithName:(NSString *)name{ TestInitView *testView=[[TestInitView alloc] initWithFrame:CGRectZero andName:name]; if (testView){ //do something here } return testView; } @end |
可以看到方法initWithName2调用的顺序是initWithName2–>initWithName–>initWithFrame:andName:，最后指向了Designated Initializer。同时需要注意的是，Secondary initializers不仅可以是实例方法，也可以是静态方法，如代码实例中的testInitViewWithName:。
文章开头我就提到两篇引用文章关于initWithCoder的分歧。 首先，如果直接父类也实现了NSCoding协议，那么子类的initWithCoder也必须调用父类的initWithCoder。
这点大家的观点都是相同的，苹果官方文档也是这么说的。
主要的分歧在于当直接父类不实现NSCoding时，子类的initWithCoder应该调用哪个初始化器。
Twitter团队的那片博客给出的看法是：
There’s a problem with the example provided in the documentation for initWithCoder:, specifically the call to [super (designated initializer)]. If you’re a direct subclass of NSObject, calling [super (designated initializer)] won’t call your [self (designated initializer)]. If you’re not a direct subclass of NSObject, and one of your ancestors implements a new designated initializer, calling [super (designated initializer)] WILL call your [self (designated initializer)]. This means that apple’s suggestion to call super in initWithCoder encourages non-deterministic initialization behavior, and is not consistent with the solid foundations laid by the designated initializer pattern. Therefore, my recommendation is that you should treat initWithCoder: as a secondary initializer, and call [self (designated initializer)], not [super (designated initializer)], if your superclass does not conform to NSCoding.
直接理解有点困难，我们用代码来说话。我们新建一个类SubTestInitView,它继承于TestInitView，且它实现NSCoding协议。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | #import "SubTestInitView.h" @implementation SubTestInitView - (instancetype)initWithFrame:(CGRect)frame andName:(NSString *)name{ if (self = [super initWithFrame:frame andName:name]){ self.subName=name; } return self; } - (id)initWithCoder:(NSCoder *)aDecoder{ if (self=[super initWithFrame:CGRectZero andName:@""]){ } return self; } - (void)encodeWithCoder:(NSCoder *)aCoder{ } @end |
可以看到，我们在initWithCoder:里面调用的是TestInitView的Designated Initializer。让我们看看调用顺序(P.S. 在xib里面拖入一个View，然后指定其类型为SubTestInitView，这样就会调用其initWithCoder:)：
| 1 2 3 4 5 6 7 8 | | [<SubTestInitView 0xa00a8c0> initWithCoder:<UINibDecoder 0x990fa00>] | [<SubTestInitView 0xa00a8c0>/TestInitView initWithFrame:{} andName:<__NSCFConstantString 0x6df0c>] | [<SubTestInitView 0xa00a8c0>/UIView initWithFrame:{}] | [<SubTestInitView 0xa00a8c0>/NSObject init] | -> <SubTestInitView 0xa00a8c0> (init) | -> <SubTestInitView 0xa00a8c0> (initWithFrame:) | -> <SubTestInitView 0xa00a8c0> (initWithFrame:andName:) | -> <SubTestInitView 0xa00a8c0> (initWithCoder:) |
根据引用的内容，其认为会调用顺序中有[self (designated initializer)]，也就是SubTestInitView 的- (instancetype)initWithFrame:(CGRect)frame andName:(NSString *)name，但是实际结果并不是这样的。子类的Designated Initializer并没有被调用。而最后其建议将initWithCoder:视为Secondary initializers，然后在里面调用[self (designated initializer)]。这样做的目的是为了保证[self (designated initializer)]会被调用，以保证初始化是正确的。
对此，@an00na则提出不一致的看法。
@an00na引入了数据源的概念，他认为initWithCoder:是用另一个数据源NSDecoder初始化的。一个类可以由多个数据源初始化，也就是说可以有多个Designated Initializer。因此，initWithCoder是Designated Initializer，而根据我们前面提到的原则，我们应该调用父类的Designated Initializer。
这个时候，我产生了疑惑。按照这个说法，此时应该如代码所示，调用父类TestInitView的initWithFrame:andName:明显有问题，因为并非是同个数据源。可是父类并没有实现NSCoding，我们可以调用他的initWithCoder(实际上是UIView的)吗？
我注意到UIButton的继承顺序是UIButton->UIControl->UIView…，UIControl同样没有实现NSCoding，那么对于这种情况，apple又是如何做的呢？我跟踪了UIButton的生成过程：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | | [<UIButton 0x9c7e400> initWithFrame:{}] | [<UIButton 0x9c7e400>/UIControl initWithFrame:{}] | [<UIButton 0x9c7e400>/UIView initWithFrame:{}] | [<UIButton 0x9c7e400>/NSObject init] | -> <UIButton 0x9c7e400> (init) | -> <UIButton 0x9c7e400> (initWithFrame:) | -> <UIButton 0x9c7e400> (initWithFrame:) | -> <UIButton 0x9c7e400> (initWithFrame:) 2014-04-16 01:36:12.948 BlogDemo[2128:60b] ------------- | [<UIButton 0x8eba7f0> initWithCoder:<UINibDecoder 0x9373600>] | [<UIButton 0x8eba7f0>/UIControl initWithCoder:<UINibDecoder 0x9373600>] | [<UIButton 0x8eba7f0>/UIView initWithCoder:<UINibDecoder 0x9373600>] | [<UIButton 0x8eba7f0>/NSObject init] | -> <UIButton 0x8eba7f0> (init) | -> <UIButton 0x8eba7f0> (initWithCoder:) | -> <UIButton 0x8eba7f0> (initWithCoder:) | -> <UIButton 0x8eba7f0> (initWithCoder:) |
间隔线上面是以[UIButton buttonWithType:UIButtonTypeCustom]方式初始化的UIButton，下面的则是通过xib初始化的UIButton。我们可以看到，下面的初始化顺序并没由调用到initWithFrame:,这也证明了@an00na关于数据源的看法。而同时可以发现中间调用了UIControl的initWithCoder:!
于是，在这里，我认为如果你的自定义类的其中一个父类实现了NSCoding协议，而且你有扩展属性，虽然你本身没有声明会实现NSCoding协议，你也需要实现NSCoding的两个方法：initWithCoder:和encodeWithCoder:,并对你扩展的属性做coding操作。
给TestInitView补上这两个方法，SubTestInitView的initWithCoder也调用父类的initWithCoder后，让我们再看看实际的调用顺序：
| 1 2 3 4 5 6 7 8 | | [<SubTestInitView 0xa664e70> initWithCoder:<UINibDecoder 0xd880600>] | [<SubTestInitView 0xa664e70>/TestInitView initWithCoder:<UINibDecoder 0xd880600>] | [<SubTestInitView 0xa664e70>/UIView initWithCoder:<UINibDecoder 0xd880600>] | [<SubTestInitView 0xa664e70>/NSObject init] | -> <SubTestInitView 0xa664e70> (init) | -> <SubTestInitView 0xa664e70> (initWithCoder:) | -> <SubTestInitView 0xa664e70> (initWithCoder:) | -> <SubTestInitView 0xa664e70> (initWithCoder:) |
经过上面的探讨，我们了解了多数据源的设计模型。但是这带来了另外一个问题：如何使得通过不同数据源初始化动作是一致的？
比如说，我们往往需要再对象初始化紧接着做一些动作。由于多数据源的存在，并且不同的数据源提供的数据内容不一样，我们应当如何处理？
很自然的，我们可能会想到讲部分动作重构成一个方法，无论从哪个数据源初始化，都调用这个方法。
如果是自己编写的不同数据源的Designated Initializer，具体调用这个方法的时机需要自己把握。我在这里着重讲一下UIView或UIViewController的子类在处理多数据源需要注意的问题。
按前面所述，UIView和UIViewController的子类需要实现NSCoding的两个方法。但是我们需要注意的是，同样是调用initWithCoder，却仍然可能是不同的数据源：UINibDecoder或者NSKeyedUnarchiver。
这两者分别代表什么情况呢？UINibDecoder是指xib初始化，而NSKeyedUnarchiver是指通过归档文件(如plist/txt等物理文件)初始化。它们最大的区别是UINibDecoder仅包含了xib里面能够设置的数据，而NSKeyedUnarchiver包括了整个对象的数据，也就是说如果是从NSKeyedUnarchiver初始化的，是不再需要额外的初始化动作了。而如果是从UINibDecoder初始化的，则在对象初始化后，会调用其awakeFromNib方法，我们需要把额外的初始化动作写在这里。
根据这个，我再次改写了TestInitView如下：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 | #import "TestInitView.h" @implementation TestInitView //super override - (id)initWithFrame:(CGRect)frame { return [self initWithFrame:frame andName:@""]; } //Designated Initializer - (instancetype)initWithFrame:(CGRect)frame andName:(NSString *)name{ if (self = [super initWithFrame:frame]){ [self someInit]; self.name=name; //correct From Name } return self; } - (id)initWithCoder:(NSCoder *)aDecoder{ if (self=[super initWithCoder:aDecoder]) { self.name=[aDecoder decodeObjectForKey:@"name"]; //correct From NSKeyedUnarchiver } return self; } - (void)encodeWithCoder:(NSCoder *)aCoder{ [super encodeWithCoder:aCoder]; [aCoder encodeObject:self.name forKey:@"name"]; } - (void)awakeFromNib{ [super awakeFromNib]; [self someInit]; //correct From UINibDecoder } - (void)someInit{ self.name=@""; //anyelse.... } @end |
这样我们就可以保证无论是从什么数据源初始化，得出的结果都是正确的了。事实上，如果在工程中我们没有对UIView或UIViewController的子类对象有归档的需求的话，NSCoding的两个方法可以省去不写。
经过一番长篇大论:)，我们可以总结正确编写Designated Initializer的原则如下：
P.S.尽管我做了很多实例分析研究，但经验所限可能仍有不足或不对之处，欢迎指正。本文内大量内容来源Twitter团队博客的那篇文章以及@an00na的文章，我仅仅是用中文做了讲述，在此表示十分感谢！
联系客服
