控制器，是MVC中的一环，也是手机软件开发中最需要注意的地方，对它的认识不清晰会导致业务层代码的结构混乱，耦合性高。经常见一些进行了几年的老项目代码，如果不是经常的迭代重构，维护起来会非常痛苦。今天重点说一下怎么化解这个问题。

其实，每个平台都对Controller有很清晰的描述和定义，只不过我们在使用中容易自己乱了阵脚，而最终导致自己难受罢了。像Android中的Activity、Fragment，IOS中的ViewController，都定义了明确的生命周期自管理方法，供开发者使用。我们只需要把这些生命周期方法当入口，驱动自己的代码就好了。在使用过程中下面几个注意事项多多注意，你的代码会很纯洁的。

1、Controller绝对不要对外暴露方法，不要让其它C可以通过函数调用的方式操作自己。

这个是严重破坏Controller生命周期自管理的行为，必须禁止。对一个C来说，接受外部C的启动参数并启动，加入到系统的C管理器之后，就不能接受任何其它C的驱动了。如果确实需要通信，请使用消息。

2、消息通信。

这个应该必须被当作是C之间进行通信的唯一手段，因为只有它是不干涉C的运行的，由目标C自己决定是否接收消息，接收了消息之后如何处理。一个Ca启动另一个Cb，或者在Cb运行期间，Ca向Cb发送消息。Activity、Fragment中的Intent，ViewController中的Notification，这些都是多少天然的组合。

3、当Controller之间有共性的时候，我们肿么办？

这其实是个Has-a，还是Is-a的问题。我用近10年的编码经验告诉大家，一定要选择Has-a，这个基于几点，一个是业务多变化，今天的共性明天可能就不存在了，今天有3个，明天就可能变成2个，选择Is-a这种强关联，会很痛苦的。另外，业务层的开发往往是几个人几杆枪，任务分开各干各的，Has-a是最合适的，把关键的公共小模块做好，其它的自由发挥去吧。不要把眼睛紧盯在那几行重复的代码上面。

4、页面太多，Controller之间跳转混乱，怎么破？

这个其实是表象。首先，我们做好上面3点之后，C之间的耦合性问题已经不存在，接下来我们再规范一下C之间进行跳转时的传参规则，参数由目标C来定义自己需要接收的数据格式。想跳到哪个页面时，找到它的源码，看下它定义的参数规则，按它的要求传过去，然后把生成的新C交给系统的C管理器就好了。在Android中是startActivity，commitFragment，IOS中是presentViewController。

5、关于页面开放。是否使用PageLink？

这个要避免走向极端。如果你的页面需要开放给第三方应用，毫无疑问，PageLink是最好的选择。因为这些页面一般都是核心页面，稳定性高，数量少，参数少，一个URI可以很清晰表达出来。像电端类的宝贝详情，SNS类的个人主页、日志详情等。那对于内部页面之间的跳转呢？这个要慎用。内部页面数量多，参数多变，数据结构复杂多样，随着业务的变化还会不断更新。每次跳转前把数据结构压成URI，通过分发中心传递给目标C之后再反序列化，校验参数合法性。每次参数有变化再调整，你累不累？

好了，今天先聊这么多，各位有什么更好的想法或者不同意见欢迎交流，一起提高。