动机
移动端应用随着硬件和平台能力提升, 有了日趋复杂的趋势. 而移动端的架构演化也将
影响移动端架构的一些要素有:
- 功能复杂程度, 常常来源于需求的复杂程度
- 平台的能力, 现代移动端操作系统的平台能力日趋强大
- 开发团队的规模
- 开发者的技术栈, 依赖于流行的开发技术
本文的动机主要是通过简单介绍集中移动端比较常见的框架, 来帮助读者了解并可以应用到自己的项目中.
MVC
Model-View-Controller结构应该是非常经典且古老的架构了. 百度百科上的图示有非常详细的说明:
在阮一峰的网站上, 可以找到包含用户交互的完成图示:
这里有一个需要注意的地方: View和Model是可以互相访问的.
MVP
Model-View-Presenter是MVC进化而来的. 主要功能是隔离了View和Model层,由于View和Model层可以互访, 带来了耦合.
将MVC中的Controller替换成Presenter, 隔离了Model和View, 就成为了我们看到的MVP模式.包含了用户交互的图示:
这里我们可以举个例子, 一家便利店:
- Model相当于仓库
- View相当于货架上面摆满了商品
- Presenter相当于店长,理货员和售货员
这里View也叫做被动视图, 没有任何的主动性. 在实际开发中, 系统负责交互的模块充当着上图中用户的角色.
MVVM
Model-View-ViewModel是MVP的一个变种. 基本上可以理解为将MVP的Presenter替代为ViewModel.同时引入了一个DataBinding的概念.
- Binder(DataBinding)是MVVM模式中隐含的一个概念, 是View和ViewModel存在的一种双向绑定: View中的变化会自动反应在ViewModel中, 反之亦然.
小结
在看过MVC, MVP, MVVM后, 我们简单小结一下. 这三种模式都是解答如何拆分一个应用程序这个问题的. 在实际使用中, 主要的关注点是如何拆分系统中交互逻辑 "最重" 的部分. 比如在Android上, 我们的关注点就是如何拆分Activity(Fragment), 在iOS上,则是如何拆分ViewController.
- 在Android上, 通常使用MVP, 将Activity拆分成MVP中的"View"和"Presenter", 同时"Presenter"中加入能够和Model交互的逻辑处理.
- 在iOS上, 通常使用MVVM, 将ViewController拆分成"View"和"ViewModel", 在"View"中绑定"ViewModel"中的属性.
Clean Architecture
Clean Architecture的结构很像一颗洋葱, 其分层原则: 里面的层是永远不知道外层的.
需要先理解几个概念:
- Entities
应用程序的业务对象 - Use Cases(Interactors)
业务逻辑 - Controllers/Presenters(Interface Adapters)
控制层, 决定何种输入需要处理 - External Infertfaces(Frameworks and Drivers)
外界环境的抽象, 比如说UI, frameworks, 数据, 网络连接等
一个比较直观的图示如下:
还可以结合下图理解:
可以参考下面两个Repo上的代码进行理解:
- Android-CleanArchitecture
-
android-clean-architecture-boilerplate
还有两篇文章帮助理解: - Clean Architecture: Use case containing the presenter or returning data?
两个实例代码其实各有不同, 而且Clean架构其实有MVP和MVVM的影子, 但是一个核心点在于: 数据的流动和层级间的依赖是单项的, 也就是说, 在Clean架构中, 不存在回环的情况, 这一点也是这个架构的优越之处.
VIPER
- View
用户的交互传给Presenter, 根据Presenter的要求展示画面 - Interactor
业务逻辑 - Presenter
负责从Interactor处取得数据给View展示, 同时负责通知Router画面跳转 - Entity
Interactor所使用的数据对象 - Router
画面跳转和展示逻辑, 在实际实现中, Router常常还承担着创建View, Presenter和Interactor.
总结
综上可以看出, 所有的架构设计都在完成一件事:
合理的分配各个组件的负担, 避免过轻或者过重. 同时避免耦合, 使得模块或者层级内部就可以自成体系, 减少对外部的依赖.
移动应用架构的演进过程就是根据研发团队的人员架构选择一个合理的,能够有效协作模式的过程. 随着团队架构变化, 可能程序架构也需要随之升级变化.
