UIViewController的误用

分类：设计模式作者：佚名

转自:http://www.onevcat.com/2012/02/uiviewcontroller/

什么是UIViewController的误用

UIViewController是iOS开发中最常见也最重要的部件之一，可以说绝大多数的app都用到了UIViewController来管理页面的view。它是MVC的核心结构和桥梁构成，可以说UIViewController是绝大多数开发者所花时间最多的部分了。
但是正是这样一个重要的类却经常被误用，从而导致app的不稳定，莫名奇妙的bug甚至无法通过appstore的审查。最常见和最可怕的误用在于在一个UIViewController里加入本来不应该由它管理的其他UIViewController，也即违反了Apple在开发者文档中关于UIViewController的描述：

Each custom view controller object you create is responsible for managing all of the views in a single view hierarchy. In iPhone applications,the views in a view hierarchy Traditionally cover the entire screen,but in iPad applications they may cover only a portion of the screen. The one-to-one correspondence between a view controller and the views in its view hierarchy is the key design consideration. You should not use multiple custom view controllers to manage different portions of the same view hierarchy. Similarly,you should not use a single custom view controller object to manage multiple screens worth of content.

一个ViewController应该且只应该管理一个view hierarchy，而通常来说一个完整的view hierarchy指的是整整占满的一个屏幕。而很多app满屏中会有各个区域分管不同的功能，一些开发者喜欢直接新建一个ViewController和一套相应的View来完成所要的功能（比如我自己=_=）。虽然十分方便，但是却面临很多风险..

一般来说，只要你的代码中含有类似这样的语句，那你一定是误用UIViewController了

[Crayon]
viewController.view.bounds = CGRectMake(50,50,100,200);
[viewController.view addSubview:someOtherViewController.view];
[/Crayon]

这样的代码可能导致莫名的bug，也会令接手的开发者无所适从。

小题大做吧，这样用会有什么问题呢

一个很麻烦的问题是，这将会导致你的app在不同的iOS版本上有不同的表现。在iOS5之前，能够对viewController进行管理的类有UINavigationController，UITabBarController和iPad专有的UISplitViewController。而在iOS5中加入了可自定义的ViewControllers的容器。由于新的SDK的处理机制，iOS4前通过addSubview加到当前controller的view上的view的呈现，将不会触发被加入view hierarchy的view的controller的viewWillAppear:方法。而且，新加入的viewController也不会接收到诸如didReceiveMemoryWarning等委托方法，而且也不能响应所有的旋转事件！而iOS5中由于所谓的custom container VC的出现，上述方法又能够运行良好，这导致了同样代码在不同终端产生不同的行为，为之后的维护和进一步开发埋下了隐患。另外，用这样的方法所添加的viewController显然违背了Apple的本意，它的parentViewController，interfaceOrientation显然都是错误的，有时候甚至会出现触摸事件无法响应等严重问题。


好吧，那我们要怎么办

如果你已经在一个app里这样误用了大量的viewController，那可能的办法也许是尽力去自行处理各种非正常的状况，比如在addSubview之后手动调用加入的vc的viewWillAppear:，以及在收到didReceiveMemoryWarning后顺次调用子VC的didReceiveMemoryWarning(显然都是很蛋疼的做法啊)。但是需要注意的是iOS5中这些方法的调用似乎是没有问题的（至少我测试是这样），因此需要对不同版本系统进行分别处理。可以用UIDevice的方法确定运行环境的系统版本：

// System Versioning Preprocessor Macros

#define SYstem_VERSION_EQUAL_TO(v) ([[[UIDevice currentDevice] systemVersion] compare:v options:NSNumericSearch] == NSOrderedSame)
#define SYstem_VERSION_GREATER_THAN(v) ([[[UIDevice currentDevice] systemVersion] compare:v options:NSNumericSearch] == NSOrderedDescending)
#define SYstem_VERSION_GREATER_THAN_OR_EQUAL_TO(v) ([[[UIDevice currentDevice] systemVersion] compare:v options:NSNumericSearch] != NSOrderedAscending)
#define SYstem_VERSION_LESS_THAN(v) ([[[UIDevice currentDevice] systemVersion] compare:v options:NSNumericSearch] == NSOrderedAscending)
#define SYstem_VERSION_LESS_THAN_OR_EQUAL_TO(v) ([[[UIDevice currentDevice] systemVersion] compare:v options:NSNumericSearch] != NSOrderedDescending)
[/Crayon]

在合适的时机判定判定系统版本，手动调用对应方法：

