程式設計 /z/programming
6
Ask kaif: 有多少人 iOS 開發，手寫 AutoLayout 來排元件 (/z/programming)

我們從以前到現在都沒有使用 Interface Builder 建立 nib，所以都是手寫元件位置和設定 autoresizingMask。前陣子因為把最低版本設為 6 以後，開始導入 AutoLayout 看能不能把元件排的更容易懂跟方便，沒想到比自己想像中難很多，一部分也是因為一直沒把 iOS View 的生命週期搞得很清楚。
因為用官方的 API 去寫真的會寫死人，也超級難維護，所以我們用 Masonry1 來寫，感覺稍微好寫跟好懂一點。接下來就遇到 collection view cell 計算高度的問題，參考了 stackoverflow2 和需要 uilabel 動態調整高度而參考了 Intrinsic Content Size of Multi-Line Text3，搞了一整天累死了。有多少人是用 autolayout 的嗎？讓我知道還有什麼雷我沒踩到嗚嗚....0rz

1
https://github.com/Masonry/Masonry
2
http://stackoverflow.com/questions/18746929/using-auto-layout-in-uitableview-for-dynamic-cell-layouts-variable-row-heights
3
http://www.objc.io/issue-3/advanced-auto-layout-toolbox.html
18 則討論 koji 張貼於

siuying 積分 4 編輯於

自動計算高度只是基本啊，還有更多更頭痛的。

有人問「為什麼不用 nib ?」nib 對於固定的介面來說是最好的，簡單易作 (假設你學懂了怎樣用)，要說缺點的話 只是不好維護、沒有重用性而已，但因為很易做，那也沒大問題。

但是當問題比較複雜的時候，就非要用手動方法做不可了。

比如說我想做 Facebook Feed ，我有很多種不同的 Feed：

  • 基本 post
  • 有圖片的 post
  • 有影片的 post
  • 有 quote 的post
  • 某人 like 了某個 post
  • 某人分享了某個 post

如果這些不同的條件下的 layout 可以稍為不同 (比如說 margin 或 font size)，用 nib 作就會很煩了。 有些時候可以用一個 layout 一個nib 蒙混過去，但如果以上變化可以組合呢，需要動畫化呢？這時手寫就是唯一解決方案。

習慣了的話用 code 比 nib 更簡單更快，也可以很好讀。所以不要怕用code layout 。Masonry 是個很漂亮很好用的 API ，考慮到很多常用的情況 (如更新 constant 不用存 constraint 的 reference) 。

要是說最需要注意的地方只有一個：把複雜的 View 分拆，組合不同的較少的元件。例如 post 可以分作 header ，body 和 footer。header 有頭像有名字、footer 有 Like / Share / Comment 等等。如果在一個 View 裡做的話，layout code 很快就會暴漲，有很多 branch，有錯誤時 (在 Auto layout 時很容易發生) 也很難找到原因。現在回想這很明顯，但這是浪費了無數光陰才明白的。

回應

Kros 積分 3

遇到 scrollview 就更慘了，要預先知道 contentSize。如果要動態的 contentSize，很複雜。所以我遇到要有動態的 contentSize，就用以前的 layout 方式了。

回應

superbil 積分 3

之前有試過 PureLayout1 這套用起來也是簡單；所以我也算是手寫排元件的

一開始就是純手工來排畫面上的東西，所以換過來其實也差不多啦，只是觀念上和考量的事情並不相同；然而自己試過一陣子 Interface Builder 的感覺是不太好，雖然說大部份的事情都可以自訂義，但是那些東西也是要重新習慣過，再說 Interface Builder 要整理弄懂的功夫其實並不容易。大部份時候都會有奇怪的需求，或是不同的 view 之間的整合顯示，很多東西並不是 Interface Builder 可以完全解決的。

