【转载】如何给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的博客)