前面寫了一篇文章，介紹FlexLib這個(gè)布局庫，見IOS新一代界面開發(fā)利器 —— FlexLib。然后有很多網(wǎng)友問相比于Masonry有什么優(yōu)勢，今天就簡單對比一下兩者優(yōu)劣。

Masonry是一個(gè)非常優(yōu)秀的開源庫，可以說是Masonry的出現(xiàn)拯救了Autolayout，其簡潔的語法贏得了大量美譽(yù)。但是隨著眾多基于Flexbox布局庫的出現(xiàn)(如React Native、Weex、Texture)，autolayout本身越來越顯得難以適應(yīng)時(shí)代的需要。下面從幾個(gè)方面簡單分析一下：

Autolayout性能問題

Frame / Auto Layout / FlexBox 的性能對比如下：

詳細(xì)的Autolayout評測見這篇文章：從 Auto Layout 的布局算法談性能

總體而言，當(dāng)頁面中的窗口數(shù)量達(dá)到30個(gè)以上的時(shí)候，布局所需要的時(shí)間即可達(dá)到16ms，也就是當(dāng)視圖比較多的時(shí)候，autolayout會(huì)有嚴(yán)重的性能問題。而使用flexbox模型，其布局性能非常接近于使用frame方式布局。

Masonry僅支持布局屬性的設(shè)置

對于一個(gè)頁面而言，除了需要設(shè)置控件的布局屬性，還需要設(shè)置控件的視圖屬性，包括背景色、字號(hào)、文字等。而這些都用代碼來設(shè)置將直接導(dǎo)致代碼冗長，可讀性差，不容易修改等。

使用Masonry寫的代碼

[self .textViewmas_makeConstraints:^(MASConstraintMaker *make) { make .top.mas_equalTo(self) .mas_offset( 7) ;make .bottom.mas_equalTo(self) .mas_offset(- 7) ;make .left.mas_equalTo(self .voiceButton.mas_right) .mas_offset( 4) ;make .right.mas_equalTo(self .emojiButton.mas_left) .mas_offset(- 4) ;make .height.mas_equalTo(HEIGHT_CHATBAR_TEXTVIEW) ;}] ;self .textView.font= [UIFont systemFontOfSize: 16] ;self .textView.color= [UIColor colorWithRed: 0green: 0blue: 0alpha: 0.6] ;self .textView.text= @ "測試文本";

FlexLib通過xml配置文件

<UITextViewname="_textView"layout="top:7,bottom:7,left:4,right:4"attr="fontSize:14,color:#333333,text:測試文本"/>

可以看出，通過xml配置起來優(yōu)勢相當(dāng)明顯

每次界面的改動(dòng)都需要重新編譯運(yùn)行

因?yàn)檎麄€(gè)布局都使用代碼來編寫，只要設(shè)計(jì)有一點(diǎn)點(diǎn)改動(dòng)，都需要修改代碼、編譯、重新運(yùn)行，這對于小項(xiàng)目還可以接受，而對稍大一些的項(xiàng)目所花費(fèi)的時(shí)間則難以想象。

使用xml配置則可以運(yùn)行時(shí)修改xml布局，然后即時(shí)刷新界面，如圖：

適配iPhone X的代價(jià)

iPhoneX一出，讓使用autolayout以及masonry的每個(gè)界面都需要進(jìn)行適配，其工作量相當(dāng)之大。

對比之下，使用FlexLib則無需額外對iPhoneX進(jìn)行適配，另外如果框架提供的safeArea不能滿足需求，也可以非常方便的通過重載進(jìn)行適配。

使用FlexLib適配iPhoneX的效果圖

除了以上幾點(diǎn)以外，F(xiàn)lexLib還有其他特性，包括輸入框自動(dòng)躲避鍵盤、支持預(yù)定義風(fēng)格、國際化支持、tablecell高度自動(dòng)計(jì)算等。

因此，您是否還打算繼續(xù)使用Masonry呢？