Snapkit源码阅读浅析

前言

SnapKit库的使用非常简单，它受到很多开发者的喜爱和使用。那么，我们知道了怎么使用它后，有没有想过它的源码是什么样子呢？现在，就让我们来看一下SnapKit的“内心世界”到底是怎样的五彩斑斓，才能够如此引起开发者们的垂涎和追捧？

SnapKit的github链接： 猛戳这里

SnapKit文件结构

SnapKit总共有34个文件, 每个文件都有各自的功能，文件之间又相互关联，起到链接的作用。它主要是基于系统API的NSLayoutConstraint类的一个封装， 将系统API的类、方法、属性、协议、结构体、枚举等整合起来，形成一条条独立、简洁、清爽、易用的布局链。

SnapKit Files.png

从上面图片中的列表可以看到，总的有34个文件，现在，你是否会一下子就感觉到头疼，这么多文件，那是不是很复杂？代码是不是特别多？一想到这里就头疼死了。

实际上，尽管SnapKit有那么多的文件，但是它们都相对来说比较简单，文件结构十分清晰，除了Constraint.swift文件超过了200行代码，其他基本都是几行到几十行不等，有些文件只有一个协议方法，甚至有好几个文件都只是定义一个别名而已，例如：ConstraintInsets.swift、ConstraintLayoutGuide.swift、ConstraintLayoutSupport.swift、ConstraintView.swift等。

struct1.png struct2.png

以上两张图几乎是SnapKit牵扯到的Class、Enum、Struct、protocol等结构，至于继承系统类或者器别名的没有写出来。事实上，为了更好地增强SnapKit的可读性和关联性，作者几乎对用到的系统API都做了封装。

SnapKit之snp浅析

为什么要说snp? 它有何特别之处？对于SnapKit布局来说，有什么作用?

因为在SnapKit布局中，我们一定且必须使用到snp, 先看下面的布局代码

let subview = UIView()
subview.backgroundColor = .purple
view.addSubview(subview)
subview.snp.makeConstraints { (make) in
    make.width.equalTo(100)
    make.height.equalTo(200)
    make.center.equalToSuperview()
}

在布局中，snp是当前所要布局view的一个延展属性， 在SnapKit源码中有

typealiasUIView.png extensionUIView.png

说明：在ConstraintView的extension中，还有很多已经废弃了的方法、属性，作者用了上面这个snp来代替，主要是因为实现代码更加swift化，也更加方便管理。

从本文中的文件结构的图片中可以看出，snp是一个结构体实例对象，结构体ConstraintViewDSL继承于ConstraintAttributesDSL协议。而在snp所属的结构体中，有着几个我们制作约束时所需要的实例方法和属性， 通过view.snp.的形式，我们就可以开始进行调用ConstraintViewDSL结构体的方法进行布局了，这是布局开始的第一步，也很好理解。

SnapKit之makeConstraints{}方法的浅析

继上面一个分析后，我们知道，在布局开始时，制作约束，必须调用ConstraintViewDSL结构体的方法来对视图进行布局，那我们就来看一下这个方法（已经把其他方法屏蔽，便于分析）

public struct ConstraintViewDSL: ConstraintAttributesDSL {

    public func makeConstraints(_ closure: (_ make: ConstraintMaker) -> Void) {
        ConstraintMaker.makeConstraints(item: self.view, closure: closure)
    }

    internal let view: ConstraintView
    
    internal init(view: ConstraintView) {
        self.view = view
    }
    
}

在拿到ConstraintViewDSL结构体实例后，从上面代码段中可以看出，我们就可以调用makeConstraints方法了。

在调用ConstraintViewDSL结构体的实例方法makeConstraints的时候，我们实质上是对ConstraintMaker 类的静态方法makeConstraints的调用，这里主要是做了一个回调而已。

这里面有一个ConstraintViewDSL结构体的初始化方法，用来保存当前的视图，也就是在我们调用subview.snp的时候, 就已经初始化结构体并且引入当前的视图了

public var snp: ConstraintViewDSL {
    return ConstraintViewDSL(view: self)
}

那么为何要引入当前的视图呢？原因是我们在调用制作约束makeConstraints的时候需要使用到当前的视图, 也就是下面这句代码中的view

ConstraintMaker.makeConstraints(item: self.view, closure: closure)

