iOS-UI佈局 Xib，Masonry，Frame之間的比較選取

若是你要讓兩個iOS開發吵起來，只須要說一句：Frame佈局比Masonry好!

iOS常見的佈局方式有三種：Xib, Masonry,Frame,相信對於iOS開發者來講,這三種佈局並不陌生，而且時常會看到Frame與Masonry誰更好的爭論，其實並無誰比誰好這一說，只有誰比誰更合適當前項目，靈活運用纔是王道

• Xib: 基於Autolayout，簡單，上手快，可視化視圖大大提高了開發效率，缺點是靜態佈局不夠靈活，修改麻煩，性能相對其餘會稍低一點，適合須要快速開發，頁面較爲固定的項目
• Masonry: 基於Autolayout,佈局上比Xib靈活，適配方便快速，缺點是約束有錯誤不直觀，且容易代碼冗餘,性能次於Frame，適合須要快速迭代，產品經理腦洞賊大常常修改的UI的項目
• Frame: 純手工計算，適用於複雜、多變的頁面，性能最好，佈局最靈活，作動畫相對比Masonry方便；缺點是須要大量的計算，容易形成閱讀困難，接手難度大

這裏通常會有三個疑問

一. 爲何說Frame的性能比Masonry的好，Xib的次之？

Masonry和Xib都是基於Autolayout相對佈局，全部的相對佈局最終都會轉換成Frame絕對佈局；AutoLayout是線性方程組求解，當計算過多時，會佔據較大系統內存，甚至影響GPU繪製形成卡頓，這也是不少人儘可能壓縮視圖層級，減小計算量的緣由；Frame則乾脆得多,基於XY座標軸系統的佈局。從數學上限定了UI控件的具體位置，是iOS開發中最底層、最基本的界面佈局機制。
就像是去電影院找位置，直接說第幾排第幾座確定比「距離最右邊第三個距上邊第十個位置」這種說法來的省力一些；至於Xib原理和Autolayout同樣，但多耗費了些性能在圖形轉化上

二. 上面三種對各類尺寸屏的適配和使用上如何？

這點綜合起來Masonry佔優，純代碼設計，在頁面佈局的操控上會更爲方便，控件間的關係也一目瞭然。但這裏須要提一下一些沒接觸過Xib和Frame上的一些錯誤理解

在Xib設置的高度是死的，且不能根據屏幕大小適配？

Xib能夠能夠將高度約束NSLayoutConstraint引出，設置NSLayoutConstraint的constant便可隨意修改高度，並且能夠經過添加分類

- (void)setAdapterScreen:(BOOL)adapterScreen{
    adapterScreen = adapterScreen;
    if (adapterScreen) {
        //這裏也能夠改爲以其餘屏幕爲基準
        self.constant = self.constant * ([UIScreen mainScreen].bounds.size.width / 375.0);
    }
}
- (BOOL)adapterScreen{
    return YES;
}
複製代碼

後面在須要適配的NSLayoutConstraint上Adapter Screen修改成On便可，修改後的NSLayoutConstraint都會跑這個方法適配。這兩個配合基本能夠知足大部分頁面的適配需求。

Frame是停留在4s年代的遠古佈局，各類值也是死的，不能根據屏幕大小適配？

Frame不是停留在4S年代的佈局，而是怎麼都不會變更的的基礎，全部佈局最終轉換的目的，誠然使用Autolayout能幫咱們減小大量的計算，但這些是基於損耗性能的狀況下進行的，若是對性能有較高的追求的話，通常都建議用Frame佈局。 沒接觸過的不少人不理解Frame的狀況下，會本能的認爲Frame就是寫死幾個值，後續根據各類屏幕判斷值，劉海屏什麼的都要單獨適配，這個認知是錯誤的，通常在熟悉Frame佈局的人都會設置好宏定義

// 屏幕寬
#define kScreenW ([UIScreen mainScreen].bounds.size.width)
// 屏幕高
#define kScreenH ([UIScreen mainScreen].bounds.size.height)
// 適配iPhone X 狀態欄高度
#define kScreenStatusBarHeight (iPhoneX ? 44.f : 20.f)
// 適配iPhone X 導航欄高度
#define kScreenNavHeight (iPhoneX ? 88.f : 64.f)
// 狀態欄
#define kNavH (iPhoneX ? 88.f : 64.f) 
// iPhone X
#define iPhoneX (([[UIScreen mainScreen] bounds].size.height - 812) ? NO : YES)

複製代碼

使用時

_tableView = [[UITableView alloc]initWithFrame:CGRectMake(0, 0, kScreenW, self.view.height - kNavH) style:UITableViewStyleGrouped];
複製代碼

這樣就很方便的根據各類狀況進行適配，自己代碼量並不會增長多少，而性能卻提高很多。

三. 這些佈局應該如何選取

在我看來，這三種佈局的優缺點都很是的明顯，根據項目自己需求選取對應的方式便可。上面提到很是屢次的性能問題，但隨着手機性能的不斷提升，一些性能損耗的對App的影響愈來愈小

• 在項目較小，頁面變更不大，須要快速開發的狀況下，Xib也是一個很好的選擇，蘋果自己推出Xib的緣由就是爲了讓程序員把更多的精力放在業務邏輯上；
• 在項目迭代頻率較高，產品腦洞奇大，常常須要修改UI的狀況下，建議用Masonry；
• 在頁面較爲複雜，或追求操做順滑，或頁面有動畫的狀況下Frame纔是最佳；

這裏並沒有意討論三者間的優劣，技術的選取自己就是要看項目需求，只是我看到網上太多開發者固守Masonry/frame/xib而一昧的貶低其餘，做爲一個開發人員應該更多的走出本身的溫馨區，嘗試各類開發方案