if (SYstem_VERSION_LESS_THAN(@“5.0”))
{ //viewWillAppear或didReceiveMemoryWarning或其他
} [/Crayon]

显然，这样的代码既非优雅亦难维护，而且随着iOS版本的更新，谁也不知道这段代码之后会不会有什么问题，无形中增加了开发成本。

真正的解决之道

当然是严格遵守Apple提供的设计规范，每个VC管理一个view hierarchy。在设计的时候，永远记住你的view和view controller都需要重用，而不恰当的使用view controller会导致重用性大打折扣。而通用的view有时也需要一个类似controller的东西来管理它的subview的行为，或者做出某些相应，这个时候我们不妨想一想一些Apple写的经典的view是如何实现的，比如UITableView和UIPickerView，依靠protocol的各种方法进行配置。
作为自定义的view的controller应当是直接继承自NSObject的类，而不应该是UIViewController。一个UIViewController可以包含若干个这样的controller来控制一个view中的不同部分的功能实现，而对于对应的自定义view是代码写的还是nib出来的就无所谓了。当然，如果是新接触iOS开发的话，我个人不建议使用Interface Builder，除非你确实清楚IB到底在背后为你做了什么。在当你完全清楚之后，IB确实能极大提升开发效率（特别是在Xcode4以后），但是如果你的对IB和view加载连接的概念如同毛线团的话，IB的使用只会让你以及让你的同事茫然失措。

在iOS5中提供了所谓的container of View Controllers，有兴趣的童鞋可以参看WWDC 2011的Session 102 – Implementing UIViewController Containment(需要一个野生开发者账号)

一些资料

作为iOS开发者，Apple的关于UIViewController的文档以及开发者的一些讨论是必读的，简单整理如下：


版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。

相关推荐

