Was ist das MVP-Modell von Android? Was ist der Unterschied zum normalen Schreiben von Event-Handling-Funktionen?
Ist MVP nur eine zusätzliche Presenter-Klasse, um das Android-Ansichtsobjekt zu speichern, Daten zu verarbeiten und die Ansicht zu aktualisieren?
Besteht der Unterschied zum normalen Schreiben von Ereignisverarbeitungsfunktionen darin, dass der Code in der Ereignisverarbeitungsfunktion in die Presenter-Klasse verschoben wird?
Aber wenn es nur dieser Unterschied ist, scheint es nichts Besonderes zu sein. Sind wir beim Schreiben von Code nicht alle so abstrakt? Warum sollten wir das Konzept von MVP trennen, wenn wir die Geschäftslogik zusammenfassen?
个人看来优点有以下几个：
1、逻辑清晰，界面的归View，数据处理的归Presenter，不至于出现Activity和Fragment大爆炸，读起代码来十分要命，后续的维护和升级也会带来很大的方便。我在看别人写的代码的时候，最怕分层不清楚，十分吃力。
2、测试方便，Presenter可以单独抽出来测试，不用和View绑定在一起测试，出错了也好排查。
你这么说是没错啦，专门用presenter来处理view。
我认为的好处：
1.presenter正常接收的是一个view的接口，这个应用DIP（依赖倒置原则），就是让我们尽量依赖抽象，这样任意一个view，只要实现了这些接口，那么他们都可以共用这些处理逻辑。
2.应用了SRP(单一职责原则)，可以让数据处理逻辑层与view分离，解耦
其实只是我们在开发中的随意性有点高，按照OCP原则，对扩展开发，对修改封闭，一个Activity可能会有 v1 v2 v3版本，那么这时候你去修改代码的时候，可能就是把以前的代码推到重来，或者在以前的代码基础上修改，这是比较危险的行为，而且也是一个没效率的行为，用了MVP，那么当你出现了v2、v3版本的时候，可能增加了几个控件，或者减少了几个控件，此时你如果是直接去修改之前的代码，那么mvp框架确实没有鸟用，但是你以扩展的方式来进行开发，就不一样了，多了几个控件，那么写个新interface继承原来view的interface，然后再来一个新的presenter继承旧的，在这里面进行新逻辑的编写，维护上面和方便，测试也只需要测试新的代码就行了，程序的稳定性可以增强。
所以如果遵照mvp模式来写，不知不觉中的你代码的可维护性就变强了。