调用方式就是

subview.snp.makeConstraints { (make) in
    
}

既然调用subview.snp.makeConstraints实质上是调用ConstraintMaker类的静态方法makeConstraints来进行布局，那么现在，我们进入到ConstraintMaker类文件中来分析它的静态方法makeConstraints，看看它是如何操作布局的

ConstraintMaker类的makeConstraints布局浅析

在ConstraintMaker类中：

makeConstraints.png

然后我们可以传入参数第一个是item, 是一个LayoutConstraintItem, 它是一个类协议。因为ConstraintView继承这个协议，所以刚才在ConstraintViewDSL结构体的makeConstraints方法中，我们传入了当前的视图, 即在这里， item就是我们传入的当前的view。

我们再来看makeConstraints中, 有这两行代码

 let maker = ConstraintMaker(item: item)
 closure(maker)

这里为何要使用let maker = ConstraintMaker(item: item), 原因是我们在调用当前类的makeConstraints方法时，直接直接对当前类进行初始化，在获取到ConstraintMaker的实例的同时，也对ConstraintMaker的私有属性private let item: LayoutConstraintItem进行了初始化，如下

private let item: LayoutConstraintItem
private var descriptions = [ConstraintDescription]()
    
internal init(item: LayoutConstraintItem) {
      self.item = item
      self.item.prepare()
}

为何要获取ConstraintMaker的实例的原因是我们需要closure(maker), 也就是实例对象，这样的话，我们就可以在外面布局的时候通过make.width、make.right等来获取到ConstraintMaker的width、height、left、right等属性。

接着看makeConstraints中, 有

var constraints: [Constraint] = []
for description in maker.descriptions {
    guard let constraint = description.constraint else {
        continue
    }
    constraints.append(constraint)
}
for constraint in constraints {
    constraint.activateIfNeeded(updatingExisting: false)
}

首先是定义了约束的数组constraints, 数组中的元素Constraint是一个约束类，你先别管里面有什么，怎么实现，你现在只要知道它是约束，并且是一个类，现在被放到一个数组中，其他的我们后面会讲到。

接着，遍历我们刚刚初始化的类实例的属性descriptions, 也许有人就有疑问了，private var descriptions = [ConstraintDescription]()我根本就没有初始化过，哪来的值呢？好的，别急，等下再告诉你，你只要知道它是一个ConstraintDescription约束描述类， 遍历之后我们就可以拿到ConstraintDescription约束描述类的约束属性constraint了，但是它是一个可选类型，所以我们必须拆包处理，故用guard语句判断，如果约束存在，则往所定义的约束数组中添加约束， 不存在，退出本次循环，继续判断约束是否存在，直到所有的约束都添加完毕为止。

最后，遍历刚刚添加的约束数组，并且激活所有的约束。这个activateIfNeeded(updatingExisting: false)是约束类Constraint中的激活约束的方法，为什么这个里面的参数updatingExisting为何传的是false而不是true呢？因为这是一个makeConstraints方法，你给一个视图才开始布局，就需要更新已经存在的约束吗？才刚开始制作约束，哪来的“已经存在”的约束呢？所以传true的时候是针对updateConstraints方法的。 具体细节待我一一道来。

现在我们在刚才的分析中，存在三个疑点

• 疑点一，maker.descriptions是约束描述类，但未初始化，我们却使用了?

• 疑点二，Constraint是一个约束类，怎么实现的，为何要在这里创建、添加、激活?

• 疑点三，activateIfNeeded怎么实现？这里为何要使用它来激活约束?

ConstraintDescription约束描述类的布局浅析

为了解释上面我们提到的几个疑点，我们首先来看一下这个ConstraintDescription约束描述类是一个什么东西。为何不讲Constraint类呢？不是不讲，现在我们先知道它就是一个约束类，在刚才的makeConstraints方法中，它是一个数组的元素，我们现在是在添加元素，而添加的元素恰好是对maker.descriptions的一个遍历，所以，我们会先来看ConstraintDescription约束描述类，再看Constraint约束类。

先来看其源码

public class ConstraintDescription {
    
