该篇内容 come from here
架构
根据维基百科解释：软件架构是指软件系统的高级结构以及创建这种结构和系统的学科，我们都知道什么是建筑学。
简单说，决定并实施特定的代码架构或设计模式就是解决开发人员不时而遇的问题。
问题
一些常见的问题，如代码紧耦合，即使代码的一部分发生细小变化，也会导致代码的其他部分发生变化或者错误。可重用性降低最终导致复制粘贴代码行。显得不那么友好。
如何解决
Android本身被编写为MVC，其中Activity或多或少地负责所有事情。对于足够简单的应用，但随着复杂性的增加，问题的数量和水平也会提高。
目前有许多不同的架构方法，如MVP，FLUX，MVI，MVVM等，已被证明在解决上述问题方面富有成效。只要代码可维护，我们就可以使用任何方法，我们能够快速适应变化，一切运行良好，简而言之就是开发人员的快乐生活。
终极目标
以大局观看，最终目标是以这种分布式方式构建实体，将Android相关的东西保存在一个地方，并分离出所有其他不需要运行的android实体，然后进一步拆分非-Android依赖片，从而实现代码模块化，可扩展性，易于维护，测试友好性等...
问题：为什么选择MVVM？
关于架构模式无数的讨论和文章，我们可以同意这一点，上面讨论的最受欢迎和广泛采用的是MVP~Model - View - Presenter。围绕这个有很多作品，甚至我很欣赏它。它是一个成熟的模式，在某种程度上它实际上解决了这个问题，总有一个但是～你懂的～未完。
We can agree that nothing is perfect and there is always a scope for betterment.
我们同意没有任何事物是完美的，并且有办法做到更好。
MVP已经成熟，令人惊叹的是Google引入了Android架构组件，其中包括ViewModel而不是Presenter，因此证明了Google支持MVVM。
MVP肯定有些不对劲!!
一个简单的MVP看起来像这样：
简单的MVVM看起来像这样：
以上显示的是两者的简化表示。您看得出来差别吗？让我们从MVP仍然面临的问题开始，以及我们如何利用MVVM来克服这些问题。
紧耦合
对于每个Activity或者Fragment而言（视图），我们需要一个Presenter。这是一个硬约束规则。 Presenter保存对Activity和Fragment的引用保留对presenter的引用。 1：1的关系，这就是最大问题所在。
随着视图复杂性的增加，这种关系的维护和处理也会增加。
这最终会导致我们之前遇到的同样问题，因为设计的快速变化，我们实际上需要修改整个关系。
从我们的最终目标“以分布式方式构建事物”中挑选一个声明，为了实现它并避免这种紧密关系，ViewModels被引入。
ViewModels是简单类，它们与逻辑/模型层交互，只暴露状态/数据，实际上不知道该数据将由谁或如何使用。只有View（Activity）保存对ViewModel的引用，反之亦然，这解决了我们的紧耦合问题。单个视图可以保存对多个ViewModel的引用。
即使对于复杂的视图，我们实际上可以在同一层次结构中具有不同的ViewModel
可测性
由于Presenters很难绑定视图，因此编写单元测试变得有点困难，因为View具有依赖性。
ViewModels的单元测试更加友好，因为它们只是暴露状态，因此可以独立测试而无需测试数据的消耗方式，简而言之，ViewModels不依赖于View。
这是两个主要的选择，使选择明确。可能有更多或可能没有。以下评论等待中!!
最终决策
这些架构模式在不断发展，MVVM具备所有能力，或者我们可以说有可能变得强大，有用但实现惊人。 MVP已经发展到一定程度，但没有什么是完美的。
我也同意MVVM有一个轻微的学习曲线，但最终它帮助我们克服了一些缺点。
不确定未来，但截至目前“一个适合所有解决方案~Silver Bullet”是不存在的，单个模式可能不足以满足要求。有人可能不喜欢MVVM，这纯粹取决于他们的判断力。只要我们能够实现最终目标，其他任何事情都不重要。
PS：这些是我个人的经历，想法和为什么我们喜欢MVVM用于我们的项目。这里的目的不是比较和找出差异。我所尝试的只是分享我对MVP的经验以及MVVM可以克服的一些缺点。
如果有兴趣，我还准备了一个示例项目（样板代码设置，链接如下），它使用Kotlin，Android Architectural Components，RxJava，Dagger 2实现MVVM。我们将非常感谢您的反馈和建议。
连接地址
那就是这篇文章。如果你喜欢这个，并认为我在这里做得很好，那么请不要忘记拍手。您的欣赏是有价值的，让我保持积极性。
快乐的编码，Cheers!!
