①现行中Android MVC模式
优点:
- 代码与设计书的匹配度更高,易于理解,不同级别的程序员更容易中途参加到项目开发中来。
-
现行有e*Bank项目中,将耗时的数据处理逻辑交给异步task处理,缓解Activity的压力,在这些异步task中只要关心当前task要做什么,入力是什么,出力是什么。在Activity中只需要调用异步的execute方法来执行异步任务,回调时处理异步结果,Activity关心的只是总体的业务流。
缺点:
- 现在使用的XML,Activity,Model模式其实就是传统意义上的MVC模式,其中Activity(Fragment, Adatper)做的事情包括了View(用setText,setVisible等方式来控制画面),和Controller(控制业务逻辑,和Model交互的操作)。这样使Activity越来越大,导致FatActivity形成。
- 类的职责分类不明确,V和C的耦合严重。
- 在项目的扩展性方面也很欠缺,例如,当你需要将画面上的TextView修改成EditText时,需要修改XML以及Activity对控件的引用。
- Adapter适配器们在管闲事:它们应该只负责View的那些事儿。比如:判断入出金Flag,if出金,then字体颜色为绿色,if入金,字体颜色为红色。再比如:判断口座状态,显示不同的badge,显示不同的银行卡背景颜色。getView越写越大,逻辑越写越多。
关于Adapter我的想法:
- 如果ListView等的item异常简单,尽量使用ArrayAdapter,SimpleAdapter,而不是随意创建继承BaseAdpater的新类。
- getCount,getItem,getItemId这种每个Adapter中内容都一样的处理可以提取到抽象类中。
- 在需要调用NotifyDataSetChanged时,请考虑,是否想要重绘所有的可见View,如果不是,最好创建一个单独更新某一个Item的方法updateItemView(int postion)。
- getView方法,在每次滑动时,将不可见item移入我们的视野的时候会被调用到,所以在getView中做了业务的判断,对性能是有所影响的。来回的滑动,虽然利用了ViewHolder来降低内存开销,但是反反复复的判断逻辑也未尝不可避免。
②MVVM:[Model View ViewModel]
View | 对应于Activity和xml,负责View的绘制以及与用户交互。 View层不做任何业务逻辑、不涉及操作数据、不处理数据、UI和数据严格的分开。 |
Model | 实体模型层 ViewModel 可以根据Model 获取一个Bean的Observable<Bean>( RxJava ),然后做一些数据转换操作和映射到ViewModel 中的一些字段。 |
ViewModel | 负责完成View于Model间的交互,负责业务逻辑 ViewModel 只做和业务逻辑和业务数据相关的事,不做任何和UI、控件相关的事,ViewModel 层不会持有任何控件的引用,更不会在ViewModel中通过UI控件的引用去做更新UI的事情。 |
- 利用谷歌提供的DataBinding,实现数据的单向绑定和双向绑定。
- MVVM Light Toolkit是一个Android MVVM 轻量级工具库https://www.jianshu.com/p/43ea7a531700
- 关于DataBinding讲解 点我,推荐ObserveField的方式,双向绑定。点我
- POJO和JavaBean有差异
//POJO public final String firstName; public final String lastName; public User(String firstName, String lastName) { this.firstName = firstName; this.lastName = lastName; }
//JavaBean public class User { private final String firstName; private final String lastName; public User(String firstName, String lastName) { this.firstName = firstName; this.lastName = lastName; } public String getFirstName() { return this.firstName; } public String getLastName() { return this.lastName; } }
优点:
- ViewModel:绝对不持有UI的引用,不考虑UI的变化,只专心处理数据,准备数据。onClick等UI listener不在这里管理。耦合度很低。
- 可复用性:一个View Model复用到多个View中,同样的一份数据,用不同的UI去做展示,对于版本迭代频繁的UI改动,只要更换View层就行。
- 单元测试:View Model里面是数据和业务逻辑,View中关注的是UI,这样的做测试是很方便的,完全没有彼此的依赖,不管是UI的单元测试还是业务逻辑的单元测试,都是低耦合的。
缺点:
-
View:在XML中会出现过多的UI判断控制的逻辑代码(比如:android:visibility="@{user.status == 1 ? View.VISIBLE : View.GONE}"),这也是一种程度上的代码倒退,如同在jsp中写了一大堆java逻辑。如果UserBean属于一个Model对象,那么新增一个ModelAdapter对Model的值进行有利于View展示的改造,那么上述问题可以避免。
-
DataBinding框架提供的不够全面,ListView等处理可能存在欠缺。
-
类和方法会增加:新建一个空的工程,统计打开 build.gradle 中 Data Binding 开关前后的 apk 文件中类数量和方法数量,类增加了 120+,方法数增加了 9k+(开启混淆后该数量减少为 3k+)。
③MVP:[Model View Presenter展示器]
View | 对应于Activity和xml,负责View的绘制以及与用户交互 |
Model | 实体模型 |
Presenter | 负责完成View于Model间的交互和业务逻辑 |
- 主要依靠创建接口达到目的。
- Android Architecture Components
- 用谷歌提供的应用架构库来处理本地SQLite的事情android.arch.persistence.room
- 由于Presenter持有View的对象引用,当Activity销毁时,如果Presenter还在做异步后台任务,那么响应时需要使用View做一些画面展示时,会出现内存泄漏问题。在Presenter中做一个onDestroy方法用来销毁View的引用,并且在Activity的生命周期中调用。同时回调回来之后需要注意防止View的空指针异常。
- 与MVC相比同样带来一个问题,和设计书的匹配难度加大了。因为设计书没有按照职能单一的方式去设计。
- 谷歌官方提供的MVP架构示例
缺点:
- Activity需要实现各种跟UI相关的接口,同时要在Activity中编写大量的事件,然后在事件处理中调用presenter的业务处理方法,View和Presenter只是互相持有引用并互相做回调,代码不美观。
- 这种模式中,程序的主角是UI,通过UI事件的触发对数据进行处理,更新UI就有考虑线程的问题。而且UI改变后牵扯的逻辑耦合度太高,一旦控件更改(比较TextView 替换 EditText等)牵扯的更新UI的接口就必须得换。
- 复杂的业务同时会导致presenter层太大,无法避免代码的臃肿问题。
④VIPER:[View Interactor交互器 Presenter展示器 Entity Routing]
故事背景:MVP中的presenter变成了一个方法超多的庞大的类,使得它很难维护和理解。因为它要负责许多事情:处理UI事件,UI逻辑,业务逻辑,网络和数据库查询。这违背了单一职责原则,而 VIPER 可以解决这个问题,从根本上遵循了单一职责原则。
View 视图 | |
Interactor 交互器 | 只负责业务逻辑和获取来自数据库和 API 的数据 |
Presenter 展示器 | UI 事件处理以及为 View 准备来自Interactor的数据之类的事情 |
Entity 实体 | |
Routing 路由 |
[参考URL]
- 【Google提供】:MVVM, MVP等架构的示例代码参照如下
- https://github.com/googlesamples/android-architecture
- Android开发架构选择MVP or MVVM
- https://www.jianshu.com/p/2fbb3fc84449
- 如何构建Android MVVM应用程序:简书
- https://www.jianshu.com/p/2fc41a310f79
- 更多精彩博客汇总
- https://www.jianshu.com/p/1f21e1d375aa
- The Clean Architecture :
- https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
- 一种更清晰的Android架构 :
- https://zhuanlan.zhihu.com/p/20001838
- Android-CleanArchitecture :
- https://github.com/android10/Android-CleanArchitecture
- 给 Android 开发者的 RxJava 详解 :
- http://gank.io/post/560e15be2dca930e00da1083
- 浅谈 MVP in Android :
- http://blog.csdn.net/lmj623565791/article/details/46596109
- VIPER英文博客
- https://cheesecakelabs.com/blog/using-viper-architecture-android/
- VIPER英文博客译文博客
- http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2017/0329/7754.html