    internal let item: LayoutConstraintItem
    internal var attributes: ConstraintAttributes
    internal var relation: ConstraintRelation? = nil
    internal var sourceLocation: (String, UInt)? = nil
    internal var label: String? = nil
    internal var related: ConstraintItem? = nil
    internal var multiplier: ConstraintMultiplierTarget = 1.0
    internal var constant: ConstraintConstantTarget = 0.0
    internal var priority: ConstraintPriorityTarget = 1000.0
    internal lazy var constraint: Constraint? = {
        guard let relation = self.relation, let related = self.related, let sourceLocation = self.sourceLocation else {
            return nil
        }
        let from = ConstraintItem(target: self.item, attributes: self.attributes)
        
        return Constraint(from: from, to: related, relation: relation, sourceLocation: sourceLocation, label: self.label, multiplier:self.multiplier, constant: self.constant, priority: self.priority
        )
    }()
    
    // MARK: Initialization
    
    internal init(item: LayoutConstraintItem, attributes: ConstraintAttributes) {
        self.item = item
        self.attributes = attributes
    }
    
}

好，刚才在ConstraintMaker中是不是有一个private var descriptions = [ConstraintDescription]()私有属性呢？是的，但是，我们使用它了，却未见将它初始化，没有初始化，意味着没有值。实际上它在ConstraintMaker中已经初始化了，我们来看里面的这个方法

 internal func makeExtendableWithAttributes(_ attributes: ConstraintAttributes) -> ConstraintMakerExtendable {
        let description = ConstraintDescription(item: self.item, attributes: attributes)
        self.descriptions.append(description)
        return ConstraintMakerExtendable(description)
}

首先是对ConstraintDescription约束描述类进行了初始化，然后得到实例对象description, 然后self.descriptions.append(description)。至于这个makeExtendableWithAttributes是干嘛的？别急，下面会讲到，这里只要知道ConstraintDescription约束描述类进行了初始化并且maker.descriptions有值了就好了。

从ConstraintDescription约束描述类的源码中可以看出，它有一个constraint属性，也就是Constraint约束类的一个实例对象，好了，这样就清楚了为何这里可以遍历，并且放进一个刚创建的var constraints: [Constraint] = []数组中。

分析一下ConstraintDescription约束描述类的初始化方法，即

 internal init(item: LayoutConstraintItem, attributes: ConstraintAttributes) {
        self.item = item
        self.attributes = attributes
 }

传入了参数item, 就是之前提到的当前view, 另外一个是布局属性，也就是常常使用的width、height、leading、right等等。

分析一下ConstraintDescription约束描述类的属性constraint, 即

internal lazy var constraint: Constraint? = {
    guard let relation = self.relation, let related = self.related, let sourceLocation = self.sourceLocation else {
        return nil
    }
    let from = ConstraintItem(target: self.item, attributes: self.attributes)
    
    return Constraint(from: from, to: related, relation: relation, sourceLocation: sourceLocation, label: self.label, multiplier:self.multiplier, constant: self.constant, priority: self.priority
    )
}()

