关于代码手写UI,xib和StoryBoard
代碼手寫UI
這種方法經(jīng)常被學(xué)院派的極客或者依賴多人合作的大型項(xiàng)目大規(guī)模使用。Geek們喜歡用代碼構(gòu)建UI,是因?yàn)榇a是鍵盤敲出來(lái)的,這樣可以做到不開IB,手不離開鍵盤就完成工作,可以專注于編碼環(huán)境,看起來(lái)很cool很高效,而且不到運(yùn)行時(shí)大家都不知道會(huì)是什么樣子,也顯出了程序員這一職業(yè)的高大上及神秘氣息(這個(gè)真的不是在黑..想想大家一起在設(shè)計(jì)師背后指點(diǎn)江山的場(chǎng)景吧)。大型多人合作項(xiàng)目使用代碼構(gòu)建UI,主要是看中純代碼在版本管理時(shí)的優(yōu)勢(shì),檢查追蹤改動(dòng)以及進(jìn)行代碼合并相對(duì)容易一些。
另外,代碼UI可以說(shuō)具有最好的代碼重用性。如果你的目的是寫一些可以高度重用的控件提供給其他開發(fā)者使用,那毫無(wú)疑問最好的選擇應(yīng)該是使用代碼來(lái)完成UIView的子類。這樣進(jìn)一步的修改和其他開發(fā)者在使用時(shí),都會(huì)方便不少。使用代碼也是最為強(qiáng)大的,會(huì)有xib或者StoryBoard做不了的事情,但是使用代碼最終一定能夠完成所要的需求。
但是代碼手寫UI的劣勢(shì)同時(shí)也是最明顯的,主要就是一個(gè)字:慢。首先相比可視化的IB來(lái)說(shuō),完成一個(gè)并不太復(fù)雜的界面,你可能需要寫上數(shù)百行的UI代碼。不論是初始化一個(gè)Label,還是設(shè)定一個(gè)frame或者添加一個(gè)target-action,都需要寫代碼,這不僅在前期極為浪費(fèi)時(shí)間,在之后維護(hù)時(shí)代碼定位和尋找也會(huì)很痛苦。其次,因?yàn)槟銦o(wú)法直觀地看到你能得到的結(jié)果,所以你很可能需要不斷地Cmd+R/Cmd+.來(lái)修改各個(gè)視圖的位置大小。即使你用上了Reveal或者RestartLessOften之類的工具,也還是無(wú)法特別方便地完成需要的布局。另外加上如果需要利用AutoLayout來(lái)進(jìn)行尺寸適配的話,使用代碼進(jìn)行約束就更加頭疼了。很多時(shí)候一個(gè)無(wú)法滿足的約束的問題就夠來(lái)回運(yùn)行修改調(diào)試很長(zhǎng)時(shí)間了。
Xibs
相對(duì)于代碼,使用IB和xib文件來(lái)組織UI,可以省下大量代碼和時(shí)間,從而得到更快的開發(fā)速度。如果你曾經(jīng)受到過微軟家Visual Basic或者其他Visual系的可視化界面的荼毒與殘害,因此懷疑Interface Builder的純正血統(tǒng)和工作能力,建議可以看看這些資料以糾正三觀:Jean-Marie Hullot的Interface Builder神話以及西裝革履的青澀喬幫主在NeXT時(shí)親手用IB構(gòu)建應(yīng)用(需要FQ)。另外,不妨打開你的Mac上的Application文件夾中或者iPhone上Apple家的各種應(yīng)用。你會(huì)驚奇地發(fā)現(xiàn),IB遠(yuǎn)比你看到的要強(qiáng)大:小至計(jì)算器取色器這類小工具,大至iWork三件套,Aperture或Final Cut這樣的專業(yè)級(jí)應(yīng)用,無(wú)一不是使用IB來(lái)完成UI制作的。
其實(shí)IB和xib是從iOS SDK初次面世開始就是捆綁在開發(fā)者工具套裝內(nèi)的內(nèi)容了,而到了Xcode 4之后更被直接集成到了Xcode中成為了IDE的一部分。xib設(shè)計(jì)的一大目的其實(shí)是為了良好的MVC:一般來(lái)說(shuō),單個(gè)的xib文件對(duì)應(yīng)一個(gè)ViewController,而對(duì)于一些自定義的view,往往也會(huì)使用單個(gè)xib并從main bundle進(jìn)行加載的方式來(lái)載入。IB幫助完成view的創(chuàng)建,布局和與file owner的關(guān)系映射等一些列工作。對(duì)于初學(xué)者來(lái)說(shuō),牢記xib的文件都是view的內(nèi)容,有助于建立起較好的MVC的概念,從而在開發(fā)中避免或少走彎路。
xib文件之前一大被詬病的問題是文件內(nèi)容過于復(fù)雜,可讀性很差,即使只是簡(jiǎn)單打開沒有編輯也有可能造成變化而導(dǎo)致合并和提交的苦難。在Xcode 5中Apple大幅簡(jiǎn)化了xib文件的格式,使其變得易讀易維護(hù)。可以說(shuō)現(xiàn)在對(duì)于xib文件在版本管理上其實(shí)和純代碼已經(jīng)沒有太大差異,只要仔細(xì)看過一遍xib的文件內(nèi)容,自然能理解絕大部分,并很好地追蹤并查找過往的修改記錄了。
當(dāng)然xib也不是完美的。最大的問題在于xib中的設(shè)置往往并非最終設(shè)置,在代碼中你將有機(jī)會(huì)覆蓋你在xib文件中進(jìn)行的UI設(shè)計(jì)。在不同的地方對(duì)同一個(gè)屬性進(jìn)行設(shè)置,這在之后的維護(hù)中將會(huì)是噩夢(mèng)般的存在。因?yàn)槠鋵?shí)IB還是有所局限的,它沒有邏輯判斷,也很難在運(yùn)行時(shí)進(jìn)行配置,而反之使用代碼確是無(wú)所不能的。在使用xib時(shí),輔以部分代碼來(lái)補(bǔ)充和完成功能幾乎是不可避免的。關(guān)于這點(diǎn)在開發(fā)時(shí)應(yīng)該予以高度重視,如果選擇xib,那么要盡量將xib的工作和代碼的工作隔離開來(lái):能夠使用xib完成的內(nèi)容就統(tǒng)一使用xib來(lái)做,而不要說(shuō)三個(gè)Label其中兩個(gè)在xib設(shè)置了字體而另一個(gè)卻在代碼中完成。盡量?jī)H保持必要的、較少的IBOutlet和IBAction會(huì)是一個(gè)好方法。
StoryBoard
iOS5之后Apple提供了一種全新的方式來(lái)制作UI,那就是StoryBoard。簡(jiǎn)單理解來(lái)說(shuō),可以把StoryBoard看做是一組viewController對(duì)應(yīng)的xib,以及它們之間的轉(zhuǎn)換方式的集合。在StoryBoard中不僅可以看到每個(gè)ViewController的布局樣式,也可以明確地知道各個(gè)ViewController之間的轉(zhuǎn)換關(guān)系。相對(duì)于單個(gè)的xib,其代碼需求更少,也由于集合了各個(gè)xib,使得對(duì)于界面的理解和修改的速度也得到了更大提升。減少代碼量就是減少bug量,這也是程序開發(fā)中的真理之一。
在Xcode5之后,StoryBoard已經(jīng)成為新建項(xiàng)目的默認(rèn)配置,這也代表了Apple對(duì)開發(fā)者的建議和未來(lái)的方向。WWDC2013的各個(gè)Sample Code中也基本都使用了StoryBoard來(lái)進(jìn)行演示。可以預(yù)見到,之后Apple必定會(huì)在這方面進(jìn)行繼續(xù)強(qiáng)化,而反之純代碼或者單個(gè)xib的方式很可能不會(huì)再得到增強(qiáng)。
如果不考慮iOS版本的支持(其實(shí)說(shuō)實(shí)話現(xiàn)在已經(jīng)很少還見到要從iOS4開始支持的app了吧),現(xiàn)在StoryBoard面臨的最大問題就是多人協(xié)作。因?yàn)樗械腢I都定義在一個(gè)文件中,因此很多開發(fā)者個(gè)人或企業(yè)的技術(shù)負(fù)責(zé)人認(rèn)為StoryBoard是無(wú)法進(jìn)行協(xié)作開發(fā)的,其實(shí)這更多的是一種對(duì)StoryBoard的陌生所造成的誤解。雖然Apple并沒有在WWDC明確提及,但是沒有人規(guī)定整個(gè)項(xiàng)目只能有一個(gè)StoryBoard文件。一種可行的做法是將項(xiàng)目的不同部分分解成若干個(gè)StoryBoard,并安排開發(fā)人員對(duì)自己的部分進(jìn)行負(fù)責(zé)。簡(jiǎn)單舉例比如一個(gè)有4個(gè)tab功能相互獨(dú)立的基于UITabBarViewController的應(yīng)用,完全可以使用4個(gè)StoryBoard來(lái)分別代表4個(gè)tab,并在相互無(wú)干擾的情況下完成開發(fā)。這樣一來(lái)就不會(huì)存在所謂的沖突問題了。StoryBoard的API是如此簡(jiǎn)單,現(xiàn)在的SDK中一共方法數(shù)量一只手就能數(shù)過來(lái),所以具體方法在這里就不再羅嗦了。
StoryBoard的另外的挑戰(zhàn)來(lái)源于ViewController的重用和自定義的view的處理。對(duì)于前者,在正確封裝接口以及良好設(shè)計(jì)的基礎(chǔ)上,其實(shí)StoryBoard的VC重用與代碼的VC重用是沒有本質(zhì)區(qū)別的,在StoryBoard中添加封裝良好需要重用的Scene即可解決。而對(duì)于后者,因?yàn)镾toryBoard中已經(jīng)不允許有單個(gè)view的存在,因此很多時(shí)候我們還是需要借助于單個(gè)的xib來(lái)自定義UI。這一點(diǎn)可以說(shuō)是由于StoryBoard的設(shè)計(jì)思路所造成的,StoryBoard更強(qiáng)調(diào)的是一種層次結(jié)構(gòu),是在全局的視角上來(lái)組織UI設(shè)計(jì)和遷移。而對(duì)于單個(gè)的view,更多的會(huì)注重于重用和定制,而與整個(gè)項(xiàng)目的流程沒有太大關(guān)系。相信抓住這一要點(diǎn),就能很好地了解什么時(shí)候使用xib,什么時(shí)候使用StoryBoard。
關(guān)于StoryBoard最后要說(shuō)的是,現(xiàn)在會(huì)有一些對(duì)于StoryBoard性能上的擔(dān)憂。因?yàn)橄鄬?duì)于單個(gè)xib來(lái)說(shuō),StoryBoard文件往往更大,加載速度也相應(yīng)變慢。但是其實(shí)隨著現(xiàn)在設(shè)備的更新?lián)Q代,在iPhone4都難覓的今天,這點(diǎn)性能上的差距幾乎可以忽略了。而再之后的設(shè)備,不論讀取還是解析,只會(huì)越來(lái)越快。所以性能上的問題完全是沒有擔(dān)心的必要的。
我的觀點(diǎn)和選擇
我入門的時(shí)候是使用xib的,因?yàn)槟菚r(shí)候還沒有StoryBoard,而我也不是喜歡代碼的學(xué)院派Geek。到現(xiàn)在,三種方式我都有嘗試過,并分別得到了一些可能還并不是特別深刻體會(huì)。對(duì)于現(xiàn)在的我來(lái)說(shuō),xib是我的奶酪,也是我在自己的一些項(xiàng)目里一直使用的方式,我可以在極短短時(shí)間內(nèi)用xib架起一套包括自定義要素和良好部件重用性復(fù)雜UI。但是在我嘗試了幾次使用StoryBoard制作demo之后,我已經(jīng)決定在之后的項(xiàng)目轉(zhuǎn)向使用StoryBoard。一方面因?yàn)榇_實(shí)是未來(lái)方向(每次新工程刪StoryBoard很討厭..),現(xiàn)在的StoryBoard專有的preview功能,以及之后AutoLayout的進(jìn)一步改進(jìn)等都很值得期待;另一方面也覺得奶酪放一個(gè)地方太久了會(huì)不好,趁著iOS7的大變革,也更新一下自己的觀念和方式,把奶酪換個(gè)地方擺擺,也許會(huì)對(duì)以后大有裨益。
對(duì)于初心者來(lái)說(shuō),我并不建議上手就直接使用代碼來(lái)進(jìn)行UI制作和布局,因?yàn)槿唛L(zhǎng)的UI代碼確實(shí)非常乏味無(wú)趣。盡快看到成品,至少盡快看到原型,是保持興趣,繼續(xù)深入和從事職業(yè)的有效動(dòng)力。所以如果有可能有條件,在老鳥的指導(dǎo)下選擇StoryBoard來(lái)進(jìn)行快速構(gòu)建(或者如果是單個(gè)人開發(fā)的話,可以不用考慮多個(gè)StoryBoard協(xié)作,就更容易),會(huì)是入門的好選擇。而最新的教程和文檔已經(jīng)開始逐漸偏向StoryBoard,關(guān)于StoryBoard的問題在SO上關(guān)注度也會(huì)更高,這樣在入門時(shí)會(huì)有更多的資料可以進(jìn)行參考。
這并不是說(shuō)不需要關(guān)心代碼UI或者xib,因?yàn)槭褂肧toryBoard的時(shí)候在只能使用代碼以及自定義單個(gè)view時(shí),還是不可避免地需要接觸它們的。這里想給的一點(diǎn)建議就是,雖然你不依賴代碼來(lái)進(jìn)行UI制作,但是了解并掌握如何使用純代碼來(lái)從頭構(gòu)建UI還是非常必要的:包括從新建Window開始,到初始化ViewController,添加必要的view,設(shè)定它們的property,以及添加和處理它們的各種響應(yīng)及responser鏈等內(nèi)容。現(xiàn)在iOS開發(fā)入門非常容易,Xcode和xib/StoryBoard幫助開發(fā)者隱藏了太多的細(xì)節(jié),但是很多時(shí)候如果你不明白u(yù)nderhood到底是些什么,為什么這些xib/StoryBoard會(huì)這樣運(yùn)作的話,經(jīng)常會(huì)出現(xiàn)卡在一些很可笑的和初級(jí)的bug上找不著北,這其實(shí)會(huì)是對(duì)時(shí)間的巨大浪費(fèi),很不值得。
一些IB小技巧
最后分享一些IB使用上的小技巧作為結(jié)束吧。其中很多方法也可以用在StoryBoard上,所以在向我自己之前xib使用者生涯致敬的同時(shí),也算是一點(diǎn)小的備忘總結(jié)吧。
同時(shí)添加多個(gè)outlet
在IB中,選中一個(gè)view并右鍵點(diǎn)擊,將會(huì)出現(xiàn)灰色的HUD,可以在其上方便地拖拉或設(shè)定事件和outlet。你可以同時(shí)打開多個(gè)這樣的面板來(lái)一次性添加所有outlet。右鍵點(diǎn)擊面板,隨便拖動(dòng)一下面板,然后再打開另一個(gè)。你會(huì)發(fā)現(xiàn)前一個(gè)面板也留下來(lái)了,這樣你就可以方便地進(jìn)行拖拽設(shè)定了。
當(dāng)然,對(duì)于成組和行為類似的IBOutlet,應(yīng)該直接使用IBOutletCollection來(lái)進(jìn)行處理會(huì)更方便。
可視化坐標(biāo)距離
IB最煩人的問題就是對(duì)其。用代碼的時(shí)候我們可以明確地指定x,y坐標(biāo),但是換到IB的時(shí)候我們更多的時(shí)候是靠拖拽UIView來(lái)布局。比如需要三個(gè)間隔相同的label,除了用強(qiáng)大的肉眼來(lái)估測(cè)距離是否相等以外,難道只能乖乖分別選中三個(gè)label,記下它們的坐標(biāo)然后打開計(jì)算器來(lái)做加減法么?
顯然不要那么笨,試試看選中一個(gè)label,然后按住option鍵并將鼠標(biāo)移動(dòng)到其他label上試試?你可以發(fā)現(xiàn)view之間的距離都以很容易理解的方式顯示出來(lái)了。不僅是同層次的view,被選中view與其他層次的view之間的距離關(guān)系也可以同樣顯示。
在一組view層次中進(jìn)行選擇
對(duì)于一些復(fù)雜的view層級(jí)關(guān)系,我們往往直接在IB中選擇會(huì)比較困難。比如view相互覆蓋時(shí),我們很難甚至不能在編輯視圖中選中底層的view。這時(shí)候一般的做法是打開左側(cè)的view層級(jí)面板,一層層展開然后選擇自己需要的view。其實(shí)我們也有更簡(jiǎn)單的方法:按住Cmd和Shift,然后在需要選擇的view上方按右鍵,就可以列出在點(diǎn)擊位置上所有的view的列表。藉此就可以方便快速地選中想要的view了。
添加輔助線
這么高大上的技巧必須放在最后啊...在左邊的層級(jí)列表中雙擊某個(gè)view,然后Cmd+_或者Cmd+|即可在選中的view上添加一條水平或者垂直中心的輔助線。當(dāng)然這個(gè)輔助線是可以隨意移動(dòng)的。如果干過設(shè)計(jì)的同學(xué)肯定明白這個(gè)的意義了,在之后的對(duì)其和設(shè)計(jì)變更的時(shí)候都有重要的參考價(jià)值。
?
轉(zhuǎn)自:http://onevcat.com/2013/12/code-vs-xib-vs-storyboard/
轉(zhuǎn)載于:https://www.cnblogs.com/W-Kr/p/5191477.html
總結(jié)
以上是生活随笔為你收集整理的关于代码手写UI,xib和StoryBoard的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: springmvc学习笔记--mybat
- 下一篇: 准备去香港南丫岛,哪一家旅行社比较好