自定义Xib视图时super.init的作用及相关使用疑问

Great questions—let’s break this down step by step, since understanding initializer behavior in UIKit is crucial for building stable, working views.

In Swift (and Objective-C before it), when you create a subclass (like your HeaderStyle1 inheriting from UIView), the subclass doesn’t automatically handle the initialization logic of its parent class.

UIView has a ton of internal setup that happens during initialization: it creates its underlying CALayer (the thing that actually renders pixels on screen), sets default properties like backgroundColor (to clear), isUserInteractionEnabled (to true), and initializes layout-related state.

Calling super.init(...) tells the parent class (UIView) to run its own initialization code. If you skip this, the parent’s internal state will be uninitialized, leading to crashes, broken rendering, or views that don’t respond to user input. It’s like building a house: you can’t add your custom rooms (subclass code) until the foundation (parent class setup) is in place.

For example, when you call super.init(frame: frame) for a code-created UIView, you’re letting UIView set up its initial frame, create the layer, and prepare all the core systems that make a view work.

When you load a view from a Xib, the system uses the init?(coder: NSCoder) initializer (since Xibs are archived as XML that gets decoded at runtime). Here, super.init(coder: coder) is just as critical: it tells UIView to decode all the information from the Xib—like the subviews you added in Interface Builder, their constraints, and any properties you set there.

If you skip super.init(coder:) in a Xib-based view, none of the Xib’s content will be loaded properly. Your custom view will be an empty shell, because the parent class never got the chance to unpack the Xib’s archive data.

When you add your HeaderStyle1 instance to a view controller’s view with addSubview(header), UIKit adds it to the view hierarchy. Once it’s part of that hierarchy, UIKit will handle laying it out (via Auto Layout or frame-based layout) and rendering it on screen.

This process directly depends on super.init having been called correctly:

• super.init ensures the view has a valid CALayer (the rendering layer)
• It sets up the view’s ability to participate in layout (so constraints or frames work)
• It initializes the state needed for UIKit to recognize the view as part of the hierarchy

If super.init was skipped, the view would lack these core components. Even if you call addSubview, UIKit wouldn’t be able to render it—you’d either see nothing, or get a runtime crash when the system tries to access uninitialized parts of the view.

Quick code example to tie it all together #

Here’s how a proper Xib-based custom view initializer looks:

class HeaderStyle1: UIView {
    // Your custom subviews/properties
    @IBOutlet weak var titleLabel: UILabel!

    // For code-based initialization
    override init(frame: CGRect) {
        super.init(frame: frame) // First, let UIView set up its foundation
        commonSetup() // Your custom setup (e.g., load Xib, configure labels)
    }

    // For Xib-based initialization
    required init?(coder: NSCoder) {
        super.init(coder: coder) // Let UIView decode the Xib data
        commonSetup()
    }

    private func commonSetup() {
        // Load the Xib content into this view
        let nib = UINib(nibName: "HeaderStyle1", bundle: nil)
        if let contentView = nib.instantiate(withOwner: self).first as? UIView {
            contentView.frame = bounds
            contentView.autoresizingMask = [.flexibleWidth, .flexibleHeight]
            addSubview(contentView)
        }
    }
}

Notice how both initializers call super.init first (or right after any subclass property initialization) before doing custom work. That’s the key pattern to follow.

内容的提问来源于stack exchange，提问作者John