Android常见架构模式-反向控制模式

我们在编写应用程序时，经常要使用代码库（Library）和框架（Framework）来完成业务功能的开发。

代码库是一组静态代码的堆砌集合，一般没有自己的状态和业务流程，代码模块之间也相对独立，应用程序在使用代码库所提供的功能时，直接调用API就行了，库都是被动的，不会参与或控制应用程序的业务流程。

框架与代码库有所不同，一般是为了解决某种通用业务而设计、开发的，有生命周期，也有相对固定的内在业务逻辑，有一定的自治行为，通常它会按照业务流程实现一些功能或者提供解决某个业务功能的流程框架，需要由外界提供环境让它运行。它有两个典型特点：一是通过扩展而不是修改框架来实现新功能（OCP原则），二是使用框架来实现功能的应用程序，它的控制流程由框架而非应用程序自己控制。

框架中有些行为是被动的，就像代码库那样，比如所提供的服务，应用层可以直接调用API；有些行为是主动的，需要框架自己根据设定的业务流程来运转。但在实际应用开发时，有一些业务场景往往是具体的，不同的应用程序有不同的业务逻辑。应用是具体的，而框架又是通用的，框架不能未卜先知，是无法知道不同应用的具体业务逻辑的，应用程序知道自己的业务逻辑，但又不能修改框架，那么为了兼顾框架的通用性和应用的具体性，框架该如何设计呢？

我们先看一下Android框架是如何实现的，以触屏事件的响应处理为例。当Android响应屏幕触碰事件时，会按照自有的处理流程来接收这个事件，分析它，然后由事件分发流程来传递事件，找到前景Activity，通过ViewGroup找到接触点所在的Widget控件，然后调用这个控件的OnXxxListener接口或者onXxxEvent()。注意，所有这些流程完全是由Android Framework自己运转的，只是到了最后，才把具体处理这个事件的具体业务逻辑（即OnXxxListener接口或者onXxxEvent()）交由应用层来实现。

显然，Android的事件分发机制处理流程是固定的、通用的，不可能也不应该是由应用层自己实现，这也正是框架的价值所在。当框架层需要应用层提供具体功能时，会预先定义接口让应用层提供，等到框架层需要的时候再主动调用这些接口，也就是著名的“don’tcall us, we’ll call you”的好莱坞原则。

这种架构模式就是所谓的控制反转模式（IOC），也就是说框架在某些地方会为应用层留出一些关键逻辑，由应用层根据具体的需求来实现，当框架按照既定的流程运行到该处时，就会主动调用由应用层所提供的方法，从而满足了具体的应用场景。

IOC模式是一种依赖倒置，也即反向调用机制。如果把应用层调用框架层代码的过程，称为正向调用的话，那么反过来，由框架层调用应用层代码的过程，就称为反向调用。也就是说框架层根据自己的流程，会在需要的时候回调应用层的代码，来实现具体业务逻辑，从应用层的角度看，相当于流程控制从自己一方转移到了框架层，相当于控制反转了。

IOC的优点是完美地兼顾了框架的通用性和应用的具体性，由框架负责不变的流程，应用负责易变的业务；缺点就是流程不容易理解、难以调试，因为是反向调用，和人的正向调用思维方式不一样，尤其是在调试代码时，不能像正向调用那样一步步的跟踪，来查找问题。

IOC模式实现的原理是，框架层负责实现通用的模板流程，应用层负责提供具体的业务逻辑。常见的实现方式有两种：

1. 继承
   框架层定义基类，在基类中实现框架的基本逻辑流程，并定义了抽象方法以供基类使用，由应用层继承该基类并override抽象方法，也就是设计模式中所谓的“模板方法模式”，显然是利用了面向对象的多态技术；

2. 委托
   框架层定义回调接口类，由应用层实现该接口类，并注册到框架层，框架层负责调用该回调接口，也就是所谓的“观察者模式”，也就是注册回调方式。

在Android中，应用IOC模式的地方有很多，比比皆是。比如最为常见的Application、Activity、Fragment、View、AsyncTask等类，它们都采用了IOC模式来设计。所实现的方式无非就是“模板方法模式”或者“观察者模式”，比如Application、Activity、Fragment类中的onXxx()等生命周期方法、View的onMeasure()、onLayout()、onDraw()、onXxxEvent()等方法，都是模板方法模式中的“钩子方法”；使用观察者模式实现的经典例子是View类，View类中常用的OnXxxListener接口，由应用层实现具体的接口添加View实例中，OnXxxListener为Observer角色，框架层为Subject角色。由于大家经常使用这些类，应该有深刻的印象，这里就不再赘述了。