<分区>
我发现有些团队需要使用 Masonry 等工具以编程方式创建每个 View 。我想知道这是什么原因。我一直认为 IB 是创建 View 和布局的一种非常快速和简单的方法。
您能否详细说明使用程序化方法而不是 IB 的所有优缺点?
最佳答案
常用的论点总结得很好in this post :
I have spent countless hours searching for the source of a bug only to discover it’s some checkbox in one of the half dozen inspectors in Interface Builder. If it was in code, it’s simple to glance at the view code and see the source of the problem much quicker.
总的来说,我还没有真正发现这是真的。在某些情况下,尤其是自动布局,通常是正确的。
If you use Interface Builder and have outlets and forget to connect the outlet in the second place you use it, you crash at runtime. This is terrible. This introduces a whole new class of bugs.
发生了,但是防御性编程以在 viewDidLoad
中使用断言检测它们并不难。
Have you ever had a merge conflict in a NIB. It’s the worst. (Granted the XIB format has helped, but it’s just awful instead of impossible now.) If you’re working in a large application with several developers, you will waste an enormous amount of time dealing with this issue.
这确实是一个非常可靠的论据。在我们有了引用资料之前, Storyboard是一个严重的痛点,现在它只是经常令人烦恼。代码差异和历史记录远比 Interface Builder 更好。
Every time I get a crash while editing a NIB, I grumble to myself and wish it was code even more.
这曾经是一个很好的争论。您仍然需要学会避免一些粗糙的边缘,但现在这是一个平庸的论点。
Layout code is not hard. Auto-layout is a bit more code than traditional layout, but it’s still not bad. Trying to work with auto-layout in Interface Builder is maddening. Setting outlets to control built-in constraints is just silliness.
It’s so simple to just override layoutSubviews and do your thing. Personally, I find this much easier to work with than auto-layout for most things.
这在几年前是毫无保留的事实。现在好多了,堆栈 View 已经让很多痛苦消失了,但它仍然是一个痛点。
Interface Builder itself is not bad. It does encourage bad practices, prevents reusability (making working with others more difficult), and slows your workflow.
这让与他人合作变得更加困难是一个可靠的观点,相信任何从事过大型项目的人都会不同意,因为将编辑合并到 Interface Builder 文件几乎是不可能的。其余的......充其量是有争议的。
关于ios - 是否有任何理由以编程方式创建 View 而不是使用界面构建器?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/37680491/