Android架构模式都没搞懂，拿什么去跳槽啊？

关注

原创最新推荐文章于 2026-03-15 01:36:45 发布 264 阅读 AI 写同款· GEO 优化 ›

京东Android校招笔试真题解析：考点拆解与备考攻略 Android开发岗校招笔试往往涵盖Java基础、组件机制与数据结构算法，是检验候选人计算机功底和编码能力的关键环节。理解HashMap底层扩容与并发问题、Handler消息循环原理、Activity启动模式等核心知识，有助于构建完整的Android技术体系。这些原理不仅用于解题，更直接支撑日常开发中的性能优化、异步任务处理和架构设计。针对京东等大厂真题进行考点拆解与刷题路径规划，能帮助应届生系统备战校招，快速掌握高频考点、编程题解法与时间管理技巧，实现从基础理论到工程实践的有效转化。阅读详情

为什么要用架构或者模式？

使用架构的目的是使程序模块化，做到模块内部的高聚合和模块之间的低耦合，使得程序在开发的过程中，开发人员只需要专注于一点，提高程序开发的效率。

而且最重要的一点，架构和模式并不是说让你的代码量更少了，往往可能还会增大，但是它帮你在逻辑上更简单的了，很好的定义了单一原则，提供了更好的扩展性，方便定位问题以及后续需求变更时不至于满篇的去改一大堆东西。

MVC

MVC（Model-View-Controller）是最常见的软件架构之一，业界有着广泛应用。它本身很容易理解，但是要讲清楚，它与衍生的 MVP 和 MVVM 架构的区别就不容易了。

视图层(View)

对应于XML布局文件

控制层(Controller)

Android的控制层是由Activity来承担的，Activity本来主要是作为初始化页面，展示数据的操作，但是因为XML视图功能太弱，所以Activity既要负责视图的显示又要加入控制逻辑，承担的功能过多。

模型层(Model)

我们针对业务模型，建立的数据结构和相关的类，它主要负责网络请求，数据库处理，I/O的操作。

在Android开发中，Activity并不是一个标准的MVC模式中的Controller，本来它的首要职责是加载应用的布局和初始化用户界面，接受并处理来自用户的操作请求，进而作出响应。在MVC模式下随着界面及其逻辑的复杂度不断提升，Activity类的职责不断增加，以致变得庞大臃肿。

MVP

MVP 架构模式是 MVC 的一个变种，MVC 与 MVP 之间的区别其实并不明显，作者认为两者之间最大的区别就是 MVP 中使用 Presenter 对视图和模型进行了解耦，它们彼此都对对方一无所知，沟通都通过 Presenter 进行。

视图层(View)：

负责绘制UI元素、与用户进行交互，对应于XML、Activity、Fragment

模型层(Model)：

负责存储、检索、操纵数据，一般包含网络请求，数据库处理，I/O流。

控制层(Presenter)：

Presenter是整个MVP体系的控制中心，作为View与Model交互的中间纽带，处理View于Model间的交互和业务逻辑。

MVP的设计思想在项目中的具体实现就是接收到View的请求，从Model层获取数据，将数据进行处理，通过View层的接口回调给Activity或者Fragment。

MVP能够让Activity成为真正的View，只做UI相关的事。

此外它的优点还是很多：

1.模型与视图完全分离，我们可以修改视图而不影响模型；

2.项目代码结构（文件夹）清晰，一看就知道什么类干什么事情；

3.我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑，这个特性非常的有用，因为视图的变化总是比模型的变化频繁

4.协同工作（例如在设计师没出图之前可以先写一些业务逻辑代码或者其他人接手代码改起来比较容易）

尽管这样，MVP模式也有不足之处，缺点如下：

1.Presenter层与View层是通过接口进行交互的，View层可能会有大量的接口，因为有可能好几个Activity都是去实现同一个View接口，那么所有用到的Activity都要去实现所有的方法(不管你是否用到)，而且如果后面有些方法要删改，Presenter和Activity都要改动，比较麻烦；

2.MVP把Activity相当的一部分责任放到了Presenter来处理，复杂的业务同时也可能会导致P层太大，一旦业务逻辑越来越多，View定义的方法越来越多，会造成Activity和Fragment实现的方法越来越多，依然臃肿。

MVVM

MVP中我们说过随着业务逻辑的增加，UI的改变多的情况下，会有非常多的跟UI相关的 Case，这样就会造成View的接口会很庞大。

而MVVM就解决了这个问题，通过双向绑定的机制，实现数据和UI内容，只要想改其中一方，另一方都能够及时更新的一种设计理念，这样就省去了很多在View层中写很多 Case 的情况，只需要改变数据就行。

Model：

Model层就是职责数据的存储、读取网络数据、操作数据库数据以及I/O，一般会有一个ViewModel对象来调用获取这一部分的数据。

View：

我感觉这里的View才是真正的View，为什么这么说？View层做的仅仅和UI相关的工作，我们只在XML、Activity、Fragment写View层的代码。

View层不做任何业务逻辑、不涉及操作数据、不处理数据、UI和数据严格的分开。

ViewModel：

ViewModel 只做和业务逻辑和业务数据相关的事，不做任何和UI、控件相关的事，ViewModel 层不会持有任何控件的引用，更不会在ViewModel中通过UI控件的引用去做更新UI的事情。

ViewModel就是专注于业务的逻辑处理，操作的也都是对数据进行操作，这些个数据源绑定在相应的控件上会自动去更改UI，开发者不需要关心更新UI的事情。