这个是一个懒加载方法，并且是可选的，开始用guard语句判断了三个可选类型，分别是self.relation、self.related、self.sourceLocation。这里可能有人又有疑惑了，这三个属性并未看见其初始化，怎么又直接使用了呢？并且，他们是什么东西？有什么作用呢？好，其实这个又跟ConstraintMaker类中的方法makeExtendableWithAttributes返回值(实例对象）ConstraintMakerExtendable有关，暂且不说，只要知道这些属性只要我们调用make.width.equalTo的时候就已经被初始化就好，因为用户不一定会正确地传入值，所以，有可能有值，有可能没值，故用可选类型定义，并且判断三个条件必须符合之后，才能制作约束。解释一下三个属性的作用:

• self.relation

枚举类型，就是对系统的NSLayoutRelation的封装。即枚举值是

public enum NSLayoutRelation : Int {

    case lessThanOrEqual

    case equal

    case greaterThanOrEqual
}

• self.related

是一个ConstraintItem类实例对象，其实就是我们传入的所要布局的目标视图。

• self.sourceLocation

资源定位。是一个元组，（String，Int）类型，也就是出错的时候定位在（#file，#line）哪个文件，哪一行。

接着，在判断之后，创建了开始布局的视图from， 返回Constraint约束类的初始化后的实例对象。

到此为止，刚才牵扯到的疑问已经解决其中之一，还有两个疑问，实际上是和Constraint约束类相关。那么接下来，我们就来讲一下Constraint约束类。

Constraint约束类的布局浅析

这个类是非常重要的一个类，我把它当做SnapKit的核心类，因为布局就牵扯到约束，没有约束的布局一切都是虾扯蛋的。

我们先来回答刚才的一个疑问，就是在调用makeConstraints制作约束的时候，为何要调用

constraint.activateIfNeeded(updatingExisting: false)

为了快速回答这个问题，我们直接定位到Constraint约束类的方法

internal func activateIfNeeded(updatingExisting: Bool = false) {
    guard let item = self.from.layoutConstraintItem else {
        print("WARNING: SnapKit failed to get from item from constraint. Activate will be a no-op.")
        return
    }
    let layoutConstraints = self.layoutConstraints

    if updatingExisting {
        var existingLayoutConstraints: [LayoutConstraint] = []
        for constraint in item.constraints {
            existingLayoutConstraints += constraint.layoutConstraints
        }

        for layoutConstraint in layoutConstraints {
            let existingLayoutConstraint = existingLayoutConstraints.first { $0 == layoutConstraint }
            guard let updateLayoutConstraint = existingLayoutConstraint else {
                fatalError("Updated constraint could not find existing matching constraint to update: \(layoutConstraint)")
            }

            let updateLayoutAttribute = (updateLayoutConstraint.secondAttribute == .notAnAttribute) ? updateLayoutConstraint.firstAttribute : updateLayoutConstraint.secondAttribute
            updateLayoutConstraint.constant = self.constant.constraintConstantTargetValueFor(layoutAttribute: updateLayoutAttribute)
        }
    } else {
        NSLayoutConstraint.activate(layoutConstraints)
        item.add(constraints: [self])
    }
}

因为之前我们穿的是Bool值是false, 所以我们直接定位到else部分

NSLayoutConstraint.activate(layoutConstraints)
item.add(constraints: [self])

这样就很显而易见了，万变不离其宗， 调用系统API激活约束。那么又问又有疑惑了，激活约束后怎么还有item.add(constraints: [self])呢？这很奇怪呀！！！好，我来回答你的疑惑，这句代码目的是为了保存约束，方便你可以做移除约束的操作，如果你不信，你可以在源码中将这行代码删掉，你的约束也是正常的，并且视图也会正确显示！但是，当你调用snp.removeConstraints()方法的时候，不起任何作用！！！调用snp.remakeConstraints就会造成约束冲突，视图变形！

最后一个疑问，Constraint约束类的作用，这个我们直接来看初始化方法

    // MARK: Initialization

    internal init(from: ConstraintItem,
                  to: ConstraintItem,
                  relation: ConstraintRelation,
                  sourceLocation: (String, UInt),
                  label: String?,
                  multiplier: ConstraintMultiplierTarget,
                  constant: ConstraintConstantTarget,
                  priority: ConstraintPriorityTarget) {
        self.from = from
        self.to = to
        self.relation = relation
        self.sourceLocation = sourceLocation
        self.label = label
        self.multiplier = multiplier
        self.constant = constant
        self.priority = priority
        self.layoutConstraints = []

        // get attributes
        let layoutFromAttributes = self.from.attributes.layoutAttributes
        let layoutToAttributes = self.to.attributes.layoutAttributes

        // get layout from
        let layoutFrom = self.from.layoutConstraintItem!

        // get relation
        let layoutRelation = self.relation.layoutRelation

        for layoutFromAttribute in layoutFromAttributes {
            // get layout to attribute
            let layoutToAttribute: LayoutAttribute
            #if os(iOS) || os(tvOS)
                if layoutToAttributes.count > 0 {
                    if self.from.attributes == .edges && self.to.attributes == .margins {
                        switch layoutFromAttribute {
                        case .left:
                            layoutToAttribute = .leftMargin
                        case .right:
                            layoutToAttribute = .rightMargin
                        case .top:
                            layoutToAttribute = .topMargin
                        case .bottom:
                            layoutToAttribute = .bottomMargin
                        default:
                            fatalError()
                        }
                    } else if self.from.attributes == .margins && self.to.attributes == .edges {
                        switch layoutFromAttribute {
                        case .leftMargin:
                            layoutToAttribute = .left
                        case .rightMargin:
                            layoutToAttribute = .right
                        case .topMargin:
                            layoutToAttribute = .top
                        case .bottomMargin:
                            layoutToAttribute = .bottom
                        default:
                            fatalError()
                        }
                    } else if self.from.attributes == self.to.attributes {
                        layoutToAttribute = layoutFromAttribute
                    } else {
                        layoutToAttribute = layoutToAttributes[0]
                    }
                } else {
                    if self.to.target == nil && (layoutFromAttribute == .centerX || layoutFromAttribute == .centerY) {
                        layoutToAttribute = layoutFromAttribute == .centerX ? .left : .top
                    } else {
                        layoutToAttribute = layoutFromAttribute
                    }
                }
            #else
                if self.from.attributes == self.to.attributes {
                    layoutToAttribute = layoutFromAttribute
                } else if layoutToAttributes.count > 0 {
                    layoutToAttribute = layoutToAttributes[0]
                } else {
                    layoutToAttribute = layoutFromAttribute
                }
            #endif

            // get layout constant
            let layoutConstant: CGFloat = self.constant.constraintConstantTargetValueFor(layoutAttribute: layoutToAttribute)

            // get layout to
            var layoutTo: AnyObject? = self.to.target

            // use superview if possible
            if layoutTo == nil && layoutToAttribute != .width && layoutToAttribute != .height {
                layoutTo = layoutFrom.superview
            }

            // create layout constraint
            let layoutConstraint = LayoutConstraint(
                item: layoutFrom,
                attribute: layoutFromAttribute,
                relatedBy: layoutRelation,
                toItem: layoutTo,
                attribute: layoutToAttribute,
                multiplier: self.multiplier.constraintMultiplierTargetValue,
                constant: layoutConstant
            )

            // set label
            layoutConstraint.label = self.label

            // set priority
            layoutConstraint.priority = LayoutPriority(rawValue: self.priority.constraintPriorityTargetValue)

            // set constraint
            layoutConstraint.constraint = self

            // append
            self.layoutConstraints.append(layoutConstraint)
        }
    }

其实这个也没多少需要详细讲得，无非就是先初始化属性，然后判断所要布局的视图和对应的布局视图的位置关系，这里举一个与父视图的关系，比方说，现在我刚创建一个Xcode工程，并且创建了一个子视图，我们想要让所要布局的子视图的edges等于父视图的margins, 那么我们可以这样写：

subview = UIView()
subview.backgroundColor = .purple
view.addSubview(subview)
subview.snp.makeConstraints { (make) in
    make.edges.equalTo(view.snp.margins)
}

这非常简单，然后约束调用的是这个判断

if self.from.attributes == .edges && self.to.attributes == .margins {
    switch layoutFromAttribute {
    case .left:
        layoutToAttribute = .leftMargin
    case .right:
        layoutToAttribute = .rightMargin
    case .top:
        layoutToAttribute = .topMargin
    case .bottom:
        layoutToAttribute = .bottomMargin
    default:
        fatalError()
    }
} 

为什么呢？原因是self.from.attributes == .edges && self.to.attributes == .margins条件满足，即布局视图的attributes就是edges, 等于父视图的margins， 从这句代码make.edges.equalTo(view.snp.margins)可以很好地看出来。不清楚的话，可以将代码“照葫芦画瓢”试试。一定会调用的。

最后就添加布局约束self.layoutConstraints.append(layoutConstraint)就搞定了。

一切基本讲得差不多了，但是，我们还有一个东西要讲，那就是关系属性make.top.right.left.trailing.leading.width.edges等等， 往下看

ConstraintMakerExtendable类的布局浅析

要讲这个的目的是，在SnapKit中，所有布局我们都要使用make.width、make.right等的形式，而后面的这些宽、高、左边、右边、前边、后边、边缘等都是ConstraintMakerExtendable类的实例对象。

ConstraintMakerExtendable类继承于ConstraintMakerRelatable类，在ConstraintMakerExtendable类中，都是这种形式

public class ConstraintMakerExtendable: ConstraintMakerRelatable {
    
    public var left: ConstraintMakerExtendable {
        self.description.attributes += .left
        return self
    }
    
    public var top: ConstraintMakerExtendable {
        self.description.attributes += .top
        return self
    }
 
  .............................................................................
  .............................................................................
  .............................................................................   
}

这里就是创建了一个自身的实例对象，返回自身的一个实例。关键点在于self.description.attributes += .top, description是ConstraintMakerRelatable的一个属性，因为继承的关系，所以这里有self.description, attributtes又是ConstraintDescription的属性，至于符号+=是作者对系统集合API的一个封装，见下面

internal func +=(left: inout ConstraintAttributes, right: ConstraintAttributes) {
    left.formUnion(right)
}

也即是将相应的布局约束属性放到self.description.attributes中, 因为在我们制作约束的时候需要用到Constraint类（上面已经讲过了），添加约束、激活约束、甚至移除约束都离不开改属性的存在 或者说离不开 结构体ConstraintAttributes的存在。

好，现在该穿越了，回到我们的最初的ConstraintMaker类中：

public var left: ConstraintMakerExtendable {
    return self.makeExtendableWithAttributes(.left)
}

public var top: ConstraintMakerExtendable {
    return self.makeExtendableWithAttributes(.top)
}

.......................................................等等

可以看到，我们经常使用的形式make.left.equalTo（还有很多）中的left就是一个ConstraintMakerExtendable的实例对象， 返回的是调用方法makeExtendableWithAttributes的结果，这个方法文章中已经写过，不再重复，不懂或忘记的回过头看看。如此，布局就“万事俱备只欠东风”了，最后一步就是equalTo，这也是必不可少的那么equalTo究竟又是什么呢？

接着往下看你就知道了.............................

ConstraintMakerEditable类的布局浅析

在这里，equalTo()是ConstraintMakerRelatable类的实例方法返回的ConstraintMakerEditable类的实例，在文章开头的文件结构中我们已经知道，ConstraintMakerEditable继承于ConstraintMakerPriortizable , 而ConstraintMakerPriortizable 继承于ConstraintMakerFinalizable。 之前说过width、height、right等等其实就是ConstraintMakerExtendable类的实例，所以有make.width.equalTo()的形式，而ConstraintMakerExtendable类又继承于ConstraintMakerRelatable类。这样的话，我们来看一下ConstraintMakerRelatable类的equalTo()方法：

internal func relatedTo(_ other: ConstraintRelatableTarget, relation: ConstraintRelation, file: String, line: UInt) -> ConstraintMakerEditable {
    let related: ConstraintItem
    let constant: ConstraintConstantTarget
    
    if let other = other as? ConstraintItem {
        guard other.attributes == ConstraintAttributes.none ||
              other.attributes.layoutAttributes.count <= 1 ||
              other.attributes.layoutAttributes == self.description.attributes.layoutAttributes ||
              other.attributes == .edges && self.description.attributes == .margins ||
              other.attributes == .margins && self.description.attributes == .edges else {
            fatalError("Cannot constraint to multiple non identical attributes. (\(file), \(line))");
        }

        related = other
        constant = 0.0
    } else if let other = other as? ConstraintView {
        related = ConstraintItem(target: other, attributes: ConstraintAttributes.none)
        constant = 0.0
    } else if let other = other as? ConstraintConstantTarget {
        related = ConstraintItem(target: nil, attributes: ConstraintAttributes.none)
        constant = other
    } else if #available(iOS 9.0, OSX 10.11, *), let other = other as? ConstraintLayoutGuide {
        related = ConstraintItem(target: other, attributes: ConstraintAttributes.none)
        constant = 0.0
    } else {
        fatalError("Invalid constraint. (\(file), \(line))")
    }
    
    let editable = ConstraintMakerEditable(self.description)
    editable.description.sourceLocation = (file, line)
    editable.description.relation = relation
    editable.description.related = related
    editable.description.constant = constant
    return editable
}

