Android应用架构浅析（正在输入中...)

发表于

看山是山
看山不是山
看山还是山

只谈风月，不谈代码。

写在前面

  1. 文章为原创, 作者为林帅斌，转载请注明出处：我和我的世界@iDIK.net
  2. 文章主旨为研究Android应用的架构方案思想，不细至代码。
  3. 个人水平有限，难免理解出错，望指出共同研究。

MVC

MVC是啥？

MVC是一种被Web服务器框架广泛使用而且很是成熟的架构，这种架构把一次交互逻辑划分为 视图-控制器-业务处理器 三大模块，按照这三大模块集合则把整个系统划分为了MVC三大层次, 具体功能如下

  • 视图层（V, View）：负责显示与接受用户输入，即与用户进行交互
  • 业务处理器层(M, Model)：处理业务逻辑，包括计算业务结果，与数据源交互等,并将处理结果通过渲染器等中介直接渲染至视图告知用户处理结果以及等待用户下一步交互
  • 控制器层(C, Controller)：负责调度，使视图层的输入根据意图达到相应的业务处理器

可以看得出来，其实真正在处理交互的是MV，但由于划分层，会同时存在若干个V和若干个M，所以就需要一个C来调度，更有一些复杂的逻辑，可能一个V需要调用多个M来处理，这时候C就作用巨大了。

MVC数据传递路径

像前面提到的，很多成熟的Web服务器框架都是使用MVC架构的，所以要深入研究MVC架构，建议可以考虑学习一些Web服务器，其中，CakePHP是业界比较认可的严格遵循MVC架构的框架。

Android应用原配MVC架构？

很多人，或者网上很多文章都认为Android应用原生标配的是MVC架构，对于这种说法我是有所保留的，这种说法的基本观点划分如下

  • M是业务处理层
  • V是各种XML定义的View
  • C由Activity来担当

结合上文对MVC的介绍我们来分析一下我为什么还会保留点什么：

  1. 业务处理层是主动划分出去的，这个不是Android开发要求的，淡然，这个不是重点。
  2. 视图中的V是负责交互，然而XML文件显然不具备这一功效，可以明确感知的事XML文件不是视图层，最多算得上视图层的一个组件，或者称为视图模版。
  3. 负责交互不正是Activity该干的事吗？对，所以要划分，Activity理应是V而非C。

  4. 缺少渲染器一般的角色来把M的计算结果返回给V。

    这样看来，原配MVC很可能不是真的。

在我看来，Android系统开发者原本对应用的设计就是容器化的设计，无论是Activity还是其他组件，其实都是一种容器，在这个容器内你可以运行你想要的任何代码，所以开发这些代码用到什么样的技术，Android系统开发者根本就不关注，同时还为你能快速写好应用提供了不少帮助东西，其中就包括一套XML描述的视图模版技术，这些帮助的东西仅仅是帮助你快速开发，就算你不用，也是完全可以的。

所以，要使用MVC模式开发应用不是不可以，需要我们重新去考量，去设计，而目前主流的架构主要集中在MVP和MVVM，所以这里我就不再多扯了，，

MVC@Android

MVC@Android架构图

注意：下文所提到的MVC架构将使用此方案，而非其他文章所描述的原配方案

MVP

就当前，MVC 由于被误解了 无人问津，而MVVM目前主流的实现依赖的一种在Android应用开发中仍未被广泛采纳的DataBinding而迟迟不得志，MVP可以说是风光一时无两，无愧为 最有价值玩家 。

从一则故事说起

Android应用开发有一个通病，由于无原配应用架构，所有的代码仿佛都能写在一个Activity里面便能使其跑出想要的效果，而且开发人员水平参差不齐，啥代码都往里搬，所以Activity往往都会成为一个代码黑洞。

于是大伙围着分析了一下原因，厄，，总不能说是因为我们开发水平太次了，，对，必须想另外一个理由，，

于是，一个高大上而且合理的理由就出现了：

“Activity同时控制着视图而且又处理业务，代码多是肯定的呀，维护性差是必然的”

我看了看Android系统View类中几万行的代码，心中感慨呀，不多说了

把具体业务处理逻辑M层拆出去，相当简单，拆完以后，发现Activity还是那么庞大，因为Activity还是要处理视图逻辑和业务调度逻辑，那就继续拆。

于是，把Activity的代码按照视图控制代码和业务控制代码强行拆分成两个类，一个称为V，属于是视图层，另外一个是P，即主持层，主管业务控制。

这样Activity就真的好轻啦，仅仅包含读取视图数据，弹窗提示用户等代码，再怎么写也好像没有几百行行代码。

“你们这个设计不错，代码很好，维护性很强”

而拥有几千减去几百行代码的P在一般略显疲倦。。。

不管怎么样，分三个类来写的确比写在一个类里面，可维护性要高很多，而且，还可以把P拆成多个子P，维护性又进一步提高了，有了分层分模块的概念，就可以制定开发规范，通过规范，就算水平差点的开发也不能轻易祸害全局。

于是呼，这个架构就迅速流行起来了。。。

故事归故事，MVP还是Android上很成熟的架构，特别是使用合理的时候。

MVP介绍

在MVP中，Activity以及相关的View、Fragment等都属于V，负责显示交互结果还有接受数据，所有的逻辑处理，包括控制视图的显示、清空输入框等，都交由P处理，P使用对应的M进行业务逻辑计算，监听操作结果，并回调操作V。

MVP@Android交互图

MVP主要组成：

  • 业务处理器层(M, Model)：处理业务逻辑
  • 视图层(V, View)：被动式处理交互
  • 主持层(P, Presenter)：控制视图逻辑以及调用业务逻辑
  • 接口化组件