xib 也是有他的限制，一個頁面上畫面上元件不多，大部份的東西都能夠解決，愈來愈多元件就要考慮過了，因為重複的元件有不同的行為，也會有不同的顯示或是執行流程，xib 也只能排出一定的型式，超過一定的符度之後他也是不管的啦 (笑

storyboard 在舊版 XCode 6 之前，若有試著把他丟進版本控管系統來看一下的話，他改動的範圍是非常大的，也就是只要有兩個人在同時編輯，要手動 merge 那個 XML 是非常困難的； XCode 6.x 之後，產生和編輯的範圍會變小，讓這個檔案 (storyeboard) merge 比較不會出錯，但是誰知道那天會有人遇到呢？這個就算是開發時的不可測量範圍吧

然後有朋友提醒我，Interface Builder 也不是完全的所見即所得…突然覺得手動自己寫起來安心多了阿！

1
https://github.com/smileyborg/PureLayout
回應

chchwy 積分 0

為什麼不用 nib ? 這是我比較好奇的地方。

回應

IngramChen 積分 0

nib/xib 的內容不能手編，也不能在 git merge。我一開始學 iOS 時，也是乖乖的用工具。後來發現不對，怎麼這麼難控制，所以就開始有一部份用手寫，到了最後全部都手寫了。

nib 之於 Xcode 感覺就是像是 html 之於 dreamweaver。dreamweaver 產生的 html 能看嗎？現代的開發者都比較傾向手寫 css, html及程式了。這點在 android 也是一樣，寫個 layout xml，程式 bind 一下就好了。你的 layout xml 能做的很乾淨好維護，你看 git diff 也看得出哪邊被改了。iOS 的開發在這點上實在是很弱。

zonble 曾寫過一篇: 你為什麼不該在你的 iOS 軟體專案中使用 Storyboard1 ，道理也有點類似，都是不靠 visual tool 來生成前端。

不過 Masonry API 設計的還不錯，算是補償了一些。

1
http://zonble.net/archives/2014_01/1540.php
回應

chchwy 積分 1

Zonble 那篇文章不推薦 storyboard ，因為不適合多人共編，我們團隊也從來不用 storyboard。

但是我們團隊一向使用 xib ，因為視覺的東西就是應該要用視覺工具來開發，而且是由 UI 專業人員來做，programmer 不應該插手這件事。

有個工具可以輔助專業分工，我覺得這是進步的地方，至少我自己認為 dreamweaver 產生垃圾 html 跟要不要用 design tool 來設計 iOS UI 是兩回事。

當然碰到複雜的情況，我們會 subclass xib 裡面的某個元件，但是這也只有在必要的時候才做。

回應

IngramChen 積分 0 編輯於

設計師可以訓練到用 Xcode，那也挺厲害的。

我們這邊的設計師只負責到 photoshop/illustrater 的設計，後面的全部都是工程師這邊按著樣子去手刻... 工程師並不插手設計。不過 UX 方面的是大家一起討論出來的。

回應

chchwy 積分 2 編輯於

我們公司有配置 Technical Art 這個職位，產出 UI Layout 是他們的工作 XD

其實除了 xib ，我們公司也用 Qt 製作桌面程式，也是全面採用 Qt Designer 來拉 UI，純手工 code 產生 view 是不被鼓勵的，因為這樣子不管改什麼小細節都要找 RD，RD 時間很珍貴的。

回應

IngramChen 積分 0

Technical Art… 好奢侈啊

好奇 web 這方面呢？Technical Art 手刻 html/css 還是用工具拉的？

回應

chchwy 積分 2

因為我不在 Web 部門，所以剛剛跑去偷問了一下，發現該位 Artist 會用 bootstrap 跟前端攻城師合作 XDD

回應

koji 積分 0

RD、Art 多少成員啊？

回應

chchwy 積分 2

如果只看我們產品團隊的話，RD 10人左右、 Techinical Art 2人、真正專職美術的 Art 則是不屬於某特定團隊。

回應

Kros 積分 1

簡單的 view controller/view 用 nib 是 ok，但是複雜的 vc/view 還是用手寫的比較好維護，而且多人同時開發，也不用管理 nib merge failed 的問題。

回應

koji 積分 0

連三回也 XD....

回應

koji 積分 0 編輯於

其實在我開始加入 iOS 上開發之前，就有同事試過 nib 跟程式碼中設定，所以我自己是沒多深的見解。不管是當初的理由跟後來我自己去看一下 stackover 大家討論，就是不好用、沒特別偏好 WYSIWYG、複雜的 UI 好不好拉、多人開發以及產生的檔案衝突該怎辦...等等，後來的 Storyboard 也沒去用過。看一看這些討論就...沒特別想回頭嘗試了。

回應

chchwy 積分 1

storyboard 不好用，但是 xib 我覺得值得一試。

回應