一、写在前面
开发者在写View的时候一定逃不掉的就是这个命题。用Frame也好用Autolayout也好，如果没有精心设计过，布局部分一定惨不忍睹。
直接使用CGRectMake的话可读性很差，光看那几个数字，也无法知道view和view之间的位置关系。用Autolayout可读性稍微好点儿，但生成Constraint的长度实在太长，代码观感不太好。Autolayout这边可以考虑使用Masonry，代码的可读性就能好很多。这也是我正在使用的。
使用良好的工具来做View的布局，能提高我们的工作效率，也能减少bug发生的几率。架构不光要关心那些高大上的内容，也要多为工程提供方便易用的小工具，这样才能发挥架构的价值。
二、何时使用StoryBoard、Nib，何时使用纯代码写View
- 同一份代码文件的作者会有很多，不同作者同时修改同一份代码的情况也不少见。因此，使用Git进行代码版本管理时出现
Conflict的几率也比较大。
iOS开发过程中，会遇到最蛋疼的两种Conflict一个是project.pbxproj，另外一个就是StoryBoard或XIB。因为这些文件的内容的可读性非常差。
然而在StoryBoard中往往包含了多个页面，这些页面基本上不太可能都由一个人去完成，如果另一个人在做StoryBoard的操作的时候，出于某些目的动了一下不属于他的那个页面，比如为了美观调整了一下位置。然后另外一个人也因为要添加一个页面，而在Storyboard中调整了一下某个其他页面的位置。那么针对这个情况，我就只能说：祝你好运了。
但如果使用代码绘制View，Conflict一样会发生，但是这种Conflict就好解很多了，你懂的。
2.需求变化非常频繁，为了完成需求而针对现有代码进行微调的情况，以及针对现有代码的部分复用的情况也比较多。
到开发者这边来，这种情况就很蛋疼。因为这种改变有时候不光是UI，UI所对应的逻辑也有要改的可能，开发者就会两边文件都改，你原来link的那个view现在不link了，然后你的outlet对应也要删掉，这两部分只要有一个没做，编译通过之后跑一下App，一会儿就crash了。
另外，如果出现部分的代码复用，比如说某页面下某个View也希望放在另外一个页面里，相关的操作就不是复制粘贴这么简单了，你还得重新link一遍。也很麻烦。
3.复杂界面元素、复杂动画场景的开发任务比较多。
要是想在基于StoryBoard的项目中做一个动画，很麻烦。做几个复杂界面元素，更麻烦。有的时候我们挂Custom View上去，其实在StoryBoard里面看来就是一个空白View。然后另外一点就是，当你的layout出现问题需要调整的时候，还是挺难找到问题所在的，尤其是在复杂界面元素的情况下。
三、总结
所以在针对View层这边的要求时，我也是建议不要用StoryBoard。实现简单的东西，用Code一样简单，实现复杂的东西，Code比StoryBoard更简单。所以我更加提倡用code去画view而不是storyboard。
四、写在最后
作为前端开发（包括网页端、Android、iOS等），View层的变化是最大的，也是与用户接触最直接的，如果有bug，也是最影响用户体验的，于是，我们要花更多的时间在这一层，包括其拓展性，都很重要。
网友评论