@discardableResult
public func equalTo(_ other: ConstraintRelatableTarget, _ file: String = #file, _ line: UInt = #line) -> ConstraintMakerEditable {
    return self.relatedTo(other, relation: .equal, file: file, line: line)
}

其中，other就是我们传入的目标值或对象，它是一个ConstraintRelatableTarget协议，比如我传入一个常量100, 约束就是:

make.width.equalTo(100)

我们来看一下ConstraintRelatableTarget协议里有什么：

public protocol ConstraintRelatableTarget {
}

extension Int: ConstraintRelatableTarget {
}

extension UInt: ConstraintRelatableTarget {
}

extension Float: ConstraintRelatableTarget {
}

extension Double: ConstraintRelatableTarget {
}

extension CGFloat: ConstraintRelatableTarget {
}

extension CGSize: ConstraintRelatableTarget {
}

extension CGPoint: ConstraintRelatableTarget {
}

extension ConstraintInsets: ConstraintRelatableTarget {
}

extension ConstraintItem: ConstraintRelatableTarget {
}

extension ConstraintView: ConstraintRelatableTarget {
}

@available(iOS 9.0, OSX 10.11, *)
extension ConstraintLayoutGuide: ConstraintRelatableTarget {
}

这样就非常明确了，为什么equalTo()里面既可以是某个特定的值，也可以是一个对象，因为你可以传入Int、Double等类型的值，也可以传一个ConstraintView类型的实例对象，这样，所有的基本工作几乎都做好了。那么，你就可以通过目标视图对象、位移、位置关系等来确定两个视图的位置关系，从而制作符合需求的相应的约束。

