【轉載】如何給UIViewController瘦身

 

如何給UIViewController瘦身

 

編輯： z_zombie 來源： smileEvday的博客

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

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

iOS中最多見的一種設計模式就是MVC，但在實際開發過程當中，咱們由於這樣、那樣的緣由讓單純的ViewController變成了集Model，Controller以及View的一個大集合，這樣勢必就會致使VC的代碼容量呈幾何增加。這樣的代碼會存在如下幾個問題：

一、不利於後續維護

代碼在一個公司的存活時間一般遠長於你在公司的時間，你是否也在接手現有項目之後邊看代碼邊在內心默唸「a piece of shit」，我想沒有一我的但願以後接手你代碼的人有一天看你代碼的時候也在內心默唸着一樣的話。做爲一個有追求的程序員，或者說爲了避免被之後的同事罵，咱們必需要爲本身的代碼負責，避免動輒就是幾千行的一個源文件。你本身寫的都不肯因看，更況且後續接手的人呢。

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

二、不利於支撐UI的變更

試想若是有一天大家的App的UI風格須要改變，大量的View須要改變，在一個幾千行的VC中刪刪改改是什麼感覺。可能由於改動UI的時候一個不留神錯改了Model或者Controller的東西，致使程序都不能正常運行。並且改動的範圍不能控制在一個較小的範圍，測試迴歸起來的工做量也是很大的。

三、不利於複用

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

一般iPhone版本和iPad版本無論UI怎麼變，業務邏輯只是基本相同的，那麼若是當初咱們的代碼層級比較清晰，是否是Controller和Model層就能夠完美的複用呢，針對不一樣的版本換一套View便可，這個是否是方便多了，本身感覺一下。

2、如何解決這些問題

第一部分說了這麼多終於點題了，如何使用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分層的好處：

一、VC代碼量驟降，易於維護

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

二、複用性提升

拆分後若是App須要對UI展現進行大改，那麼你的改動基本上都會停留在View模塊中，你能夠選擇在現有的基礎上改，也能夠選擇從寫一個。只要業務不變的話，Model和VC模塊徹底不須要修改。這樣改動的範圍較小，對開發和測試都比較友好。

拆分後若是App須要支持iPad版本，那麼你須要作的就只是重寫一個View而後放進去就行了，Model和VC模塊一樣基本上不要作任何修改，想一想是否是還有點兒小激動呢。

3、總結

使用MVC模式能夠達到幫VC瘦身，能夠到到提升複用性和可維護性的效果，同時也會讓本來一個總體的業務代碼，分散到各個不一樣的地方。實際使用中咱們須要具體問題具體分析，若是一個VC中的東西自己就很簡單，那麼徹底能夠放在一塊兒，由於即便所有放在一塊兒也就幾百行代碼。例如App中常見的Copyright界面，自己就是加載一個html就搞定了，就徹底不必搞得那麼複雜；若是一個VC已經很複雜，代碼動輒幾千行了，那麼就須要拆分，達到更好的複用以及方便維護的目的。

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

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

(來源:smileEvday的博客)