如何給UIViewController瘦身

　　隨著程序邏輯復雜度的提高，你是否也發現了App中一些ViewController的代碼行數急劇增多，達到了2，3千行，甚至更多。這時如果想再添加一點功能或者修改現有邏輯變得讓人無比頭疼。如果你遇到了這類問題，那是時候停下來了，思考一下如何更好地組織代碼，給VC瘦身。本文將會闡述如何結合MVC的思想幫你的VC瘦身同時提高復用和可擴展性。

一、開發中常見的現象和缺點

　　iOS中最常見的一種設計模式就是MVC，但在實際開發過程中，我們因為這樣、那樣的原因讓單純的ViewController變成了集Model，Controller以及View的一個大集合，這樣勢必就會導致VC的代碼容量呈幾何增長。這樣的代碼會存在以下幾個問題：

　　1、不利于后續維護

　　代碼在一個公司的存活時間通常遠長于你在公司的時間，你是否也在接手現有項目以后邊看代碼邊在心里默念“a piece of shit”，我想沒有一個人希望之后接手你代碼的人有一天看你代碼的時候也在心里默念著同樣的話。作為一個有追求的程序員，或者說為了不被以后的同事罵，我們必須要為自己的代碼負責，避免動輒就是幾千行的一個源文件。你自己寫的都不愿因看，更何況后續接手的人呢。

　　如果項目進度很趕，當時沒有時間對代碼進行合理的拆分和重構，后續也一定要抽出時間來填一下自己挖的坑。你可能會說，公司一直都很忙沒有時間留給你去重構。我只能說要不就是你自己不會安排時間，要不就是這個公司只把你當代碼搬運工。站在長遠發展的角度上，要么改變自己，要么炒了老板。

　　2、不利于支撐UI的變動

　　試想如果有一天你們的App的UI風格需要改變，大量的View需要改變，在一個幾千行的VC中刪刪改改是什么感受。可能因為改動UI的時候一個不留神錯改了Model或者Controller的東西，導致程序都不能正常運行。而且改動的范圍不能控制在一個較小的范圍，測試回歸起來的工作量也是很大的。

　　3、不利于復用

　　如果你的App一開始只支持iPhone版本，所有的一切都那么自然，程序也運行的很好。突然有一天老板告訴你說公司業務發展的不錯，為了擴大市場需要退出iPad版，這個時候如果僅僅只是iPhone版本的放大版，那么你需要做的可能就是添加一些view的自適應就好了。但現實并不總是理想，如果iPad版的需要重新設計，按鈕的位置都變動了(參考上面的第二點)，這個時候難道需要把所有的代碼都改一遍？這尼瑪工作量也太巨大了吧。

　　通常iPhone版本和iPad版本不管UI怎么變，業務邏輯只是基本相同的，那么如果當初我們的代碼層級比較清晰，是不是Controller和Model層就可以完美的復用呢，針對不同的版本換一套View即可，這個是不是方便多了，自己感受一下。

二、如何解決這些問題

　　第一部分說了這么多終于點題了，如何使用MVC模式更好的給VC瘦身，提高復用性和可維護性呢？我畫了下面一個圖：

　　解釋一下上面這幅圖，一個完整的模塊被分為了三個相對獨立的部分，分別是Model，View，Controller，對應到我們App中的依次為繼承自NSObject的數據中心，承載UI展示和事件響應的View以及我們最最常用的UIViewController。

　　其中VC持有View和Model部分，View通過代理或者Target-Action的方式把用戶的操作傳遞給VC，VC負責根據不同的用戶行為做出不同響應。如果需要加載或刷新數據則直接調用Model暴露的接口，如果數據可以同步拿到，則直接使用獲取到的數據刷新View。如果數據需要通過網絡請求等其他異步的方式獲取，VC則通過監聽Model發出的數據更新(成功或失敗)通知，在收到通知時根據成功或者失敗對View進行相應的刷新操作。可以看出來整個過程中View和Model是沒有直接交互的，所有的操作都是通過VC進行協調的。

　　進過MVC分層的好處：

　　1、VC代碼量驟降，易于維護

　　可以看到拆分后VC中就僅剩下事件的響應操作了，所有顯示相關的東西都被單獨抽取出來，所有的網絡請求以及數據緩存都被提取到出去了。VC中的代碼會大幅度減少，在我們項目中的實踐結果為：拆分前一個VC的代碼行數為2600行，拆分后VC的代碼行數僅剩不到600行。

　　2、復用性提高

　　拆分后如果App需要對UI展示進行大改，那么你的改動基本上都會停留在View模塊中，你可以選擇在現有的基礎上改，也可以選擇從寫一個。只要業務不變的話，Model和VC模塊完全不需要修改。這樣改動的范圍較小，對開發和測試都比較友好。

　　拆分后如果App需要支持iPad版本，那么你需要做的就只是重寫一個View然后放進去就好了，Model和VC模塊同樣基本上不要做任何修改，想想是不是還有點兒小激動呢。

三、總結

　　使用MVC模式可以達到幫VC瘦身，可以到到提高復用性和可維護性的效果，同時也會讓原本一個整體的業務代碼，分散到各個不同的地方。實際使用中我們需要具體問題具體分析，如果一個VC中的東西本身就很簡單，那么完全可以放在一起，因為即使全部放在一起也就幾百行代碼。例如App中常見的Copyright界面，本身就是加載一個html就搞定了，就完全沒必要搞得那么復雜；如果一個VC已經很復雜，代碼動輒幾千行了，那么就需要拆分，達到更好的復用以及方便維護的目的。

　　寫了幾年代碼了，見過所有東西都往一個源文件里面塞的，也見過一個本就很簡單的東西被設計模式搞的四分五裂的，不要為了用設計模式而用設計模式。把握好度很重要，能用子彈解決的問題就不要動大炮。

　　代碼重構應該是一個持久的過程，在開發的過程中就時不時的對現有不合理的地方進行重構，而不是等待問題已經很多了才想起重構來。千里之行始于足下，千里之堤潰于蟻穴。

注：smileEvday保留本文的一切權利

　　轉載請著名原文出處

　　本文在開發過程中隨時更新，歡迎交流