上圖轉自戴銘老師的iOS開發高手課, 看到這個圖的時候, 感覺自己真的需要總結一下, 做了幾年的iOS開發, 有時候感覺腦容量有限, 有進入的東西, 就會有要忘記的東西. 剛工作的時候選擇生活工作做加法, 整個世界是新鮮的, 去學習不同的東西, 去嘗試不同的工作, 去接觸不同的人, 去自己沒有去過的地方. 現在, 生活和工作只想做減法, 減去沒有必要的社交, 沒有必要的溝通, 學習更有針對性的東西, 這樣纔有時間提升自己.
開發經常是處於做不同需求的階段, 也就是上面的開發階段, 在前一段需求中做了一個關於圖片管理器的需求.
關於這個組件,顧名思義, 實現圖片的管理, 上傳, 編輯, 查看. 寫頁面的時候就會涉及到它的整體設計, 頁面整體採用MVC的模式, 整個組件在外部調用的時候, 展示的UI可能會略有不同, 組件採用數據驅動UI的形式, 在Model中有對不同的頁面的UI根據頁面的展示類型進行了不同的數據綁定, 頁面整體設計的很合理,但是單獨作爲一個組件的話, 裏面耦合了業務的接口請求部分, 這樣它就不能對別的app進行通用. 在寫頁面佈局的時候總會考慮到是用frame還是用Auto Layout來寫, 在我上一份工作中,用的frame比較多. 現在的公司有人用frame但是大部分是用的Auto Layout, 主要用三方的框架Masonry.
1> Auto Layout的來歷
時間點:
.1997年, Auto Layout用到的佈局算法Cassowary被髮明瞭出來;
. 2011年, 蘋果公司將Cassowary算法運用到了自家的佈局引擎Auto Layout中
Cassowary能夠有效解析線性等式系統和線性不等式系統, 用來表示用戶界面中那些相等關係和不等關係. 基於此, Cassowary開發了一種規則系統, 通過約束來描述視圖間的關係. 約束就是規則, 這個規則能夠表示出一個視圖相對於另一個視圖的位置.
由於Cassowary算法讓視圖位置可以按照一種簡單的佈局思路來寫, 這些簡單的相對位置描述可以在運行時動態地計算出視圖具體的位置. 視圖位置的寫法簡化了, 界面相關代碼也就更易於維護. 蘋果公司也是看重了這一點, 將其引入到了自己的系統中
2> Auto Layout原理
.有時候使用Masonry的時候, 有一兩個約束不對, 就閃退了, 在剛開始的時候, 對約束不熟悉, 會經常出現這個問題, 一般我會通過查看錯誤約束原因和註釋代碼的方式來找到錯誤的約束. Auto Layout佈局過程涉及延遲機制, 並非一有約束更新就馬上進行佈局重繪, 當有約束更改時, 系統的默認做法是延遲更新, 目的是實現批量更改約束, 繪製視圖, 避免頻繁遍歷視圖層級, 優化性能. 當更新約束太慢影響到後序代碼的邏輯時, 也可以強制馬上更新
Auto Layout佈局流程
Auto Layout 不只有佈局Cassowary, 還包含了佈局在運行時的聲明週期等一整套佈局引擎系統, 用來統一管理佈局的創建, 更新和銷燬. 這一套佈局引擎系統叫走Layout Engine, 是Auto Layout的核心, 主導着整個界面佈局
a.在App啓動後開啓RunLoop, 循環檢測圖層樹中是否存在約束變化;
b.當發生Constrints Change時, RunLoop檢測到約束變化;
c. Layout Engine在碰到約束變化後會重新佈局, 獲取到佈局後調用superview.setNeedLayout(), 然後進入到Deferred Layout Pass. 接下來, Layout Engine 會從上到下調用layoutSubviews(), 通過Cassowary算法計算各個子視圖的位置, 算出來後姜自視圖的frame從Layout Engine 裏拷貝出來.
Deferred Layout Pass的主要作用是做容錯處理. 如果有些視圖在更新約束時沒有確定或者是確實佈局聲明的話, 會現在這裏做容錯處理.
d. 執行完一輪佈局，RunLoop會繼續檢查視圖樹的約束更新情況，當再次發現約束更新，則執行新一輪佈局……
個人總結, Auto Layout 個人認爲在頁面不需要持續性更改UI的時候用起來比較方便, 在UI進行不停的複雜計算, 用frame會更簡單一點, 比較複雜的UI計算的時候, 用Auto Layout代碼就不會變的那麼簡潔了.