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也可以進行模塊化，提高靈活性

公共工具類的建立
對于軟件內部公共的組件或者是處理，我們可以抽象一個工具類來進行處理。