http://www.it165.net/pro/html/201505/41758.html
-
这篇文章是我学习MVP模式时翻译的,原文是Konstantin Mikheev所写,传送门。
因英语水平有限,翻译的很生硬,基本靠Google,请见谅。以下是译文。
这篇文章我会通过一个最简单的例子去一步步介绍MVP模式在Android中的最佳实践。同时我也会介绍一个使MVP模式在Android开发中变简单的library。
简单?怎么才能从中获益呢?
什么是MVP
View层是用来显示数据和相应数据操作的。在Android中,它可能是Activity,Fragment,View或者Dialog。
Model层是数据访问层,例如数据库API或者远程服务器访问API。
Presenter层提供View层和Model层的数据进行联系。Presenter层也可以控制后台Task。
在Android中,MVP模式可以把后台线程从Activitys/Views/Fragments中脱离出来,使它们在大部分生命周期事件中更加独立。这样的应用变得更加简单,整个程序的稳定性提升了10倍不止,应用代码变得更加少,代码可维护性变得更加友善,开发者的生命变得更加开心。
在Android中,为什么是MVP
原因1:保持简单傻瓜
如果你还没读过这篇文章,请读一遍:The Kiss Principle
·大多数Android程序仅仅使用了View-Model模式。 ·程序员需要参与View的复杂性,而不是解决业务。
在应用中你仅仅使用Model-View,最后会落得“一切连接这一切”的状态。
如果这个示例图看起来不是那么复杂,那么想想每个View可能随时消失和随时出现。别忘了保存和恢复view的状态。为临时View attache 几个后台任务,蛋糕准备好了!
另一种“一切连接着一切”就是上帝对象。
上地对象太过于复杂;代码块不能被重复利用,测试或方便的debug和重构。
使用MVP模式
·复杂的任务被分解成简单的任务,并且容易解决。 ·更小的对象,更少的bug,更简单debug。 ·可测试。
原因2:后台任务
无论何时,你写Activity,Fragment或者自定义View,你可以把所有方法与后台任务的外部或者静态类联系起来。这样,你的后台任务将不会和一个Activity联系,不会造成内存泄露和不用Activity来消费。我叫这样的对象为“Presenter”。
有那么几种处理后台线程的方法,但都是不可靠的,不过MVP是可靠的。
为什么MVP可以
通过这个视图,显示了不同的应用控件,在发生configuration发生改变或者内存溢出的时候发生了什么。每一个Android开发者都应该知道这个视图,然而这样一个视图并不是每个开发都知道。
Case 1:当用户旋转屏幕,改变语言设置, attache 一个外部显示器,等情况,通常Configuration会发生变化。更多关于[Configuration]
(http://developer.android.com/reference/android/R.attr.html#configChanges)请阅读链接。Case 2:当用户在开发者设置里面选择了“Don’t keep activities”或者其他Activity到最顶层,Activity会发生restart。
Case 3:没有足够的内存和应用进入后台,process会restart。
最后
现在你可以看到,Fragment当中设置setRetainInstance(true)在这里是没用帮助的,我们只需要设置save/restore就可以。因此,我们可以简单的去除Fragment的setRetainInstance方法,来限制问题的数量。"Activity, View, Fragment, DialogFragment Static variables and threads | save/restore no change | save/restore reset |
现在看起来爽多了。我们在应用任何情况下,只需要写两段代码就可以完成restore:·Activity,View,Fragment,DialogFragment的save/restore。 ·线程restart,restart后台请求。
第一部分,是Android API提供的方法。第二部分是Presenter层的工作。Presenter只要记住那些请求需要被执行,如果一个进程执行期间restart,Presenter将会重新执行它们。
一个例子
这个例子将加载服务器上得数据来显示一些items。如果出现错误将显示一个toast。
我推荐使用RxJava来构建Presenter,因为这个Library控制数据流很简单。
我也要感谢创建The Internet Chuck Norris Database的人,我把它用在了我例子当中。
没用MVP的例子00:
public class MainActivity extends Activity { public static final String DEFAULT_NAME = "Chuck Norris"; private ArrayAdapter<ServerAPI.Item> adapter; private Subscription subscription; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); ListView listView = (ListView)findViewById(R.id.listView); listView.setAdapter(adapter = new ArrayAdapter<>(this, R.layout.item)); requestItems(DEFAULT_NAME); } @Override protected void onDestroy() { super.onDestroy(); unsubscribe(); } public void requestItems(String name) { unsubscribe(); subscription = App.getServerAPI() .getItems(name.split("\\s+")[0], name.split("\\s+")[1]) .delay(1, TimeUnit.SECONDS) .observeOn(AndroidSchedulers.mainThread()) .subscribe(new Action1<ServerAPI.Response>() { @Override public void call(ServerAPI.Response response) { onItemsNext(response.items); } }, new Action1<Throwable>() { @Override public void call(Throwable error) { onItemsError(error); } }); } public void onItemsNext(ServerAPI.Item[] items) { adapter.clear(); adapter.addAll(items); } public void onItemsError(Throwable throwable) { Toast.makeText(this, throwable.getMessage(), Toast.LENGTH_LONG).show(); } private void unsubscribe() { if (subscription != null) { subscription.unsubscribe(); subscription = null; } } }
一个有经验的开发会发现这个例子是有一些缺陷的:
·每次翻转屏幕都会重新请求一次——每次翻转屏幕用户都会看一会儿空白界面。 ·如果用户经常翻转屏幕,就会导致内存泄露——每个回调都会保持对MainActivity的引用,并且request运行的时候会把MainActivity保持在内存中。这绝对有可能导致因为内存溢出而应用crash,或者应用运行明显缓慢。
使用MVP的例子01
public class MainPresenter { public static final String DEFAULT_NAME = "Chuck Norris"; private ServerAPI.Item[] items; private Throwable error; private MainActivity view; public MainPresenter() { App.getServerAPI() .getItems(DEFAULT_NAME.split("\\s+")[0], DEFAULT_NAME.split("\\s+")[1]) .delay(1, TimeUnit.SECONDS) .observeOn(AndroidSchedulers.mainThread()) .subscribe(new Action1<ServerAPI.Response>() { @Override public void call(ServerAPI.Response response) { items = response.items; publish();//onNext } }, new Action1<Throwable>() { @Override public void call(Throwable throwable) { error = throwable; publish();//onError } }); } public void onTakeView(MainActivity view) { this.view = view; publish(); } private void publish() { if (view != null) { if (items != null) view.onItemsNext(items); else if (error != null) view.onItemsError(error); } } }
从技术角度讲:MainPresenter有三个线程事件:onNext,onError,onTakeview。通过publish()方法,onNext或者onError事件会发布到MainActivity实例。
public class MainActivity extends Activity { private ArrayAdapter<ServerAPI.Item> adapter; private static MainPresenter presenter; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); ListView listView = (ListView)findViewById(R.id.listView); listView.setAdapter(adapter = new ArrayAdapter<>(this, R.layout.item)); if (presenter == null) presenter = new MainPresenter(); presenter.onTakeView(this); } @Override protected void onDestroy() { super.onDestroy(); presenter.onTakeView(null); if (isFinishing()) presenter = null; } public void onItemsNext(ServerAPI.Item[] items) { adapter.clear(); adapter.addAll(items); } public void onItemsError(Throwable throwable) { Toast.makeText(this, throwable.getMessage(), Toast.LENGTH_LONG).show(); } }
MainActivity 创建 MainPresenter,并且保持MainPresenter在onCreate和onDestory周期之外。MainActivity用一个静态变量引用MainPresenter,当由于OOM导致线程重启,MainActivity会检查MainPresenter是否还存在,如果不存在就去创建它。
是的,检查和使用静态变量起来有那么点臃肿,但是稍后我会给大家看如何写的更加优雅。:)
主要思想:
·例子应用不会在每次用户翻转屏幕的时候重新请求。 ·如果线程被重启,再次加载数据。 ·当MainActivity被销毁后,MainPresenter不会保持应用
MainActivity实例,这样当旋转屏幕的时候就不会内存泄露,而且也没有取消请求。
Nucleus
Nuleus 是我创建的一个library,灵感来自于Mortarlibrary和Keep It Stupid Simple这篇文章。
下面是功能列表:
·支持在View/Fragment/Activity状态Bundle中save/restore Presenter的状态。Presenter能够存储请求参数到重新启动。 ·提供一个工具,通过一行代码可以把请求结果和错误放到正确的view当中去,因此无需再写`!=null`来检查。 ·一个Presenter可以被多个view实例引用。如果Presenter实例使用[Dagger],就不能被多个view引用。 ·通过一行代码就可以把Presenter和view进行绑定。 ·提供view的基类:NucleusView, NucleusFragment, NucleusSupportFragment, NucleusActivity。你也可以从他们当中copy代码到任何类当中来利用Nucleus的Presenters。 ·Presenter在线程重启之后能够自动restart。在`onDestroy`自动取消注册RxJava。 ·最后,要保持简单明了,让每一个开发者都能够看懂。这里通过大约180行代码来驱动Presenter,230行RxJava代码来支持。
使用Nuleus的例子02
public class MainPresenter extends RxPresenter<MainActivity> { public static final String DEFAULT_NAME = "Chuck Norris"; @Override protected void onCreate(Bundle savedState) { super.onCreate(savedState); App.getServerAPI() .getItems(DEFAULT_NAME.split("\\s+")[0], DEFAULT_NAME.split("\\s+")[1]) .delay(1, TimeUnit.SECONDS) .observeOn(AndroidSchedulers.mainThread()) .compose(this.<ServerAPI.Response>deliverLatestCache()) .subscribe(new Action1<ServerAPI.Response>() { @Override public void call(ServerAPI.Response response) { getView().onItemsNext(response.items); } }, new Action1<Throwable>() { @Override public void call(Throwable throwable) { getView().onItemsError(throwable); } }); } } @RequiresPresenter(MainPresenter.class) public class MainActivity extends NucleusActivity<MainPresenter> { private ArrayAdapter<ServerAPI.Item> adapter; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); ListView listView = (ListView)findViewById(R.id.listView); listView.setAdapter(adapter = new ArrayAdapter<>(this, R.layout.item)); } public void onItemsNext(ServerAPI.Item[] items) { adapter.clear(); adapter.addAll(items); } public void onItemsError(Throwable throwable) { Toast.makeText(this, throwable.getMessage(), Toast.LENGTH_LONG).show(); } }
正如你看到的,这个例子明显比前一个例子短,并且简洁。Nucleus用来创建,销毁,保存Presenter, attache 或 detached一个view到Presenter,并且把请求结果自动发送到被 attache 的View当中。
MainPresenter的代码比较少是因为通过deliverLatestCache()操作,期延迟了数据和错误,直到view是可用的,才会把数据和错误送到view里。它把数据缓存到内存中,这样当configuration改变的时候,数据还是可用的。
MainActivity的代码比较少是因为Presenter的创建由NucleusActivity来管理。所有你需要绑定presenter的类,只需要在类上声明@RequiresPresenter(MainPresenter.class)注释。
警告!注释!在Android世界中,如果你使用注释,这是一个很好的做法,这不会降低性能。我已Galaxy S(2010的设备)作为基准测试,处理注释只会花去0.3ms。这种注视只会发生在view中,所以我认为注释是对系统性能没有消耗的。
更多例子
这是一个参数持久性的例子。测试列子。
deliverLatestCache()方法
这是RxPresenter的一个方法,它有三种版本:
·deliver()延迟onNext,onError和onComplete到view变成可用的才会释放。当你做一次请求的时候可以使用它,例如登录到web service。Javadoc
·deliverLatest()如果有一个新的onNext可用,将会抛弃老的onNext。如果你有数据需要更新,这将不会积累没有必要的数据。Javadoc
·deliverLastestCache()和deliverLatest()比较相似,它保存最后一次数据在内存中,当另一个view变成可用的(例如:configuration 改变),它将重新发送数据到view。如果你不想save/restore请求结果到你的view中(返回结果比较大或者不方便存储到Bundle中),这个方法将允许你去做出更好的用户体验。Javadoc
Presenter的生命周期
Presenter的生命周期与Android的控件相比,明显少一些。
·void onCreate(Bundle savedState) - 当Presenter被创建的时候会被调用。Javadoc
·void onDestroy() - 离开view的时候会被调用。Javadoc
·void onSave(Bundle state) - 当View的onSaveInstanceState被调用时会调用,保持Presenter的状态。Javadoc
·void onTakeView(ViewType view) -在Activity或者Fragment调用onResume(),或者在android.view.View#onAttachedToWindow()期间。 Javadoc
·void onDropView() - Activity或者Fragment调用onPause(),或者在android.view.View#onDetachedFromWindow()期间。Javadoc
View回收和View栈
通常你的view(Fragment和自定义view)在与用户的交互下随机 attache 和 detached。每次view被 detached的时候不去销毁Presenter,这可能是一个好主意。你可以任何时间 detached和 attache view,presenter会比这些动作活的更持久,继续后台的工作。
联想到view的回收,有个问题:fragment无法知道是否因为配置改变或者被弹出栈被 detached。
Nucleus的意见是:销毁presenter只能发生在view的onDetachedFromWindow()/onDestroy()并且activity是finish的。所以,如果你销毁view是在正常的activity生命周期,你可发出信号来通知presenter也应该被销毁。这里有两个方法可以用NucleusLayout.destroyPresenter()和NucleusFragment.destroyPresenter()。
举个例子,下面是我在我的项目里面如何管理Fragment pop()操作:
fragment = fragmentManager.findFragmentById(R.id.fragmentStackContainer); fragmentManager.popBackStackImmediate(); if (fragment instanceof NucleusFragment) ((NucleusFragment)fragment).destroyPresenter();
你可以对replace Fragment做类似的操作。压栈操作的时候也可以。
每次view从Activity detached的时候,你可以决定去销毁presenter来避免这个问题,但是你也将在view被detach的时候失去后台任务。
因此,view回收这部分,完全取决于你。也许,我会找到更好的解决方案,如果你知道,请告诉我。
最佳实践
把你的请求参数放在Presenter里
这个规则很简单:主要是为了管理请求。所以view自己不应该掌控和重启请求。从View的角度来看,后台任务,永远不会消失,不需要任何回调也会返回一个结果或错误。
public class MainPresenter extends RxPresenter<MainActivity> { private String name = DEFAULT_NAME; @Override protected void onCreate(Bundle savedState) { super.onCreate(savedState); if (savedState != null) name = savedState.getString(NAME_KEY); ... @Override protected void onSave(@NonNull Bundle state) { super.onSave(state); state.putString(NAME_KEY, name); }
我建议使用Icepicklibrary。无需使用注解,就可以减少代码量,并且简化应用逻辑——这一切都发生在编译过程中。可以配合ButterKnife使用。
public class MainPresenter extends RxPresenter<MainActivity> { @Icicle String name = DEFAULT_NAME; @Override protected void onCreate(Bundle savedState) { super.onCreate(savedState); Icepick.restoreInstanceState(this, savedState); ... @Override protected void onSave(@NonNull Bundle state) { super.onSave(state); Icepick.saveInstanceState(this, state); }
如果你有超过2个的请求参数,这个library会存储它们。你可以创建一个BasePresenter,并且把Icepick放在类里,这样所有的子类将会获得@Icicle,无需再次实现onSave。这也工作在activity,Fragment和view。
在onTakeView主线程中,执行一个即时查询Javadoc
有时候,你要查询一段小数据,例如从数据库中读取一小段数据。虽然你可以用Nucleus简单的创建一个请求,但是你不必到处使用Nucleus。如果在一个Fragment创建的过程中创建一个后台请求,用户会看到一个空白屏幕一小会儿,尽管这个请求就几毫秒。因此,为了是代码更简短,更友善,使用主线程吧。
不要尝试用Presenter控制你的View
这么做不是个好方式——应用的逻辑会变得更复杂,这是不正常的方式。
正常的方式是,控制流应该是从用户,通过View,到Presenter,再到Model。用户是控制应用程序的一个来源。因此我们的控制流应该是从用户开始,而不是从应用的内部的结构。
当控制流是从View到Presenter,然后Presenter到Model,这是一个线性流,这样很好写代码。这样你得到了一个简单的序列,user->view->presenter->model->data。但是,当控制流是这个样子的:user->view->presenter->view->presenter->model->data,这只是违反了KISS原则。
Fragment?是的,Fragment有时候会违反正常的控制流。他们太复杂了。这里有一篇不错的文章,关于思考Fragment:Advocating Against Android Fragments。但是Flow也没有简化太多。
MVC
如果你熟悉MVC,别用了。MVC完全不同于MVP,MVC并没有解决开发面临的问题。
什么是MVC?
·Model应用内部的逻辑部分。负责数据存储。 ·View唯一和MVP共同的部分,应用中呈现到屏幕的部分。 ·Controller输入设备,例如键盘,鼠标,操纵杆。
当你有一台电脑和一个用键盘简单驱动的游戏的时候,MVC出现有很长一段时间了。没有windows,没有图形交互界面,应用程序接收输入(Controller),维持一些状态(Model),产生输出(View)。控制流是这样的:Controller->Model->View。这种模式绝对不能用在Android中。
有很多混淆的MVC模式。人们相信他们使用的是MVC,实际上他们可能用的是MVP(Web开发)。很多Android开发,认为Controller就是控制View,因此他们尝试抽取View的逻辑代码来减少View的代码,用Controller来控制View。我个人没看到这种方式有任何好处。
使用不可变数据结构的复杂关系数据库项目
AutoValue是一个这样的library,在它的描述中写了一堆好处,我推荐看看它。AutoParcel是AutoValue一个Android项目。使用的主要原因是,不用改变对象,通过AutoParcel转换,而不用关心其影响了应用程序的其他部分。他们都是线程安全的。
结尾
尝试MVP,并且分享给你的朋友。:)