|
|
知识路径： > 电子商务系统程序设计基础 > 电子商务平台开发基础 > 移动端开发平台技术及其结构 > 移动端开发平台技术及其结构 > Android平台技术及其结构 >
|
|
相关知识点：4个
|
|
|
|
|
Android开发的常用框架分别为MVC（Model-View-Controller）框架、MVP（Model-View-Presenter）框架和MVVM（Model-View-ViewModel）框架，目前Google主推MVVM开发框架模式。MVC前文已有介绍，在此主要介绍MVP和MVVM框架。
|
|
|
|
（1）MVP（Model-View-Presenter）。MVP模式是目前Android系统非常流行的框架，是从MVC模式演变过来的，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。但是MVP与MVC有着一个重大的区别，如下图所示：在MVP中View并不直接使用Model，二者完全分离以减少耦合，它们之间的通信是通过Presenter（MVC中的Controller）来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过Controller。MVP大大降低了耦合度（Activity不再进行复杂的操作），层级更明显，相对MVC来说MVP更加适用于Android应用的开发。
|
|
|
|
|
|
|
|
.Model（模型）：依然是实体模型（作用与MVC相同）。
|
|
|
|
.View（视图）：在对应的Activity和XML文件中，负责View的绘制以及与用户的交互。
|
|
|
|
.Presenter（交互器／表示器）：负责完成View与Model间的交互和业务逻辑。
|
|
|
|
MVP核心是过一个抽象的View接口（IView）将Presenter与View层进行解耦。Persenter持有该View接口，对该接口进行操作，而不是直接操作View层。这样就可以把视图操作和业务逻辑解耦，从而使得Activity成为真正的View层。
|
|
|
|
虽然MVP使得Android开发变得更简单，但是也存在以下弊端：
|
|
|
|
①Presenter层与View层是通过接口进行交互的，接口粒度不好控制。粒度太小，就会存在大量接口的情况，使代码太过碎版化；粒度太大，解耦效果不好。同时对于界面UI的输入和数据的变化，需要手动调用View层或Presenter层相关的接口，相对来说缺乏自动性、监听性。
|
|
|
|
②MVP是以界面UI和事件为驱动的传统模型，更新UI都需要保证能获取到控件的引用，同时更新UI的时候还要考虑当前是否是UI线程，也要考虑Activity的生命周期。而且数据都是被动地通过UI控件做展示，但是由于数据的时变性，因此更希望数据能转被动为主动，数据能更有活性，由数据来驱动UI。
|
|
|
|
③View层与Presenter层还是有一定的耦合度。一旦View层某个UI元素更改，那么对应的接口就必须得改，数据如何映射到UI上、事件监听接口这些都需要转变。同时，复杂的逻辑业务处理也可能会导致Presenter层代码变得异常臃肿。
|
|
|
|
（2）MVVM（Model-View-ViewModel）。为了解决MPV框架结构的弊端，MVVM框架利用数据绑定（Data Binding）、依赖属性（Dependency Property）、命令（Command）、路由事件（Routed Event）等新特性打造了一个更加灵活高效的架构。Google于2016年正式推出MVVM正式库，目前的Android Studio能够很好的支持在MVVM框架下开发应用程序。
|
|
|
|
作为MVP的升级版，MVVM将Presenter改名为ViewModel（视图模型）。如下图所示，MVVM的核心思想是实现View和Model的双向绑定，当View有用户输入后，ViewModel通知Model更新数据，同理Model数据更新后，ViewModel通知View更新。
|
|
|
|
|
|
|
|
.Model（模型）：和MVP相同，基本就是实体模型（Bean），包括Retrofit的Service。ViewModel可以根据Model获取一个Bean的Observable（RxJava），然后做一些数据转换操作和映射到ViewModel中的一些字段，最后把这些字段绑定到View层上。
|
|
|
|
.View（视图）：View层实现和界面UI相关的工作，开发人员只在XML和Activity或Fragment写View层的代码。View层不做和业务相关的事，Activity不写和业务逻辑相关代码，也不需要根据业务逻辑来更新UI的代码，而更新界面UI通过Binding实现，在ViewModel里面更新绑定的数据源即可，Activity要做的事就是初始化一些控件。Activity可以更新UI，但是更新的UI必须和业务逻辑和数据是没有关系的，只是单纯的根据点击或者滑动等事件更新UI（如根据滑动颜色渐变、根据点击隐藏等单纯UI逻辑），Activity（View层）只是处理UI本身的事件，简单地说：View层不做任何业务逻辑、不涉及操作数据、不处理数据、UI和数据严格分开。
|
|
|
|
.ViewModel（视图模型）：ViewModel层做的事情刚好和View层相反，它只做和业务逻辑和业务数据相关的事，不做任何和界面UI、控件相关的事，ViewModel层不会持有任何控件的引用，不会在ViewModel中通过UI控件的引用去更新UI。ViewModel专注于业务的逻辑处理，操作也都是对数据进行操作，数据源绑定在相应的控件上会自动去更改UI，开发者不需要关心更新UI。
|
|
|
|
|
|
①数据驱动。在常规的开发模式中，数据变化需要更新界面UI的时候，需要先获取UI控件的引用，然后再更新UI。在MVVM中，这些都是通过数据驱动来自动完成，数据变化后会自动更新UI，UI的改变也能自动反馈到数据层，数据成为主导因素。这样MVVM在业务逻辑处理中只要关心数据。对于版本迭代中频繁的UI改动，更新或新增一套View即可。
|
|
|
|
②低耦合度。MVVM框架的分工是非常明确，数据是独立于UI。数据和业务逻辑处于一个独立的ViewModel中，ViewModel只需要关注数据和业务逻辑，不需要和UI或者控件打交道，即便是控件改变了（例如：TextView换成EditText），ViewModel也几乎不需要更改的。
|
|
|
|
③可复用性。一个ViewModel可以复用到多个View中。对于版本迭代中频繁的UI改动，更新或新增一套View即可。
|
|
|
|
MVVM的优点还体现在团队协作、单元测试等方面。总之，Google推进的MVVM开发框架优势非常明显，是今后Android开发框架的主要发展趋势。
|
|
|
