iOS应用架构谈 view层的组织和调用方案

View层架构是影响业务方迭代周期的因素之一

产品经理产生需求的速度会非常快，尤其是公司此时仍处于创业初期，在规模稍大的公司里面，产品经理也喜欢挖大坑来在leader面前刷存在感，比如阿里。这就导致业务工程师任务非常繁重。正常情况下让产品经理砍需求是不太可能的，因此作为架构师，在架构里有一些可做可不做的事情，最好还是能做就做掉，不要偷懒。这可以帮业务方减负，编写代码的时候也能更加关注业务。

我跟一些朋友交流的时候，他们都会或多或少地抱怨自己的团队迭代速度不够快，或者说，迭代速度不合理地慢。我认为迭代速度不是想提就能提的，迭代速度的影响因素有很多，一期PRD里的任务量和任务复杂度都会影响迭代周期能达到什么样的程度。抛开这些外在的不谈，从内在可能导致迭代周期达不到合理的速度的原因来看，其中有一个原因很有可能就是View层架构没有做好，让业务工程师完成一个不算复杂的需求时，需要处理太多额外的事情。当然，开会多，工程师水平烂也属于迭代速度提不上去的内部原因，但这个不属于本文讨论范围。还有，加班不是优化迭代周期的正确方式，嗯。

一般来说，一个不够好的View层架构，主要原因有以下五种：

代码混乱不规范

过多继承导致的复杂依赖关系

模块化程度不够高，组件粒度不够细

横向依赖

架构设计失去传承

这五个地方会影响业务工程师实现需求的效率，进而拖慢迭代周期。View架构的其他缺陷也会或多或少地产生影响，但在我看来这里五个是比较重要的影响因素。如果大家觉得还有什么因素比这四个更高的，可以在评论区提出来我补上去。

对于第五点我想做一下强调：架构的设计是一定需要有传承的，有传承的架构从整体上看会非常协调。但实际情况有可能是一个人走了，另一个顶上，即便任务交接得再完整，都不可避免不同的人有不同的架构思路，从而导致整个架构的流畅程度受到影响。要解决这个问题，一方面要尽量避免单点问题，让架构师做架构的时候再带一个人。另一方面，架构要设计得尽量简单，平缓接手人的学习曲线。我离开安居客的时候，做过保证：凡是从我手里出来的代码，终身保修。所以不要想着离职了就什么事儿都不管了，这不光是职业素养问题，还有一个是你对你的代码是否足够自信的问题。传承性对于View层架构非常重要，因为它距离业务最近，改动余地最小。

所以当各位CTO、技术总监、TeamLeader们觉得迭代周期不够快时，你可以先不忙着急吼吼地去招新人，《人月神话》早就说过加人不能完全解决问题。这时候如果你可以回过头来看一下是不是View层架构不合理，把这个弄好也是优化迭代周期的手段之一。

嗯，至于本系列其他三项的架构方案对于迭代周期的影响程度，我认为都不如View层架构方案对迭代周期的影响高，所以这是我认为View层架构是最重要的其中一个理由。

View层架构是最贴近业务的底层架构

View层架构虽然也算底层，但还没那么底层，它跟业务的对接面最广，影响业务层代码的程度也最深。在所有的底层都牵一发的时候，在View架构上牵一发导致业务层动全身的面积最大。

所以View架构在所有架构中一旦定型，可修改的空间就最小，我们在一开始考虑View相关架构时，不光要实现功能，还要考虑更多规范上的东西。制定规范的目的一方面是防止业务工程师的代码腐蚀View架构，另一方面也是为了能够有所传承。按照规范来，总还是不那么容易出差池的。

还有就是，架构师一开始考虑的东西也会有很多，不可能在第一版就把它们全部实现，对于一个尚未发版的App来说，第一版架构往往是最小完整功能集，那么在第二版第三版的发展过程中，架构的迭代任务就很有可能不只是你一个人的事情了，相信你一个人也不见得能搞定全部。所以你要跟你的合作者们有所约定。另外，第一版出去之后，业务工程师在使用过程中也会产生很多修改意见，哪些意见是合理的，哪些意见是不合理的，也要通过事先约定的规范来进行筛选，最终决定如何采纳。

规范也不是一成不变的，什么时候枪毙意见，什么时候改规范，这就要靠各位的技术和经验了。

这篇文章讲什么？

View代码结构的规定

关于view的布局

何时使用storyboard，何时使用nib，何时使用代码写View

