iOS開(kāi)發(fā)中，在界面布局時(shí)候會(huì)遇到一些莫名其妙的bug，各個(gè)地方都沒(méi)有違反正常規(guī)則，不管斷點(diǎn)跟蹤還是打印，還是通過(guò)debug view hierarchy，跟蹤下來(lái)，并沒(méi)有發(fā)現(xiàn)異常，但最終輸出結(jié)果就是出現(xiàn)問(wèn)題。這個(gè)時(shí)候，除了其他調(diào)試方法之后，最好還是需要考慮2個(gè)方面的因素。

1.布局約束沖突 （主要講 Masonry）

Masonry約束，如果同樣的約束寫(xiě)了2次，比如說(shuō)寬度設(shè)置了2次，每次設(shè)置的值不同，這時(shí)候就沖突了。而不是像設(shè)置frame那樣，最后設(shè)置的值是有效值。這種約束沖突，xcode是不會(huì)給你報(bào)錯(cuò)的。小編曾經(jīng)在這個(gè)地方掉過(guò)坑，整了半天才搞明白。（主要是小編道行實(shí)在太淺，沒(méi)有仔細(xì)研究并看debug view hierarchy里面的提示，實(shí)在活該卡了很久。）

2.命名不規(guī)范

frame方式進(jìn)行布局的時(shí)候，有時(shí)候會(huì)保存frame的值，進(jìn)行一些界面調(diào)整。假如成員變量命名為frame，這個(gè)時(shí)候項(xiàng)目中使用self.frame時(shí)候，UI界面混亂，不是你想要的。你檢查他的布局的時(shí)候，不管斷點(diǎn)跟蹤還是打印還是debug view hierarchy里面看值，都正常，但是現(xiàn)實(shí)中他顯示的位置就是不對(duì)。這個(gè)時(shí)候，你會(huì)懷疑是不是大蘋(píng)果自己的bug？但是這個(gè)不可能吧。如果你能懷疑到是不是蘋(píng)果的bug的時(shí)候，就該想到自己是不是違規(guī)操作了，比如命名問(wèn)題。不管是其他變量還是一些方法名命名等等，最好不要與C，OC 這些系統(tǒng)關(guān)鍵字以及方法同名，這樣，你會(huì)遇到預(yù)想不到的bug。

具體舉幾個(gè)例子，變量開(kāi)頭不要已關(guān)鍵字開(kāi)頭，比如new ?id frame 等等。

@property (nonatomic, assign) CGRect frame; ? 這樣寫(xiě)，你就掉坑了，（這個(gè)坑，實(shí)在太傷我了 ~~~~(>_<)~~~~ ? ，走過(guò)的路過(guò)的，千萬(wàn)躲過(guò)呀。。。）

@property (nonatomic, assign) CGRect tempFrame;? 這樣寫(xiě)，恭喜你，躲過(guò)坑了。