SnapKit的应用建议

尽量采用简洁的写法，不要画蛇添足，尽管SnapKit布局很是灵活，但是你也不能随心所欲，毕竟，团队写的代码还是需要有一个统一标准的，至少，你写的布局，要让别人能够清晰可见。

下面简洁的布局写法

• 宽和高相等，并且等于某个具体得值，比如100

建议：

make.size.equalTo(100)

不建议写成：

make.width.height.equalTo(100)

不建议写成

make.width.equalTo(100)
make.height.equalTo(100)

• 宽和高不相等，并且等于某个具体值， 比如宽=100，高=200

建议写成

make.size.equalTo(CGSize(width: 100, height: 200))

不建议写成：

make.width.equalTo(100)
make.height.equalTo(200)

• 约束关系与某个视图相等

建议写成

make.left.equalTo(view2)
make.right.equalTo(view2)
make.top.equalTo(view2)
...............................................

如果同时有几个约束关系相等，建议用链式语法，增强可读性，比如

make.left.right.top.bottom.width.height.size.equalTo(view2)

不建议写成

make.left.equalTo(view.snp.left)
make.right.equalTo(view.snp.right)
make.top.equalTo(view.snp.top)

• 如果等于父视图，直接使用equalToSuperview()

比如，view2是父视图，所要布局视图的顶部等于父视图的顶部

