Android换肤功能设计与实现（4）——控制层设计与实现

    根据Android本身的特性来说，我们可以这么说，其系统标准的控制层是Activity，为什么这么说那，从Activtiy的生命周期入手来简单说明一下：什么叫做控制层那，我们知道控制层就是连接View表现层，与Model模型层的部分，主要实现各种交互，这里的交互是广义的交互，对于一个APP来说，包括两部分，与人的交互，与系统环境的交互。对Activity来说，同样要从这两个角度来说明。

    与人的交互主要指的是APP接受用户的点击操作，改变相关的界面显示，通过界面的不同的变化，提示用户当前的APP状态，而一步步实现与用户的交互。其实通过APP与人的交互的简单定义我们就可以知道，与人的交互的主体其实就是界面，也就是View。这就是为什么各种交互都是以View为核心。这就是目前广泛使用的SDK设计方式。将所有与用户的交互绑定在View上。我们可以通过View所实现的接口来说明这种设计思路，View实现了与用户进行交互的所有的接口，点击、拖拽、手势等等。从面向对象的角度很好理解这种设计思路，毕竟与用户进行交互的最小个体就是APP界面上的一个个View。当然，SDK为了更方便的、快速的开发应用，抽象出了各种控件，如Button、Switch、ListView......等等，通过对View的集成形成ViewGroup，抽象出各种布局类型LinearLayout、RelativeLayout、FrameLayout等，（我们在这里只从交互的角度来说这个问题，在后面的说明中，会从绘制的角度来说明。）从交互的角度来说，可以这么来理解，各种控件的主要功能是提供进行交互过程中标准的界面变化的一种抽象；如Button、Switch、等等，对于这些控件来说，其主要目的是实现标准的交互外观，标准的交互响应。如Button的正常、按下、选中的不同的外观，Switch在开关状态下不同的表现等等。控件符合与用户交互的标准界面响应。而ViewGroup则更关注于界面的整体布局，ViewGroup为交互提供的是View的父子关系树，提供了交互事件如Touch事件的通知树，通过View的层次关系来管理对交互事件的响应。归根结底来说，不管是控件还是ViewGroup都是对View的一个扩展，不管是控件所强调的界面变化，还是ViewGroup所偏重的交互事件的前敌，都是与人交互的两个方面的强调。

    在开发Android换肤功能过程中，对控制逻辑的设计，就是通过上述思想，以Fragment为基础，对整个功能界面进行划分，对不同界面的控制逻辑进行分别的设计。这样可以有效避免对Activity的过度依赖，以及Activity逻辑上的过度臃肿；应该说Fragment是Android为开发比较大型应用而设计的子控制层。通过Fragment实现基于小界面的与用户的交互及与系统的交互，而实现控制层的主要工作。

    在设计控制层过程中，除了以各个子界面为基础而设计、实现的Fragment之外，在设计控制层逻辑时，需要考虑的是将逻辑较复杂的模块尽量独立出来。这里根据具体应用的特点，主要将Menu,ActionBar部分独立为单独的一类，专门负责ActionBar、MENU的交互及界面变化。在控制层设计中，同样需要考虑的就是与系统其它模块的交互，将这部分尽量集中在一起，通过接口模式访问系统资源，接收系统的广播。最后实现为两个类，SystemFacade负责访问系统下载管理器，及与下载管理器相关的交互动作，ThemeReceiver负责系统发出的广播接收与响应。

    上面基本对控制层设计过程中，的设计思路，及在新版本Android系统中如何利用新特性，新功能尽量设计出简单、稳定的控制层逻辑。如果为老版本的Android系统应用设计相应控制层，完全可以将对新特性的使用自己创建一类，单独进行管理，这里主要利用的是Fragment的设计思路，即将控制逻辑以不同的界面为主要交互对象，分别独立为不同的控制模块，进行一一实现，在Activity中对各模块进行综合管理。设计、实现控制层的主要目标就是逻辑简单、结构清新、耦合度尽量低（可以将耦合的部分集中在一个类中，如Activity就是一个很好的耦合类，将表现层、模块层的主要访问接口都集中在Activity中）。