前言 |
坦白来说,我是
storyboard / xib
重度使用患者。因为当时在学习
Cocoa Touch
组件时候,被这种拖控件拽关联的“所见即所得”的界面搭建方式所深深吸引了,从此便入了
iOS
开发的坑。颇有种“一入传销深似海”的感觉,(⊙﹏⊙)b!
了解
MacOS
发展历史的朋友都知道,
storyboard / xib
在这其中绝对是浓墨重彩的一笔,因为它颠覆了
coder
对搭建
UI
界面的认知,也确确实实带来了很多便利。然,随着技术的进步,
coder
对它们的使用越发趋于理性,因为它的一些众所周知的弊病:
-
不利于团队协作,维护成本高(
神一般
的
git
冲突) - 继承与重用问题
- 性能问题(自动布局的代码直接与界面元素耦合成了同一份二进制代码)
相信有这样论点的文章你可以轻易搜索到,笔者目前并没有足够多的资历来论述这些冲突点,不过还是建议你看一看喵神(王巍 @onevcat)的一些看法。所以你可能就很难在大型的多人合作开发项目中看到它们的身影了,即使有的话,估计也会被告知为:历史包袱,不好改!(如果你的老板愿意让你花时间去做这些吃力却又不怎么讨好的事情就又另当别论了,^_^)
在第一份实习工作中,我就在一次中午下班吃饭的路上,和公司里的同事“倾述”看
frame
布局代码的不适感(它的性能比
AutoLayout
要好一些,不过要上了一定量级的布局设置才会体现得较为明显,因为我们都相信它在写一个登录界面会有不错的表现!),并询问着一些几乎不怎么变动的界面是否可以考虑用
storyboard / xib
来写呢。这时,旁边
Android
组组长鄙视地看着我说:“现在谁还用这种可视化搭建界面的工具啊!”
感到有点遗憾的是,现在
storyboard / xib
逐渐沦为快速搭建
Demo UI
的好帮手,成为学习新控件的好助手了。(笔者窃以为在
Apple
给出以上提到的几点问题的解决方案之前,这种形势会维持下去。)正所谓时势造英雄,