Android应用架构 — 从MVC到MVVM，阿里巴巴Android口试题答案 ...

如许一来，MVC看起来就很像厥后的MVP了：

角色划分

• Model: 用来保存程序的数据状态，比如数据存储，网络请求等。
  
• View: GUI组件构成，向用户展示Model中的数据。
  
• Controller: 连接用户和系统，响应交互，传递数据。
  

办理的问题

MVC最重要的目的并不是规定各个模块应该怎样交互和联系，而是将原有的紊乱的应用程序划分出公道的层级，把以往一团紊乱的代码，按照展示层和范畴层分成两个部分。这种分离使得位于范畴层中的范畴对象可以不需要对展示层有任何了解，因此可以同时为差别的展示层工作，从而开端的实现了范畴层与展示层的解耦。
缺点

• MVC只是一种引导头脑，因而它没有明确的规定各个模块具体应该怎样交互和联系，这使得使用MVC开发的程序其布局总是千奇百怪的，这些千奇百怪的布局也有着各自独特的优势与缺陷。
  
• 另外在Android中，XML作为View层功能太羸弱，很多的界面干系的代码不得不写到Activity中，而Activity同时又作为Controller帮忙View处理用户变乱，这使得Activity的职责相当不纯粹。因此在Android中，MVC的Controller和View着实是没有分离的，形成了一种View-Model的布局。
  

MVP架构

劈头与发展

在上文中，我们提到了劈头于Web的一种MVC架构变体，这套架构模式除了被广泛应用于Web后端（比如SpringMVC框架），也反哺了客户端架构的演化。
随着GUI框架的不断进化与完满，View层具备了独立的捕捉交互变乱以及处理交互变乱的能力，因此处理交互的逻辑从Controller转移到了View中，这使得Controller直接没有存在的必要了。这种情况也同样体现在Android中：Activity和XML View组成了新View层，而不再需要Controller的角色。
前面提到，Controller在帮忙View处理用户变乱时，还趁便揽下了一部分介于View和Model之间的业务逻辑，比如在View和Model之间传递数据和请求，将Model层返回的数据做一下转换再交给View渲染等等。而Controller的消散则让这部分逻辑不得不去再次回到View或Model中，进而使得View和Model相互耦合起来。
为此，人们便借鉴了Web中的MVC架构，View必须通过Controller向Model发起请求，Controller收到效果再去更新View。如许一来，View和Model就被隔脱离了，同时之前那些业务逻辑又有合适的去处了。

在这套架构模式中，由于Controller不再作为系统与用户的连接，控制器这个名称好像有些不公道，于是便改名为Presenter（主持人）， 从名称也可以想到，这是一个协调View和Model工作的角色。
MVP架构模式解除了View与Model耦合，避免了业务逻辑出现View中，使在MVC中紊乱的数据流/变乱流变得清晰起来。 再厥后，人们发现Presenter与View之间存在强耦合，这两部分欠好独立的进行开发与测试，便运用依靠倒置原则(DIP)提取出接口，让它们相互依靠接口，便有了现在的MVP。

角色划分

• Model：用来保存程序的数据状态，比如数据存储，网络请求等。
  
• View：GUI组件构成，向用户展示数据，响应用户变乱等。
  
• Presenter：作为沟通View和Model的桥梁，处理来自View层转发的用户请求，从Model层检索数据，关照View层改变界面等。
  

两种常见的MVP

Passive View

Passive View MVP是最典范的，在该架构模式中，View层是被动的，也就是说，View层自己不会主动改变自己的任何状态，全部状态都交由Presenter间接改变。

Supervising Controller

Supervising Controller MVP与Passive View MVP的差别之处在于前者并没有完全解除View与Model之间的耦合， 而是使用DataBinding这类的框架将View属性与Model中部分数据进行绑定，简朴的数据展示直接由View与Model进行同步，而 Presenter只处理复杂的状态同步与模块协调等工作。

办理的问题

• 规范了传统MVC中紊乱的数据流向/变乱流向。
  
• 将用户变乱捕捉从Controller(Presenter)中抽离出来，使Controller(Presenter)可以专注于业务逻辑。
  
• 解除了View与Model之间的强耦合，使View层能更专注于UI处理。
  
• 解除了View与Presenter之间的强耦合，使一个Presenter能够应用于多个View，同时各个模块可以独立开发、独立测试。
  

存在的问题

• 会引入大量的接口，增加代码布局的复杂性（查看调用逻辑会很贫苦）。
  
• Presenter层持有View，导致该层不得不感知View的声明周期，带来额外的复杂度。
  

MVVM架构

劈头与发展

从Supervising Controller到Presentation Model

在前文中，我们提到，Supervising Controller MVP使用数据绑定直接将View与Model中部分属性进行绑定，在一定水平上淘汰了视图与模型之间同步的代码。
然而这种绑定只实用于简朴属性-状态的同步，涉及到较为复杂视图状态同步便无能为力了；并且，在业务逻辑较为复杂时，直接将范畴模型实体暴露给展示层，大概会导致混合业务逻辑与表现逻辑的问题。

在2004年，Martin Flower提出了Presentation Model，该模式从视图层抽象出一个展示模型， 并定名为Presentation Model，视图则根据这个模型的实体进行渲染。
Presentation Model将视图中的状态和行为放到一个单独的展示模型中，协调范畴对象（模型），并为展示层提供接口，从而最大水平的淘汰在视图层中的逻辑。视图层则将全部状态存储在展示模型中，并保持其状态与展示模型中的状态同步。

MVVM的诞生

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Android工程师，想要提升技能，每每是自己探索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易遇到天花板技术停滞不前！
因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简朴，就是希望能够帮助到想自学提升又不知道该从何学起的朋侪，同时减轻大家的负担。

既有适合小白学习的零底子资料，也有适合3年以上履历的小搭档深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包罗大厂面经、学习笔记、源码讲义、实战项目、解说视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip204888 （备注Android）

文末

我总结了一些Android核心知识点，以及一些最新的大厂口试题、知识脑图和视频资料解析。
以后的路也希望我们能一起走下去。（谢谢大家一直以来的支持）
部分资料一览：

• 330页PDF Android学习核心笔记（内含8大板块）
  

• Android学习的系统对应视频
  
• Android进阶的系统对应学习资料
  

• Android BAT大厂口试题（有解析）
  

Android进阶的系统对应学习资料
[外链图片转存中…(img-OmW8qZeX-1711918522744)]

• Android BAT大厂口试题（有解析）
  

[外链图片转存中…(img-8wIl56LX-1711918522745)]
   本文已被CODING开源项目：《Android学习笔记总结+移动架构视频+大厂口试真题+项目实战源码》收录

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。