先拋出結論：
setNeedsUpdateConstraints 保證之后肯定會調用 updateConstraintsIfNeeded .
SetNeedsLayout 保證之后肯定會調用 layoutIfNeeded .
AutoLayout 的本質
AutoLayout 是指，用一套規則（約束）來定義視圖之間的位置。
AutoLayout 能夠讓每個 view 有唯一的 frame。
其實，這樣子解釋，還是讓人很難理解，所以接下來會簡單介紹下 AutoLayout ，在對其有所了解和深入后，再解釋下面這幾個問題：
-
保證之后調用的之后是在什么時候？ - 這些方法的調用時序大概是怎么樣的？
- 為什么要先 set 一下，而不是直接 updateConstraint 和 layout
UIView 生命周期
init=>start: InitWithFrame
layout=>operation: setNeedsDisplay:
setNeedsUpdateConstraint:
setNeedsDisplay:
ifUpdateCons=>condition: update constraints ?
updateCons=>operation: updateConstraints
ifLayout=>condition: update layout ?
layoutSubview=>operation: layoutSubviews
ifDisplay=>condition: needs display ?
draw=>operation: Draw in Rect
e=>end: Event Loop
init->layout->ifUpdateCons
ifUpdateCons(yes)->updateCons->ifLayout
ifUpdateCons(no)->ifLayout
ifLayout(yes)->layoutSubview->ifDisplay
ifLayout(no)->ifDisplay
ifDisplay(yes)->draw(right)->e(right)
ifDisplay(no)->e(right)
e->ifUpdateCons
在 iOS 中，AutoLayout Engine 是一個迭代機。
為什么這樣說呢？先回到手寫布局時代，我們通過計算 view 與屏幕之間的相對距離，得出 view 實際的 frame，然后賦值給 view，這樣子每個 view 都會按照我們設置的位置正確地顯示。
接著我們來到當下的 iOS 開發，先列出幾個問題：
- 需要適配多種屏幕
- 既可以在 iPhone 上使用，又可以在 iPad 上使用
- 可以在橫屏下使用
- 在不同的屏幕尺寸下，有不同的布局方式（比如屏幕小，就一行放一個，屏幕大一行放兩個）
如果仍然在原始的手寫布局下去完成上述工作，勢必累死，也不一定能夠很好的完成。
搞個機器人
人類能夠發展到現在的文明，就是因為 善假于物也。
我希望現在有一套東西，我只需要告訴它，我希望視圖表現成什么樣子，然后它就會按照我的期望去計算出每個 view 的 frame，我只需要把 frame 拿來用就行了。
AutoLayout 就是這樣的一套東西，它接收視圖與視圖之間的規則，生成最終的 frame。
這里有個誤區，AutoLayout 的確是最終生成了 frame，不過生成之后自動給 view 賦值上去了，所以我們沒有看到 setFrame 這個過程。
這個規則就是約束 constraint。
為什么需要 update constraint
在 UIView 顯示之前，先判斷 view 是否能根據當前約束計算出唯一的 Frame。如果可以，那么就根據這個 Frame 去布局。同時，在這里我們認為 view 是滿足約束的。
嚴謹一些，是指在 AutoLayout Engine 中，該 view 的 constraint 是否為最新。
AutoLayout Engine 是一個單獨的約束處理系統，在絕大多數操作中，比如：
- Activating或Deactivating 啟用和停用
- 設置constant或priority
- 添加和刪除視圖
AutoLayout Engine 本身都會標記 view 的約束不是最新，即調用 setNeedsUpdateConstraint 。
但是也有例外，AutoLayout Engine 并不知道你又修改了約束。因此在這種 case 下，需要手動調用 setNeedsUpdateConstraint 來標記約束需要更新。
setNeedsUpdateConstraint
setNeedsUpdateConstraint 控制 view 的約束是否需要更新。當一個自定義view的某個屬性發生改變，并且可能影響到constraint時，需要調用此方法去標記constraints需要在未來的某個點更新，系統然后會調用 updateConstraints，. 以解決這個由屬性改變帶來的影響。
updateConstraintsIfNeeded
updateConstraintsIfNeeded立即觸發約束更新，自動更新布局。
updateConstraints
當 Custom View 發現屬性或者其他的改變導致它的所有約束中有一個失效時，首先應該刪除這個失效的約束，然后調用 setNeedsUpdateConstraints 表示當前的約束需要更新，然后在 updateConstraints 中恰當地地方檢查當前 content 所需的必要約束。
注意：要在實現在最后調用[super updateConstraints]
layoutSubviews
在確定了 view 的約束后，AutoLayout 通過計算可以得出 view 的 frame，計算的過程就是 layout 的過程。
Layout 的順序，是由最外層向里遞進，所以子視圖只需要相對于父視圖做好布局就可以。
在調用 layoutSubviews 的同時，也會調用 setNeedsUpdateConstraint。
Auto Layout Process 自動布局過程（引用自Objccn.io）
與使用springs and struts(autoresizingMask)比較，Auto layout在view顯示之前，多引入了兩個步驟：updating constraints 和laying out views。
每一個步驟都依賴于上一個。display依賴layout，而layout依賴updating constraints。顯示之前首先得知道布局，想要完整的布局就得更新約束（約束才能得出布局啊）。
updating constraints->layout->display
第一步：updating constraints，被稱為測量階段，其從下向上(from subview to super view),為下一步layout準備信息。
可以通過調用方法setNeedUpdateConstraints去觸發此步。constraints的改變也會自動的觸發此步。但是，當你自定義view的時候，如果一些改變可能會影響到布局的時候，通常需要自己去通知Auto layout，updateConstraintsIfNeeded。
自定義view的話，通常可以重寫updateConstraints方法，在其中可以添加view需要的局部的contraints。
第二步：layout，其從上向下(from super view to subview)，此步主要應用上一步的信息去設置view的center和bounds。可以通過調用setNeedsLayout去觸發此步驟，此方法不會立即應用layout。如果想要系統立即的更新layout，可以調用layoutIfNeeded。另外，自定義view可以重寫方法layoutSubViews來在layout的工程中得到更多的定制化效果。
第三步：display，此步時把 view 渲染到屏幕上，它與你是否使用Auto layout無關，其操作是從上向下(from super view to subview)，通過調用setNeedsDisplay觸發，
因為每一步都依賴前一步，因此一個display可能會觸發layout，當有任何layout沒有被處理的時候，同理，layout可能會觸發updating constraints，當constraint system更新改變的時候。
需要注意的是，這三步不是單向的，constraint-based layout是一個迭代的過程，layout過程中，可能去改變constraints，有一次觸發updating constraints，進行一輪layout過程。
注意：如果你每一次調用自定義layoutSubviews都會導致另一個布局傳遞，那么你將會陷入一個無限循環中。
就是說，layout 和 updateConstraints 不斷迭代最終確立了整個布局和顯示，然后交給屏幕去顯示
實踐出真知
layoutIfNeeded 調用導致 Crash
在調用 layoutIfNeeded 時，view 必須要被 setNeedsLayout 后，才會理解執行 layoutSubviews。
一個視圖缺少高寬約束，在設置完了約束后執行layoutIfNeeded，然后設置寬高，這種情況在低配機器上可能會出現崩問題。原因在于layoutIfNeeded需要有標記才會立刻調用layoutSubview得到寬高，不然是不會馬上調用的。頁面第一次顯示是會自動標記上需要刷新這個標記的，所以第一次看顯示都是看不出問題的，但頁面再次調用layoutIfNeeded時是不會立刻執行layoutSubview的（但之前加上setNeedsLayout就會立刻執行），這時改變的寬高值會在上文生命周期中提到的Auto Layout Cycle中的Engine里的Deferred Layout Pass里執行layoutSubview，手動設置的layoutIfNeeded也會執行一遍layoutSubview，但是這個如果發生在Deferred Layout Pass之后就會出現崩的問題，因為當視圖設置為setTranslatesAutoresizingMaskIntoConstraints:NO時會嚴格按照約束->Engine->顯示這種流程，如在Deferred Layout Pass之前設置好是沒有問題的，之后強制執行LayoutSubview會產生一個權重和先前一樣的約束在類似動畫block里更新布局讓Engine執行導致Ambiguous Layouts這種權重相同沖突崩潰的情況發生。
RemoveFromSuperView
將多個有相互約束關系視圖removeFromSuperView后更新布局在低配機器上出現崩的問題。這個原因主要是根據不含視圖項的約束不合法這個原則來的，同時會拋出野指針的錯誤。在內存吃緊機器上，當應用占內存較多系統會抓住任何可以釋放heap區內存的機會視圖被移除后會立刻被清空，這時約束如果還沒有被釋就滿足不含視圖項的約束會崩的情況了。
remove 之前最好能夠 clearConstraint。
我的一些疑問
第一步：updating constraints，被稱為測量階段，其從下向上(from subview to super view),為下一步layout準備信息。
始終不明白為什么要從下往上更新約束，我的理解是，先是父視圖確定自己位置，子視圖才確認自己視圖。當然這個是 layout 的過程。
我當前的理解是這樣，子視圖的約束先更新，再逐步向上觸發父視圖更新約束，猜測的原因是子視圖的約束可能會導致父視圖約束更改。