建议这样写

make.top.equalToSuperview()

不建议这样写：

make.top.equalTo(view2)
make.top.equalTo(view2.snp.top)

• 距离父视图某个边缘多少距离 （同一性质）

前提：所布局视图的关系和父视图的关系是同一性质的，什么叫同一性质，比如top等于父视图的top，left等于父视图的left等等

假设view2为父视图， 距离父视图顶部100dp的距离

注：left、right、bottom等同下。

建议写成

make.top.equalTo(100)

不建议写成：

make.top.equalToSuperview().offset(100)
make.top.equalTo(view2).offset(100)

• 距离父视图某个边缘多少距离 （不同性质）

如： left 距离父视图的right为 200

make.left.equalTo(view2.snp.right).offset(200)

SnapKit源码浅析总结

该库的源码逻辑清晰，封装得很好，善于将class、struct、protoco结合起来使用，文件结构也很清晰，尽管分为这么多的文件，但是每个文件相互独立有相互依赖，都实现特定的功能，层级简单，如作者用四五个文件单独为特定的class、protocol、enum定义别名。

另外就是代码十分简洁，每个文件你仔细去看，34个文件只有一个文件超过200行代码。

但是，个人觉得文件太多，对类、协议等的分离太多，对于新手来说，有时候很难弄清楚功能的实现，因为你研究一个功能，就会牵扯到很多很多文件，很多类，很多协议，可能一时会有点懵逼。但是好的地方就是，你研究清楚结构后，弄清楚每个文件的作用后，就会发现比较简单，这也是为何这么多文件，这么多类和协议，但是最终我们布局的时候，几行代码就搞定了布局。

就好比你寒窗苦读，努力工作， 成为了一个很有才华的人，你的一言一行别人都觉得是名言，时刻用来提醒自己。

但是，谁又知道，你惊人的才华的外表背后，都是你对多年的血与泪的努力的一个封装。

欢迎加入 iOS(swift)开发互助群：QQ群号: 558179558， 相互讨论和学习！