是否有必要让业务方统一派生ViewController？

方便View布局的小工具

MVC、MVVM、MVCS、VIPER

本门心法

跨业务时View的处理

留给评论区各种补

总结

View代码结构的规定

架构师不是写SDK出来交付业务方使用就没事儿了的，每家公司一定都有一套代码规范，架构师的职责也包括定义代码规范。按照道理来讲，定代码规范应该是属于通识，放在这里讲的原因只是因为我这边需要为View添加一个规范。

制定代码规范严格来讲不属于View层架构的事情，但它对View层架构未来的影响会比较大，也是属于架构师在设计View层架构时需要考虑的事情。制定View层规范的重要性在于：

提高业务方View层的可读性可维护性

防止业务代码对架构产生腐蚀

确保传承

保持架构发展的方向不轻易被不合理的意见所左右

在这一节里面我不打算从头开始定义一套规范，苹果有一套Coding Guidelines，当我们定代码结构或规范的时候，首先一定要符合这个规范。

然后，相信大家各自公司里面也都有一套自己的规范，具体怎么个规范法其实也是根据各位架构师的经验而定，我这边只是建议各位在各自规范的基础上再加上下面这一点。

viewController的代码应该差不多是这样：

要点如下：

所有的属性都使用getter和setter

不要在viewDidLoad里面初始化你的view然后再add，这样代码就很难看。在viewDidload里面只做addSubview的事情，然后在viewWillAppear里面做布局的事情(勘误1)，最后在viewDidAppear里面做Notification的监听之类的事情。至于属性的初始化，则交给getter去做。

比如这样：

这样即便在属性非常多的情况下，还是能够保持代码整齐，view的初始化都交给getter去做了。总之就是尽量不要出现以下的情况：

这种做法就不够干净，都扔到getter里面去就好了。关于这个做法，在唐巧的技术博客里面有一篇文章和我所提倡的做法不同，这个我会放在后面详细论述。

getter和setter全部都放在最后

因为一个ViewController很有可能会有非常多的view，就像上面给出的代码样例一样，如果getter和setter写在前面，就会把主要逻辑扯到后面去，其他人看的时候就要先划过一长串getter和setter，这样不太好。然后要求业务工程师写代码的时候按照顺序来分配代码块的位置，先是life cycle，然后是Delegate方法实现，然后是event response，然后才是getters and setters。这样后来者阅读代码时就能省力很多。

每一个delegate都把对应的protocol名字带上，delegate方法不要到处乱写，写到一块区域里面去

比如UITableViewDelegate的方法集就老老实实写上#pragma mark - UITableViewDelegate。这样有个好处就是，当其他人阅读一个他并不熟悉的Delegate实现方法时，他只要按住command然后去点这个protocol名字，Xcode就能够立刻跳转到对应这个Delegate的protocol定义的那部分代码去，就省得他到处找了。

event response专门开一个代码区域

所有button、gestureRecognizer的响应事件都放在这个区域里面，不要到处乱放。

关于private methods，正常情况下ViewController里面不应该写

不是delegate方法的，不是event response方法的，不是life cycle方法的，就是private method了。对的，正常情况下ViewController里面一般是不会存在private methods的，这个private methods一般是用于日期换算、图片裁剪啥的这种小功能。这种小功能要么把它写成一个category，要么把他做成一个模块，哪怕这个模块只有一个函数也行。

ViewController基本上是大部分业务的载体，本身代码已经相当复杂，所以跟业务关联不大的东西能不放在ViewController里面就不要放。另外一点，这个private method的功能这时候只是你用得到，但是将来说不定别的地方也会用到，一开始就独立出来，有利于将来的代码复用。

为什么要这样要求？

我见过无数ViewController，代码布局乱得一塌糊涂，这里一个delegate那里一个getter，然后ViewController的代码一般都死长死长的，看了就让人头疼。

定义好这个规范，就能使得ViewController条理清晰，业务方程序员很能够区分哪些放在ViewController里面比较合适，哪些不合适。另外，也可以提高代码的可维护性和可读性。

关于View的布局

业务工程师在写View的时候一定逃不掉的就是这个命题。用Frame也好用Autolayout也好，如果没有精心设计过，布局部分一定惨不忍睹。

直接使用CGRectMake的话可读性很差，光看那几个数字，也无法知道view和view之间的位置关系。用Autolayout可读性稍微好点儿，但生成Constraint的长度实在太长，代码观感不太好。

