如何正确的初始化

UIView 的首要问题就是既能从代码中初始化，也能从 xib 中初始化，两者有何不同? UIView 是支持 NSCoding 协议的，当在 xib 或 storyboard 里存在一个 UIView 的时候，其实是将 UIView 序列化到文件里（xib 和 storyboard 都是以 XML 格式来保存的），加载的时候反序列化出来，所以：

• 当从代码实例化 UIView 的时候，initWithFrame 会执行；
• 当从文件加载 UIView 的时候，initWithCoder 会执行。

从代码中加载

虽然 initWithFrame 是 UIView 的Designated Initializer，理论上来讲你继承自 UIView 的任何子类，该方法最终都会被调用，但是有一些类在初始化的时候没有遵守这个约定，如 UIImageView 的 initWithImage 和 UITableViewCell 的 initWithStyle:reuseIdentifier: 的构造器等，所以我们在写自定义控件的时候，最好只假设父视图的 Designated Initializer 被调用。

如果控件在初始化或者在使用之前必须有一些参数要设置，那我们可以写自己的 Designated Initializer 构造器，如：

1

- (instancetype)initWithName:(NSString *)name;

在实现中一定要调用父类的 Designated Initializer，而且如果你有多个自定义的 Designated Initializer，最终都应该指向一个全能的初始化构造器：

1

2

3

4

5

6

7

8

9

10

11

12

- (instancetype)initWithName:(NSString *)name {

    self = [self initWithName:name frame:CGRectZero];

    return self;

}

 

- (instancetype)initWithName:(NSString *)name frame:(CGRect)frame {

    self = [super initWithFrame:frame];

    if (self) {

        self.name = name;

    }

    return self;

}

并且你要考虑到，因为你的控件是继承自 UIView 或 UIControl 的，那么用户完全可以不使用你提供的构造器，而直接调用基类的构造器，所以最好重写父类的 Designated Initializer，使它调用你提供的 Designated Initializer ，比如父类是个 UIView：

1

2

3

4

- (instancetype)initWithFrame:(CGRect)frame {

    self = [self initWithName:nil frame:frame];

    return self;

}

这样当用户从代码里初始化你的控件的时候，就总是逃脱不了你需要执行的初始化代码了，哪怕用户直接调用 init 方法，最终还是会回到父类的 Designated Initializer 上。

从 xib 或 storyboard 中加载

当控件从 xib 或 storyboard 中加载的时候，情况就变得复杂了，首先我们知道有 initWithCoder 方法，该方法会在对象被反序列化的时候调用，比如从文件加载一个 UIView 的时候：

1

2

3

4

5

6

7

8

9

UIView *view = [[UIView alloc] init];

NSData *data = [NSKeyedArchiver archivedDataWithRootObject:view];

 

[[NSUserDefaults standardUserDefaults] setObject:data forKey:@"KeyView"];

[[NSUserDefaults standardUserDefaults] synchronize];

 

data = [[NSUserDefaults standardUserDefaults] objectForKey:@"KeyView"];

view = [NSKeyedUnarchiver unarchiveObjectWithData:data];

NSLog(@"%@", view);

执行 unarchiveObjectWithData 的时候， initWithCoder 会被调用，那么你有可能会在这个方法里做一些初始化工作，比如恢复到保存之前的状态，当然前提是需要在 encodeWithCoder 中预先保存下来。

不过我们很少会自己直接把一个 View 保存到文件中，一般是在 xib 或 storyboard 中写一个 View，然后让系统来完成反序列化的工作，此时在 initWithCoder 调用之后，awakeFromNib 方法也会被执行，既然在 awakeFromNib 方法里也能做初始化操作，那我们如何抉择?

一般来说要尽量在 initWithCoder 中做初始化操作，毕竟这是最合理的地方，只要你的控件支持序列化，那么它就能在任何被反序列化的时候执行初始化操作，这里适合做全局数据、状态的初始化工作，也适合手动添加子视图。

awakeFromNib 相较于 initWithCoder 的优势是：当 awakeFromNib 执行的时候，各种IBOutlet 也都连接好了；而 initWithCoder 调用的时候，虽然子视图已经被添加到视图层级中，但是还没有引用。如果你是基于 xib 或 storyboard 创建的控件，那么你可能需要对 IBOutlet 连接的子控件进行初始化工作，这种情况下，你只能在 awakeFromNib 里进行处理。同时 xib 或 storyboard 对灵活性是有打折的，因为它们创建的代码无法被继承，所以当你选择用 xib 或 storyboard 来实现一个控件的时候，你已经不需要对灵活性有很高的要求了，唯一要做的是要保证用户一定是通过 xib 创建的此控件，否则可能是一个空的视图，可以在 initWithFrame 里放置一个 断言 或者异常来通知控件的用户。

