view层架构是最贴近业务的底层架构，view层的架构会直接影响业务方的迭代周期。
如果您的迭代周期有些慢试着看看您的view层是否符合以下：
1 代码换乱不堪
2 模块化程度不够高，组件细粒度不够
3 过多的继承导致复杂的依赖关系
如果符合试着修改以下您的view层的设计也许会有不错的效果

本文主要讲的内容：
1 view的代码结构的规定
2 view的布局
3 nib和code实现的优劣
4 MVC和MVVM
5 子视图的模块化
6 公共工具类的建立

View的代码结构的规定
view层代码规范的重要性在于：
1 提高业务方view层代码的可读性和可移植性
2 确保代码合理的传承性
3 防止业务方对代码架构的腐蚀

下面是我所经手项目viewController里的代码的结构：

pragma mark - lifeCycle - Method -

pragma mark - eventResponse - Method -

pragma mark - customDelegate - Method -

pragma mark - notification - Method -

pragma mark - privateMethods - Method -

pragma mark - objective-cDelegate - Method -

pragma mark - getters and setters - Method -

基本要点如下：
在lifeCycle 分区书写系统的生命周期的方法
在viewDidLoad做addSubViews和loadData，监听一些事件之类，在 getter方法内部进行属性子视图的初始化之类的事情。在viewWillAppear更新子视图的布局的变化。

eventResponse区域
所有button、gestureRecognizer的响应方法都要放在这里边。

customDelegate区域
所有的自定义的代理方法都要放在这里边。（每一个delegate都把对应的protocol名字带上）

notification区域
所有的观察者的和通知的方法放在这个分区。

privateMethods区域
一般用户自己定义的不属于其他区域的方法放在这里边。

objective-cDelegate区域
oc系统的代理方法存放在这个区域。（每一个delegate都把对应的protocol名字带上）

getters and setters区域
所有的getter and setter方法放在此区域并且要放在最后。（如果getter和setter写在前面，就会把主要逻辑扯到后面去，这样代码的可读性会变差）

以上为viewController内部的代码结构，关于一个项目的代码的详细规范会单开一章此处不在详述。

view的布局
采用frame很难看出每个子视图之间的位置关系，采用Autolayout生成的代码观感不好，这里推荐采用轻量级的Masonry。

view层 采用何种方式展现？
xib和code实现的优劣
xib的优势：
1 节省开发时间，避免大量的代码。
2 可以让开发者直接看到界面便于调整。
xib的劣势：
1 不管是git还是svn管理代码，xib容易发生冲突并且不易解决
2 xib设置的像素值展现出来有时会失真
3 风格相同的组件不能复用
4 复杂的界面不便于修改

code的优势：
1 可以灵活性布局
2 代码便于管理即使产生冲突也便于修改
3 风格相同的组件可以复用
4 代码可以复用，便于模块化
5 可以很灵活的修改，可读性好
code的劣势：
代码量较大

在一个项目中可以xib和code结合使用：
复杂的、动态生成的、需求经常变动的界面、 大量风格相同的组件建议使用code完成。
简单的、静态的、并且功能不是核心的界面可以采用 xib 或 storyboard 来完成。

View层采用乃至整个项目采用哪一种模式？
设计模式都是对数据管理者、数据加工者、数据展示者之间怎样进行数据交换做出的规定。
在iOS中MVC（Model-View-Controller），其中model是数据管理者，view是数据展示者，controller为数据加工者。model和view都是由controller根据业务需求调配。

在iOS中Controller会生成一个view实际这个view是一个容器，负责对子视图的长相，UI进行处理。所以在ios中mvc为(model-view-(controller + viewContainer))。在iOS中都是把事件回传给controller，由controller控制容器内容发生变化展现不同的view。

iOS中MVC分工：

Model
给viewController提供数据，并提供存储数据和请求的接口。
提供抽象的业务组件，供controller调度。

Controller
管理view容器的生命周期并给view容器内放入内容。
监听view容器的事件并调度view容器和model进行处理。

View
展现界面元素并响应与业务无关的事件。

MVVM
随着app的增长Controller内部的代码会变的膨胀切难以维护。为了给controller代码减负我们在MVC中采用胖model方案，在胖model方案的基础上发展出MVVM设计模式。因此变为model-viewmodel-controller-view，在iOS的mvvm中依然需要controller的参与。实际上viewModel依然属于model层只不过为了处理共同的弱业务逻辑而抽象出来的一个层。

采用mvc会造成Controller代码的膨胀，采用mvvm会很好的避免这一点。

子视图的模块化
1 对于复杂的view界面，可以把每一个子视图展现的元素和响应的事件模块化
2 对于相同风格的cell也可以进行模块化，提高灵活性

公共工具类的建立
对于软件内部公共的组件或者是处理，我们可以抽象一个工具类来进行处理。