使用Kotlin构建更适合Android的MVVM应用程序，安卓已死

最新推荐文章于 2024-08-05 15:00:50 发布

程序员8000

最新推荐文章于 2024-08-05 15:00:50 发布

阅读量465

点赞数 4

分类专栏： 2024年程序员学习文章标签： android kotlin 开发语言

本文链接：https://blog.csdn.net/2201_75604580/article/details/136910227

版权

View：Activity、fragment、view、adapter、xml等等

Controller：为View层处理数据，业务等等

从这个结构来看，Android本身还是符合MVC架构的。不过由于作为纯View的xml功能太弱，以及controller能提供给开发者的作用较小，还不如在Activity页面直接进行处理，但这么做却造成了代码大爆炸。一个页面逻辑复杂的页面动辄上千行，注释没写好的话还十分不好维护，而且难以进行单元测试，所以这更像是一个Model-View的架构，不适用于打造稳定的Android项目。

MVP

Model：实体模型、数据的获取、存储等等

View：Activity、fragment、view、adapter、xml等等

Presenter：负责完成View与Model间的交互和业务逻辑，以回调返回结果。

前面说，Activity充当了View和Controller的作用，造成了代码爆炸。而MVP架构很好的处理了这个问题。其核心理念是通过一个抽象的View接口（不是真正的View层）将Presenter与真正的View层进行解耦。Persenter持有该View接口，对该接口进行操作，而不是直接操作View层。这样就可以把视图操作和业务逻辑解耦，从而让Activity成为真正的View层。

这也是现今比较流行的架构，可是弊端也是有的。如果业务复杂了，也可能导致P层太臃肿，而且V和P层有一定耦合度，如果UI有什么地方需要更改，那么P层不只改一个地方那么简单，还需要改View的接口及其实现，牵一发动全身，运用MVP的同行都对此怨声载道。

MVVM

Model：实体模型、数据的获取、存储等等

View：Activity、fragment、view、adapter、xml等等

ViewModel：负责完成View与Model间的交互和业务逻辑，基于DataBinding改变UI

MVVM的目标和思想与MVP类似，但它没有MVP那令人厌烦的各种回调，利用DataBinding就可以更新UI和状态，达到理想的效果。

数据驱动UI

在使用MVC或MVP开发时，我们如果要更新UI，首先需要找到这个view的引用，然后赋予值，才能进行更新。在MVVM中，这就不需要了。MVVM是通过数据驱动UI的，这些都是自动完成。数据的重要性在MVVM架构中得到提高，成为主导因素。在这种架构模式中，开发者重点关注的是怎样处理数据，保证数据的正确性。

关注点分离

常见的错误就是把所有代码都写在Activity或者Fragment中。任何跟UI和系统交互无关的事情都不应该放在这些类当中。尽可能让它们保持简单轻量可以避免很多生命周期方面的问题。MVVM架构模式下，数据和业务逻辑都处于ViewModel中，ViewModel只关心数据和业务，不需要直接和UI打交道，而Model只需要提供ViewModel的数据源，View则关心如何显示数据和处理与用户的交互。

通过以上简述和与MVC、MVP的对比，我们可以发现MVVM还是很有优势的，而如果再搭配Kotlin语言的话，可以说是如虎添翼了。