最后还要注意视图层级的问题，比如你要给 View 放置一个背景，你可能会在 initWithCoder 或 awakeFromNib 中这样写：

1

[self addSubview:self.backgroundView]; // 通过懒加载一个背景 View，然后添加到视图层级上

你的本意是在控件的最下面放置一个背景，却有可能将这个背景覆盖到控件的最上方，原因是用户可能会在 xib 里写入这个控件，然后往它上面添加一些子视图，这样一来，用户添加的这些子视图会在你添加背景之前先进入视图层级，你的背景被添加后就挡住了用户的子视图。如果你想支持用户的这种操作，可以把 addSubview 替换成 insertSubview:atIndex:。

同时支持从代码和文件中加载

如果你要同时支持 initWithFrame 和 initWithCoder ，那么你可以提供一个 commonInit 方法来做统一的初始化：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

- (id)initWithCoder:(NSCoder *)aDecoder {

    self = [super initWithCoder:aDecoder];

    if (self) {

        [self commonInit];

    }

    return self;

}

 

- (id)initWithFrame:(CGRect)frame {

    self = [super initWithFrame:frame];

    if (self) {

        [self commonInit];

    }

 

    return self;

}

 

- (void)commonInit {

    // do something ...

}

awakeFromNib 方法里就不要再去调用 commonInit 了。

---

调整布局的时机

当一个控件被初始化以及开始使用之后，它的 frame 仍然可能发生变化，我们也需要接受这些变化，因为你提供的是 UIView 的接口，UIView 有很多种初始化方式：initWithFrame、initWithCoder、init 和类方法 new，用户完全可以在初始化之后再设置 frame 属性，而且用户就算使用 initWithFrame 来初始化也避免不了 frame 的改变，比如在横竖屏切换的时候。为了确保当它的 Size 发生变化后其子视图也能同步更新，我们不能一开始就把布局写死（使用约束除外）。

基于 frame

如果你是直接基于 frame 来布局的，你应该确保在初始化的时候只添加视图，而不去设置它们的frame，把设置子视图 frame 的过程全部放到 layoutSubviews 方法里：

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

- (instancetype)initWithCoder:(NSCoder *)aDecoder {

    self = [super initWithCoder:aDecoder];

    if (self) {

        [self commonInit];

    }

    return self;

}

 

- (instancetype)initWithFrame:(CGRect)frame {

    self = [super initWithFrame:frame];

    if (self) {

        [self commonInit];

    }

    return self;

}

 

- (void)layoutSubviews {

    [super layoutSubviews];

 

    self.label.frame = CGRectInset(self.bounds, 20, 0);

}

 

- (void)commonInit {

    [self addSubview:self.label];

}

 

- (UILabel *)label {

    if (_label == nil) {

        _label = [UILabel new];

        _label.textColor = [UIColor grayColor];

    }

    return _label;

}

这么做就能保证 label 总是出现在正确的位置上。

使用 layoutSubviews 方法有几点需要注意：

1. 不要依赖前一次的计算结果，应该总是根据当前最新值来计算
2. 由于 layoutSubviews 方法是在自身的 bounds 发生改变的时候调用， 因此 UIScrollView 会在滚动时不停地调用，当你只关心 Size 有没有变化的时候，可以把前一次的 Size 保存起来，通过与最新的 Size 比较来判断是否需要更新，在大多数情况下都能改善性能

基于 Auto Layout 约束

如果你是基于 Auto Layout 约束来进行布局，那么可以在 commonInit 调用的时候就把约束添加上去，不要重写 layoutSubviews 方法，因为这种情况下它的默认实现就是根据约束来计算 frame。最重要的一点，把 translatesAutoresizingMaskIntoConstraints 属性设为 NO，以免产生 NSAutoresizingMaskLayoutConstraint 约束，如果你使用 Masonry 框架的话，则不用担心这个问题，mas_makeConstraints 方法会首先设置这个属性为 NO:

1

2

3

4

5

6

7

8

9

10

- (void)commonInit {

    ...

    [self setupConstraintsForSubviews];

}

 