迭代器模式（Iterator）
迭代器模式（Iterator）迭代器模式（Iterator）[Cursor]意图：提供一种方法顺序访问一个聚合对象中的每个元素，而又不想暴露该对象的内部表示。应用：STL标准库迭代器实现、Java集合类型迭代器等模式结构：心得：迭代器模式的目的是在不获知集合对象内部细节的同时能对集合元素进行遍历操作
高性能IO模型浅析
高性能IO模型浅析服务器端编程经常需要构造高性能的IO模型，常见的IO模型有四种：（1）同步阻塞IO（BlockingIO）：即传统的IO模型。（2）同步非阻塞IO（Non-blockingIO）：默认创建的socket都是阻塞的，非阻塞IO要求socket被设置为NONBLOCK。注意这里所说的N
策略模式（Strategy）
策略模式（Strategy）策略模式（Strategy）[Policy]意图：定义一系列算法，把他们封装起来，并且使他们可以相互替换，使算法可以独立于使用它的客户而变化。应用：排序的比较方法、封装针对类的不同的算法、消除条件判断、寄存器分配算法等。模式结构：心得：对对象（Context）的处理操作可
访问者模式（Visitor）
访问者模式（Visitor）访问者模式（Visitor）意图：表示一个作用于某对象结构中的各元素的操作，它使你在不改变各元素的类的前提下定义作用于这些元素的新操作。应用：作用于编译器语法树的语义分析算法。模式结构：心得：访问者模式是要解决对对象添加新的操作和功能时候，如何尽可能不修改对象的类的一种方
命令模式（Command）
命令模式（Command）命令模式（Command）[Action/Transaction]意图：将一个请求封装为一个对象，从而可用不同的请求对客户参数化。对请求排队或记录请求日志，以及支持可撤消的操作。应用：用户操作日志、撤销恢复操作。模式结构：心得：命令对象的抽象接口（Command）提供的两个
生成器模式（Builder）
生成器模式（Builder）生成器模式（Builder）意图：将一个对象的构建和它的表示分离，使得同样的构建过程可以创建不同的表示。 应用：编译器词法分析器指导生成抽象语法树、构造迷宫等。模式结构：心得：和工厂模式不同的是，Builder模式需要详细的指导产品的生产。指导者（Director）使用C
设计模式学习心得
设计模式学习心得《设计模式：可复用面向对象软件的基础》一书以更贴近读者思维的角度描述了GOF的23个设计模式。按照书中介绍的每个设计模式的内容，结合网上搜集的资料，我将对设计模式的学习心得总结出来。网络上关于设计模式的资料和文章汗牛充栋，有些文章对设计模式介绍生动形象。但是我相信“一千个读者，一千个
工厂方法模式（Factory Method）
工厂方法模式（Factory Method）工厂方法模式（Factory Method）[Virtual Constructor]意图：定义一个用于创建对象的接口，让子类决定实例化哪一个类，使一个类的实力化延迟到子类。应用：多文档应用管理不同类型的文档。模式结构：心得：面对同一继承体系（Produc
单例模式（Singleton）
单例模式（Singleton）单例模式（Singleton）意图：保证一个类只有一个实例，并提供一个访问它的全局访问点。应用：Session或者控件的唯一示例等。模式结构：心得：单例模式应该是设计模式中最简单的结构了，它的目的很简单，就是保证自身的实例只有一份。实现这种目的的方式有很多，在Java中
装饰者模式（Decorator）
装饰者模式（Decorator）装饰者模式（Decorator）[Wrapper]意图：动态的给一个对象添加一些额外的职责，就增加功能来说，比生成子类更为灵活。应用：给GUI组件添加功能等。模式结构：心得：装饰器（Decorator）和被装饰的对象（ConcreteComponent）拥有统一的接口
抽象工厂模式（Abstract Factory）
抽象工厂模式（Abstract Factory）抽象工厂模式（Abstract Factory）[Kit]意图：提供一个创建一系列相关或相互依赖对象的接口，而无须指定他们具体的类。应用：用户界面工具包。模式结构：心得：工厂方法把生产产品的方式封装起来了，但是一个工厂只能生产一类对象，当一个工厂需要生
桥接模式（Bridge）
桥接模式（Bridge）桥接模式（Bridge）[Handle/Body]意图：将抽象部分与它的实现部分分离，使他们都可以独立的变化。应用：不同系统平台的Windows界面。模式结构：心得：用户所见类体系结构（Window派生）提供了一系列用户的高层操作的接口，但是这些接口的实现是基于具体的底层实现
适配器模式（Adapter）
适配器模式（Adapter）适配器模式（Adapter）[Wrapper]意图：将类的一个接口转换成用户希望的另一个接口，使得原本由于接口不兼容而不能一起工作的类可以一起工作。应用：将图形类接口适配到用户界面组件类中。模式结构：心得：适配器模式一般应用在具有相似接口可复用的条件下。目标接口（Targ
组合模式（Composition）
组合模式（Composition）组合模式（Composition）意图：将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。应用：组合图形、文件目录、GUI容器等。模式结构：心得： 用户（Client）通过抽象类（Component）提供的公用接口统一
原型模式（Prototype）
原型模式（Prototype）原型模式（Prototype）意图：用原型实例制定创建对象的种类，并且通过拷贝这些原型创建新的对象。应用：Java/C#中的Clonable和IClonable接口等。模式结构：心得：原型模式本质上就是对象的拷贝，使用对象拷贝代替对象创建的原因有很多。比如对象的初始化构
什么是设计模式？Design pattern--和生活结合更好理解
什么是设计模式一套被反复使用、多数人知晓的、经过分类编目的、代码 设计经验 的总结；使用设计模式是为了 可重用 代码、让代码 更容易 被他人理解、保证代码 可靠性；设计模式使代码编制  真正工程化；设计模式使软件工程的 基石脉络， 如同大厦的结构一样；并不直接用来完成代码的编写，而是 描述 在各种不同情况下，要怎么解决问题的一种方案；能使不稳定依赖于相对稳定、具体依赖于相对抽象，避免引
面向对象设计原则一——单一职责原则
单一职责原则定义（Single Responsibility Principle，SRP）一个对象应该只包含 单一的职责，并且该职责被完整地封装在一个类中。Every  Object should have  a single responsibility, and that responsibility should be entirely encapsulated by t
十分钟理解Java中的动态代理----强烈推荐
动态代理和CGLib代理分不清吗，看看这篇文章，写的非常好，强烈推荐。原文截图*************************************************************************************************************************原文文本************
适配器模式-让不兼容的接口得以适配
适配器模式将一个类的接口转换成客户期望的另一个接口，使得原本接口不兼容的类可以相互合作。
策略模式-定义一个算法族
策略模式定义了一系列算法族，并封装在类中，它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。
pythonJavaScriptjavaHTMLPHPreactjsC#AndroidCSSNode.jssqlrpython-3.xMysqLjQueryc++pandasFlutterangularIOSdjangolinuxswifttypescript路由器JSON路由器设置无线路由器h3c华三华三路由器设置华三路由器电脑软件教程arraysdocker软件图文教程Cvue.jslaravelspring-boot