这其中，接口化组件并非必要组件，但一般都会着重使用，以降低P与V，P与M之间的耦合度，使之能独立进行各种单元测试，这也是MVP架构津津乐道的友好测试的原因。

说句题外话，无论什么架构，或者说什么模块，都应该尽量考虑面向接口设计，只要面向接口设计了，都属于测试友好型设计。

MVP VS MVC

其实我觉得MVP并非是MVC的一个变种，二者有相似之处，但理念还是相差甚远，二者最大的相同点就是M层处理具体业务逻辑。（补充一句：这一层的划分几乎所有架构方案都持有相同的想法）另外一点相同点就是二者的V主要为Activity以及Fragment等。

下面重点说说区别：

  1. V，MVC中，拥有完整的与用户互动的权限，可以进行各种非业务相关的操作，而在MVP中，不拥有互动权限，仅仅接受用户输入，然后传递给P进行决策，并接受P的回调进行反馈。
  2. C&P，MVC中，C是调度器的作用，调度完毕不在关注后续的操作，而在MVP中，P其实是将Activity与M的交互分离封装出来，所以关注M的操作结果并回调V进行下一步操作。
  3. MVC中会有渲染器等中间件来连接M至V这一步，而MVP无需要这个中间件。
  4. 根据上述几点可以感受到二者的数据流向是不一样的，MVC中，数据是单向流动的，即 V->C->M-(渲染器)->V , 而在MVP中，数据都是双向流动的，即 V<->P<->M

区别之所以这么多是因为二者设计的理念，关注点不一样，如果摆在同一个维度去考虑，那么MVP中的VP加起来大概就等于MVC中的V，所以MVP缺少控制器去调度，而是M与VP直接交流。

从这个角度考虑，我们可以认为MVP是一个精简版的MVC架构，省略了其中的调度以及渲染过程，从而更轻巧灵活更适合移动开发，这也许是MVP流行的一大原因。

MVP的问题

  1. 原本一个Activity顶多加一个M解决的问题，现在要划分成三个类还有三个以上的接口，开发成本显著增加，反而降低了开发效率，随着项目的成长，需要管理维护数倍的代码文件，成本也在急速增加。
  2. P承担了Activity大部分的代码，如果不合理规划P，P将会是另一个代码黑洞。
  3. P主管了Activity的一些逻辑交互，迫使其也受Activity的生命周期所约束，大大增加了其开发难度。

MVP更多…

有缺陷，但大多数也有改进的方案，而且Google官方也推出了采用MVP架构的案例，可以称得上是官方非正式认证过，此外，基于MVP架构也有不少成熟的新方案，还有各种辅助开发的开源工具，所以，MVP还是值得考虑使用的。

MVVM

MVVM我是这样去理解的

说实话，关于MVVM我看了不少文章，然而在很长一段时间内我始终感觉未领悟其奥义，大多数文章都在介绍DataBinding技术，在MVVM如何运用等。

拨开实现技术，思考一下MVVM架构的核心思想： 数据

数据才是一切的根本

围绕着数据本身从新设计交互逻辑，我们就能轻松理顺这一模式：

  1. 当关注的数据改变了，界面自动相应变化并告知用户
  2. 当需要处理的数据改变了，某个东西自动处理并修正处理后的数据
  3. 数据的计算处理，由相应的业务处理器去处理

根据这样的交互逻辑，我们划分出一下几个层次：

  • V（View）：视图层，感知数据变化，并自动调整界面告知用户，并负责接收用户输入修正数据
  • M（Model）：业务逻辑处理层，处理业务
  • VM（ViewModel）：相应数据改变，调度业务逻辑层处理数据

说了这么多，好像也没提到DataBinding呀？对，在MVVM这种架构的思想中，其实DataBinding不是一个狠角色，但实现这种思想，却要依赖到DataBinding。

再说说DataBinding

何为DataBinding？翻译过来就是“数据绑定”，其实就是一种绑定数据的技术，当数据发生变化，绑定该数据的各种观察者就会获得通知，并“自动”发生变化，无需人工写代码再去操作。其实究其根本，就是这项技术底层用观测者模式，还有些自动化编写代码的技术帮我们封装了那些本该我们手动书写的代码而已矣。

正是有了这种技术，所以MVVM中，V和VM可以忽略对方的存在，只要专心的和数据好好玩耍即可，反正，对方也会感知数据的改变而改变。

MVVM的优与劣

数据是最好的协议

MVVM通过数据本身解耦V和VM，的确比MVC和MVP架构通过接口来解耦要更高明不止一点。

另外，各层的交互降到最低，几乎为0，可以专注在自身与数据的交互，而这种交互无非就是感知数据、处理数据、修正数据，各层的逻辑也会相应的清晰明了，维护性自然而然就会增强，同时也适合多人开发，实行真正的V和VM并行开发，还有一些优点我就不多说了。。。

而Google也发布了官方支持的DataBinding技术来支持这种架构的实现，也算的是官方认证的一种架构了。

然而缺点还是有的，首先，这种架构的思想理解起来要比其他的难一点，入门门槛也会高一点，其次，这种架构不太适合小项目开发，前期会使问题复杂化。还有，使用官方的DataBinding技术改变了layout文件的传统，侵入性较强，也使不少人犹豫了要不要使用该架构。

言而总之，MVVM是一种高度面向协议的架构，注定了可维护性强，十分推荐在大型项目中使用开发。

RxMV

天下武功
唯快不破
这其实是一个硬广告

无论是MVC、MVP还是MVVM，都是很成熟，业界很是认可的模式，但其实都是大型项目实践的经验，用于更注重速度的小项目无疑是有用牛刀之嫌，为此，根据我的经验以及心得，总结设计了一个适合敏捷开发的响应式架构。

未完，待续…