- (void)setupConstraintsForSubviews {

    [self.label mas_makeConstraints:^(MASConstraintMaker *make) {

        ...

    }];

}

 

支持 sizeToFit

如果你的控件对尺寸有严格的限定，比如有一个统一的宽高比或者是固定尺寸，那么最好能实现系统给出的约定成俗的接口。

sizeToFit 用在基于 frame 布局的情况下，由你的控件去实现 sizeThatFits: 方法：

1

2

3

4

5

6

- (CGSize)sizeThatFits:(CGSize)size {

    CGSize fitSize = [super sizeThatFits:size];

    fitSize.height += self.label.frame.size.height;

    // 如果是固定尺寸，就像 UISwtich 那样返回一个固定 Size 就 OK 了

    return fitSize;

}

然后在外部调用该控件的 sizeToFit 方法，这个方法内部会自动调用 sizeThatFits 并更新自身的 Size：

1

[self.customViewsizeToFit];

 

在 ViewController 里调整视图布局

当执行 viewDidLoad 方法时，不要依赖 self.view 的 Size。很多人会这样写：

1

2

3

4

- (void)viewDidLoad {

    ...

    self.label.width = self.view.width;

}

这样是不对的，哪怕看上去没问题也只是碰巧没问题而已。当 viewDidLoad 方法被调用的时候，self.view 才刚刚被初始化，此时它的容器还没有对它的 frame 进行设置，如果 view 是从 xib 加载的，那么它的 Size 就是 xib 中设置的值；如果它是从代码加载的，那么它的 Size 和屏幕大小有关系，除了 Size 以外，Origin 也不会准确。整个过程看起来像这样：

当访问 ViewController 的 view 的时候，ViewController 会先执行 loadViewIfRequired 方法，如果 view 还没有加载，则调用 loadView，然后是 viewDidLoad 这个钩子方法，最后是返回 view，容器拿到 view 后，根据自身的属性（如 edgesForExtendedLayout、判断是否存在 tabBar、判断 navigationBar 是否透明等）添加约束或者设置 frame。

你至少应该设置 autoresizingMask 属性：

1

2

3

4

5

- (void)viewDidLoad {

    ...

    self.label.width = self.view.width;

    self.label.autoresizingMask = UIViewAutoresizingFlexibleWidth;

}

或者在 viewDidLayoutSubviews 里处理：

1

2

3

4

5

- (void)viewDidLayoutSubviews {

    [super viewDidLayoutSubviews];

 

    self.label.width = self.view.width;

}

如果是基于 Auto Layout 来布局，则在 viewDidLoad 里添加约束即可。

---

正确的处理 touches 方法

如果你需要重写 touches 方法，那么应该完整的重写这四个方法：

1

2

3

4

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event;

- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event;

- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event;

- (void)touchesCancelled:(NSSet *)touches withEvent:(UIEvent *)event;

当你的视图在这四个方法执行的时候，如果已经对事件进行了处理，就不要再调用 super 的 touches 方法，super 的 touches 方法默认实现是在响应链里继续转发事件（UIView 的默认实现）。如果你的基类是 UIScrollView 或者 UIButton 这些已经重写了事件处理的类，那么当你不想处理事件的时候可以调用 self.nextResponder 的 touches 方法来转发事件，其他的情况就调用 super 的 touches 方法来转发，比如 UIScrollView 可以这样来转发 触摸 事件：

1

2

3

4

5

6

7

8

9

10

11

12

13

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {

    if (!self.dragging) {

        [self.nextResponder touchesBegan: touches withEvent:event]; 

    } 

    [super touchesBegan: touches withEvent: event];

}

 

- (void)touchesMoved...

 

- (void)touchesEnded...

 

- (void)touchesCancelled...

这么实现以后，当你仅仅只是“碰”一个 UIScrollView 的时候，该事件就有可能被 nextResponder 处理。

如果你没有实现自己的事件处理，也没有调用 nextResponder 和 super，那么响应链就会断掉。另外，尽量用手势识别器去处理自定义事件，它的好处是你不需要关心响应链，逻辑处理起来也更加清晰，事实上，UIScrollView 也是通过手势识别器实现的：

1

2

3

@property(nonatomic, readonly) UIPanGestureRecognizer *panGestureRecognizer NS_AVAILABLE_IOS(5_0); 

 

@property(nonatomic, readonly) UIPinchGestureRecognizer *pinchGestureRecognizer NS_AVAILABLE_IOS(5_0);