Autolayout这边可以考虑使用Masonry，代码的可读性就能好很多。如果还有使用Frame的，可以考虑一下使用这个项目。

这个项目里面提供了Frame相关的方便方法(UIView+LayoutMethods)，里面的方法也基本涵盖了所有布局的需求，可读性非常好，使用它之后基本可以和CGRectMake说再见了。因为天猫在最近才切换到支持iOS6，所以之前天猫都是用Frame布局的，在天猫App中，首页，范儿部分页面的布局就使用了这些方法。使用这些方便方法能起到事半功倍的效果。

这个项目也提供了Autolayout方案下生产Constraints的方便方法(UIView+AEBHandyAutoLayout)，可读性比原生好很多。我当时在写这系列方法的时候还不知道有Masonry。知道有Masonry之后我特地去看了一下，发现Masonry功能果然强大。不过这系列方法虽然没有Masonry那么强大，但是也够用了。当时安居客iPad版App全部都是Autolayout来做的View布局，就是使用的这个项目里面的方法。可读性很好。

让业务工程师使用良好的工具来做View的布局，能提高他们的工作效率，也能减少bug发生的几率。架构师不光要关心那些高大上的内容，也要多给业务工程师提供方便易用的小工具，才能发挥架构师的价值。

何时使用storyboard，何时使用nib，何时使用代码写View

这个问题唐巧的博客里这篇文章也提到过，我的意见和他是基本一致的。

在这里我还想补充一些内容：

具有一定规模的团队化iOS开发(10人以上)有以下几个特点：

同一份代码文件的作者会有很多，不同作者同时修改同一份代码的情况也不少见。因此，使用Git进行代码版本管理时出现Conflict的几率也比较大。

需求变化非常频繁，产品经理一时一个主意，为了完成需求而针对现有代码进行微调的情况，以及针对现有代码的部分复用的情况也比较多。

复杂界面元素、复杂动画场景的开发任务比较多。

如果这三个特点你一看就明白了，下面的解释就可以不用看了。如果你针对我的倾向愿意进一步讨论的，可以先看我下面的解释，看完再说。

同一份代码文件的作者会有很多，不同作者同时修改同一份代码的情况也不少见。因此，使用Git进行代码版本管理时出现Conflict的几率也比较大。

iOS开发过程中，会遇到最蛋疼的两种Conflict一个是project.pbxproj，另外一个就是StoryBoard或XIB。因为这些文件的内容的可读性非常差，虽然苹果在XCode5(现在我有点不确定是不是这个版本了)中对StoryBoard的文件描述方式做了一定的优化，但只是把可读性从非常差提升为很差。

然而在StoryBoard中往往包含了多个页面，这些页面基本上不太可能都由一个人去完成，如果另一个人在做StoryBoard的操作的时候，出于某些目的动了一下不属于他的那个页面，比如为了美观调整了一下位置。然后另外一个人也因为要添加一个页面，而在Storyboard中调整了一下某个其他页面的位置。那么针对这个情况我除了说个呵呵以外，我就只能说：祝你好运。看清楚哦，这还没动具体的页页面内容呢。

但如果使用代码绘制View，Conflict一样会发生，但是这种Conflict就好解很多了，你懂的。

需求变化非常频繁，产品经理一时一个主意，为了完成需求而针对现有代码进行微调的情况，以及针对现有代码的部分复用的情况也比较多。

我觉得产品经理一时一个主意不是他的错，他说不定也是被逼的，比如谁都会来掺和一下产品的设计，公司里的所有人，上至CEO，下至基层员工都有可能对产品设计评头论足，只要他个人有个地方用得不爽(极大可能是个人喜好)然后又正好跟产品经理比较熟悉能够搭得上话，都会提出各种意见。产品经理躲不起也惹不起，有时也是没办法，嗯。

但落实到工程师这边来，这种情况就很蛋疼。因为这种改变有时候不光是UI，UI所对应的逻辑也有要改的可能，工程师就会两边文件都改，你原来link的那个view现在不link了，然后你的outlet对应也要删掉，这两部分只要有一个没做，编译通过之后跑一下App，一会儿就crash了。看起来这不是什么大事儿，但很影响心情。

另外，如果出现部分的代码复用，比如说某页面下某个View也希望放在另外一个页面里，相关的操作就不是复制粘贴这么简单了，你还得重新link一遍。也很影响心情。

复杂界面元素，复杂动画交互场景的开发任务比较多。

要是想在基于StoryBoard的项目中做一个动画，很烦。做几个复杂界面元素，