老实说，我无法理解所有这些关于Android的MVP和类似的东西：它的真正意义是什么？
到目前为止，我看到在Android中使用MVP的唯一实际原因是从框架类（即活动，服务，碎片......）中“提取”单元可测试的代码片段，否则这些代码将很难（或者不可能） ）来测试。
这很不错但是这样活动（和其他框架类）最终会在可能的情况下（即处理框架不可知代码时）将工作委派给演示者，并在不处理时直接进行工作。因为这个演示者最终看起来很奇怪，因为它有一些镜像Activity生命周期的方法（onStart，onResume，clickListeners ......）。我想知道这是不是代码味道？
除此之外，我看到大量的库/模式来构建MVP Android应用程序，但老实说，我没有看到它们真正的好处：让每个Activity手动创建和管理自己的演示者有什么缺点？ 我认为将Activity和Presenter相互分离没有任何好处，因为演示者只是从Activity中“提取”某些代码，它将根据定义与它紧密耦合，只要主持人这听起来就很好。仅包含严格的表示逻辑（业务逻辑的其余部分将进入对View / Presenter二人组无关的专用类。）
我对这个话题感到有点失落，我想就此问题提出一些其他意见，以获得更大的视角。
答案 0 :(得分：0)
是的，确定，您可以使您的演示逻辑框架与测试无关，但MVP还有助于通过更改演示者来更改运行时的行为。 View界面应该有更抽象的方法（不是＆＃39;隐藏按钮X＆＃39;，描述，比如显示一组数据）。通过将UI逻辑与依赖于框架的实现分离，我们可以使用不同的视图来更改UI，或者使用Presenter在运行时更改逻辑。观看 - 演示者也是一个“垫片”，这使得写作“意大利面条”变得更加困难。代码
答案 1 :(得分：0)
从长远来看，您的代码应该是可行且易于维护的，没有人愿意花费额外的时间来重构代码。不，当我们开始我们的项目时，我们应该关注正确的模式。
谈到MVP，它为您提供了易于测试的演示者层，并且没有视图参考，因此您可以轻松执行junit测试用例，否则您必须使用其他UI测试用例。
您可以在任何地方重复使用相同的演示者，因为它只包含业务逻辑
所以，如果你不想面对未来的代码问题，我建议你应该继续使用MVP