企业官网建设流程全解析

1. MVP到底在解决什么问题：从一次难看的重构说起

先聊一个我印象特别深的场景。

好几年前我接手一个维护期的老项目，功能不复杂，就是商品列表加详情加购物车，但代码已经乱得让人不敢动。Activity里塞了网络请求、JSON解析、SharedPreferences读写、列表适配器初始化，还有几个按钮的点击逻辑，一个文件轻松突破一千行。改一个需求，牵一发动全身：调整接口字段，要先找到Activity里那一大坨回调；换一个数据源，列表适配器和加载状态全得跟着改。更要命的是，想给业务写单元测试，发现根本无从下手——逻辑全贴在Android的View上，离开了模拟器什么都跑不了。

那段时间我就在想，问题到底出在哪。其实不是某个文件写得烂，而是没有任何约束在阻止代码往Activity里堆。Android给了开发者很大的自由，Activity既能当View用、又能当Controller用，结果就是大家都习惯了"一个页面一个全能类"。

后来我接触到了MVP开发模式，才意识到自己之前缺的不是编码能力，而是对职责边界的认知。MVP不是什么高深的新框架，它没引入任何新概念，也没有必须依赖的第三方库，它只是一套约定：把界面展示、业务逻辑、数据模型强行拆开，让每一层只做自己该做的事。这个介于View和Model之间的Presenter，就是整个模式的核心，它负责把"用户点了按钮"翻译成"业务要做什么"，再把"业务返回的数据"翻译成"界面该怎么显示"。

这篇文章就是写给准备面试的朋友看的。MVP、MVC、MVVM几乎是客户端面试绕不开的必考题，面了十家至少八家会问。我不打算只列概念，而是结合我自己重构项目的真实经过，把这套模式从"为什么存在"讲到"怎么落地"，再聊聊面试官通常在追问里藏的那些考点。如果你已经写过几个MVP项目但对答不流畅，或者只是背了概念但没真正理解，这篇应该都能帮上忙。

2. MVP的分工规则：Model、View、Presenter各自管什么

2.1 三层各管一摊事，边界怎么划

MVP三个字母分别对应Model、View、Presenter，职责划分是这套模式的基石，我在面试中多次被人用各种方式确认是否真正理解这一点。

Model层：数据来源和业务规则。网络请求、数据库读写、首选项存取、文件操作，以及对这些数据做加工计算的逻辑，都属于Model的范畴。一个容易忽略的细节是，Model是不知道UI存在的，它不关心数据被谁消费、怎么展示，只负责"把数据给我"。这带来的直接好处是Model可以被独立测试，也可以被多个页面复用。

View层：负责所有和界面相关的事。渲染数据、处理用户输入、展示加载状态、弹出错误提示，这些都是View的职责。在Android里，View层通常是Activity、Fragment或自定义View。有一个关键点需要拎出来强调：View不直接请求数据，也不直接做业务判断，它只做两件事——把用户的操作告诉Presenter，以及按Presenter的指示刷新界面。

Presenter层：View和Model之间的协调者。它接收View传来的用户意图，调用Model拿到数据，再把数据加工成View可以直接展示的状态返回给View。Presenter是纯逻辑层，不持有任何Android相关依赖，这才是它能做单元测试的根本原因。

打个比方来理解这三者的关系：Model是厨房，负责把菜做出来；View是餐桌，负责把菜端上来给客人吃；Presenter是服务员，客人点了什么菜由它传达后厨，菜做好了由它端回餐桌。客人不用自己跑去厨房，厨房也不用关心客人的口味偏好。

2.2 双向通信的两种实现路径

MVP里的View和Presenter是双向关联的：View持有Presenter的引用，把用户事件传给它；Presenter也持有View的引用，把数据状态传回去。因为两者要互相调用，所以必须有明确的接口约定。

一个方向是View → Presenter，这个最简单，View直接调用Presenter暴露的方法即可，比如presenter.loadData()或presenter.onItemClicked(item)。因为View持有Presenter的具体实现，这种调用没有任何弯弯绕绕。

另一个方向是Presenter → View，这个稍显棘手。如果让Presenter直接持有Activity或Fragment的具体类型，那它就和Android耦合死了，不复存在"脱离环境跑测试"的优势。所以正确的做法是给View定义一个窄接口，Presenter只依赖这个接口，不知道对面具体是什么实现。

一个典型的接口定义长这样：

public interface UserListView { void showLoading(); void hideLoading(); void showUsers(List<User> users); void showError(String message); }

Presenter里持有的是UserListView，调用view.showUsers(users)时，它并不知道具体实现者是Activity还是别的什么。Activity负责实现这个接口，在方法里操作真实的UI控件。这里有一个关键认知：View层的接口要尽量"窄"，只暴露Presenter真正需要调用的方法，不要图省事把整个Activity的全部能力都塞进去。接口越宽，耦合越紧，这一点在后续维护时会明显感受得到。

2.3 为什么View一定要定义一个窄接口

很多人第一次写MVP时会困惑：我直接在Presenter里new一个Activity对象不就行了，为什么非要多定义一个接口？这不是脱裤子放屁吗？

答案藏在"可替换性"和"可测试性"这两个词里。先说可测试性，Presenter持有的是接口而非具体实现，那么在单元测试里，就能用一个Mock的View替身去验证Presenter的行为逻辑——比如调用loadData()后，Mock View是否收到了showLoading()和showUsers()的调用，传进去的数据对不对。所有这些验证都无需启动模拟器，一个普通的JVM测试就能完成。而如果Presenter直接持有Activity的引用，同样的测试必须在Android环境里跑，成本会高很多。

再说可替换性，接口允许同一个Presenter服务于不同的View实现。最常见的场景是横竖屏切换，Activity被重建了，但业务数据还在，合理设计下Presenter可以继续复用同一份数据状态，Activity只是重新挂接上去而已。

所以在回答"MVP怎么实现"时，不要只说三层各自做什么，一定要把面向接口编程这条带出来。面试官很清楚，写出三个类人人都行，能守住接口边界才说明真正内化了MVP。

3. MVP与MVC、MVVM的对比：面试官问"区别"时想听到什么

3.1 从MVC到MVP：变化的不只是名字

面试里最经典的问题就是"MVP和MVC有什么区别"，很多人的回答止步于"MVC是Model-View-Controller，MVP是Model-View-Presenter"，这种答案约等于没答。面试官想听的，是这两种模式下View和Model之间的依赖关系发生了什么变化。

在传统的MVC架构里，View和Model之间存在直接通信。View读取Model的数据来渲染界面，用户在View上操作，Controller负责更新Model，Model的变化又会反过来影响View的显示。三者形成一个互相感知的闭环，这意味着Model一旦出问题，View会直接感知到；反过来，View的代码里也常常混入业务判断。

MVP对这个结构的改造是激进的：它彻底斩断了View和Model之间的直接联系。View不认识Model，Model也不认识View，所有交互都必须经过Presenter中转。View想做任何事，只能告诉Presenter；Model有任何新数据，也只能回报给Presenter。这个"一刀切"的设计看着笨重，却带来一个巨大的工程收益——每一层的内部改动都不会渗漏到其他层，因为唯一的信息通道被收窄到了接口方法上。

我自己的体会是，MVC适合业务简单、数据流单向清晰的场景，写起来确实比MVP省代码；一旦页面复杂度上来，各种状态需要联动，MVC里View直接观察Model的做法很快就会让代码失控，Model的一处改动往往引出一串连锁修改。MVP用多写一层接口的代价，换来了清晰的依赖方向和可单元测试的能力，对于中大型项目来讲非常划算。

3.2 MVP与MVVM的权衡：数据绑定是解放还是新坑

MVP之后必然被追问的是MVVM，"你了解MVVM吗，它和MVP相比有什么优劣"。这两个模式的核心意图是一致的——分离关注点、消灭View和Model的直接耦合，区别集中在如何把数据的变化同步到View。

MVP是手动的：Presenter把数据拿出来，调用view.showXxx()来刷新界面，来回的每一个环节都由开发者显式编写，看得见摸得着。而在MVVM模式中，ViewModel和View之间通过数据绑定机制自动同步，ViewModel里的字段一旦变化，绑定了该字段的UI控件立即自动更新，写起来的确很爽，少了一大截样板代码。

但是给View加上自动数据绑定之后，我遇到过一个比较隐蔽的坑：数据流变得隐式。出了bug或者逻辑不对的时候，你需要沿着绑定链去追踪是哪一层的数据更新触发了UI改变，排查成本比MVP直接看方法调用明显更高。MVVM的学习门槛也是它的一个成本：RxJava、协程或者Jetpack Compose这些技术栈各有各的绑定和生命周期机制，新手从MVP转到MVVM，很容易把业务逻辑写进可观察对象里，弄出一个难以维护的"大杂烩"。

面试里的稳妥答法是：对MVVM不要持有偏见，也不要无脑吹。一句"MVVM在中小型页面和表单场景下能极大减少样板代码，但隐式数据流会提高排查门槛，在复杂项目中需要对数据流向有更强的把控能力"就足够展示你的深度了。如果要我再加一点，我会补上自己在项目中因为数据绑定的双向联动出现过多次定位困难的实例，以此说明任何架构都有它的适用范围，不存在银弹。

4. 完整案例：用MVP重写一个登录模块

4.1 定义契约类：先把交互协议写清楚

理论讲了不少，是时候看一份能直接落地的代码了。拿最常见的登录功能来演示，因为它麻雀虽小、五脏俱全——有用户交互、有异步校验、有成功跳转和错误回显，每个环节都能体现MVP的协作方式。

一个被广泛认可的习惯是先写契约类，把View和Presenter之间需要协作的方法一次性定清楚，然后再去实现具体类。这就像两人协作写代码，先商量好接口签名再各自实现，可以有效避免实现到一半发现对不上。

public interface LoginContract { interface View { void showLoading(); void hideLoading(); void onLoginSuccess(); void onLoginError(String message); } interface Presenter { void attachView(View view); void detachView(); void login(String username, String password); boolean isViewAttached(); } }

注意这个契约里没有给Model规定接口，因为Model是被Presenter直接调用的服务，它不需要回头看View。实际开发中Model层往往是一堆可复用的数据服务类，不必为每个页面单独抽象接口。

登录成功后要跳转页面，这个动作应该由Presenter触发还是View触发？很多人会纠结这个。我的建议是：跳转属于UI行为，应该由View来执行。Presenter只负责告诉View"登录成功了"，具体是跳转到哪个页面、怎么带参数，View自己决定。

4.2 Presenter的核心逻辑与生命周期应对

Presenter是整个登录模块的枢纽。它要做的事情包括：接收View传来的用户名密码、做前置校验、调用Model的登录接口、根据结果回调View。下面是核心逻辑部分：

public class LoginPresenter implements LoginContract.Presenter { private LoginContract.View mView; private UserDataSource mDataSource; private CompositeDisposable mDisposables = new CompositeDisposable(); public LoginPresenter(UserDataSource dataSource) { mDataSource = dataSource; } @Override public void attachView(LoginContract.View view) { mView = view; } @Override public void detachView() { mView = null; mDisposables.clear(); } @Override public void login(String username, String password) { if (!isValid(username, password)) { mView.onLoginError("用户名或密码不能为空"); return; } mView.showLoading(); mDisposables.add(mDataSource.login(username, password) .subscribeOn(Schedulers.io()) .observeOn(AndroidSchedulers.mainThread()) .subscribe(user -> { if (isViewAttached()) { mView.hideLoading(); mView.onLoginSuccess(); } }, throwable -> { if (isViewAttached()) { mView.hideLoading(); mView.onLoginError(throwable.getMessage()); } })); } private boolean isValid(String username, String password) { return username != null && !username.isEmpty() && password != null && !password.isEmpty(); } private boolean isViewAttached() { return mView != null; } }

这里有三个细节值得展开。

第一，attachView和detachView是一对强制配套动作。Activity在onCreate里attach，在onDestroy里detach，绝对不允许只做一半。detach的核心作用一个是置空View引用，另一个是清理还在进行中的异步任务，这样才能最大程度避免内存泄漏和"回调打到已死页面"的尴尬。

第二，每次回调前都要检查isViewAttached()。异步请求发出去的这段时间里，用户可能已经旋转屏幕导致Activity重建了，旧View已经被detach了。如果Presenter不该检查就调用旧View的方法，轻则白跑一趟，重则触发NPE或者更新了一个已经不在前台展示的界面。这个小习惯在MVP里称得上是保命级的。

第三，前置校验放在Presenter而不是View。登录按钮是否可点，什么时候弹"用户名不能为空"，这些虽然涉及界面交互，但它本质是业务规则的判断，放进Presenter方便进行单元测试。View里只做最简单的控件操作，比如把点击事件传给Presenter。

4.3 View层的实现与防泄漏处理

View的角色是"被动执行"，Activity实现LoginContract.View接口，完成界面的展示工作：

public class LoginActivity extends AppCompatActivity implements LoginContract.View { private EditText mUsernameInput; private EditText mPasswordInput; private ProgressBar mLoadingView; private LoginPresenter mPresenter; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_login); mUsernameInput = findViewById(R.id.et_username); mPasswordInput = findViewById(R.id.et_password); mLoadingView = findViewById(R.id.progress_bar); mPresenter = new LoginPresenter(new UserRepository()); mPresenter.attachView(this); findViewById(R.id.btn_login).setOnClickListener(v -> mPresenter.login(mUsernameInput.getText().toString(), mPasswordInput.getText().toString())); } @Override protected void onDestroy() { super.onDestroy(); mPresenter.detachView(); } @Override public void showLoading() { mLoadingView.setVisibility(View.VISIBLE); } @Override public void hideLoading() { mLoadingView.setVisibility(View.GONE); } @Override public void onLoginSuccess() { startActivity(new Intent(this, HomeActivity.class)); finish(); } @Override public void onLoginError(String message) { Toast.makeText(this, message, Toast.LENGTH_SHORT).show(); } }

View层的代码量虽然不大，但它和老写法最大的差异在于：没有任何业务判断。页面上不会有"如果用户名是什么就干什么"的分支逻辑，不会直接拿数据层的结果来自己处理，所有决策都交给了Presenter。这样的Activity拿到另一个开发者手里，理解成本极低，改需求时也能快速定位该动哪一层。

还有一个我踩过的细节：别忘了在onDestroy里先调用super.onDestroy()再detachView()，虽然顺序问题不大，但保持直觉一致的顺序能少一些莫名的疑虑。另外如果页面在栈里被覆盖但没销毁，onStop或onPause阶段是不需要detach的，只处理onDestroy就够了，太早detach会导致界面重新可见时逻辑状态丢失。

5. 面试高频追问：从基础概念到架构演进

5.1 常被追问的细节考点

MVP相关的面试题，除了"三层各自干什么、MVC和MVP的区别"这种基础款，我还整理过一批面试官爱追问的细节考点，提前准备能让临场反应快不少。

第一，为什么MVP的Presenter不持有Context？这个问题的核心考察你对耦合的理解。Presenter一旦持有Context，就意味着它被绑定到了Android环境，单元测试就得靠模拟器跑，而且Context本身是一个重量级对象，间接持有可能引发内存泄漏。所以中央答案是：Presenter保持纯Java，才能在普通JVM里测试，也才能和具体界面解耦。

第二，Activity旋转屏幕后，Presenter和View如何处理？标准的过渡方案是：Activity重建时，旧的View调detachView断开连接，待新Activity创建后再attachView接回去。如果Presenter持有数据和状态，它本身不销毁的话，新View重建后就能立刻拿到最新数据而不需要重新发起请求。想深入的话可以提一下ViewModelStore机制和Presenter的配合，但这属于加分项，把"attach/detach"讲清楚已经足够。

第三，MVP怎么处理网络请求的生命周期？请求在Presenter里发起，理应在Presenter里取消。用RxJava的话让Presenter持有CompositeDisposable，detach时统一clear；用协程就是持有Job并在cancel时取消。核心思想同样是那句"不要让回调打到已经销毁的View"。

第四，onSaveInstanceState和Presenter有冲突吗？这个问题问的人少，但问出来特别加分。瞬时数据（比如输入框内容）用SavedInstanceState恢复没问题；而重量级数据（比如已经加载好的列表）放在Presenter里比放在Bundle里更合适，因为Bundle有大小限制和序列化开销。能说出两者的分工，面试官的印象会明显不一样。

5.2 如何回答"MVP有什么缺点"

面试官如果只问优点，反而说明问题不深。真正有经验的面试官一定会追问缺点，这其实是在考察你有没有经历过架构演进中的权衡。

我给出的短板清单一般包含这几条，每一条也都配上应对思路。

• 代码量明显增加。原本一个Activity搞定的事，现在要拆出接口、实现类、Model，文件数目翻倍还带拐弯。好处是责任清晰了，代价是样板代码多了。应对思路是引入契约类把协议集中管理，并且不要让Model为每个页面单独抽象一个接口，多用通用数据服务。
• Presenter变胖的风险。所有业务逻辑都在Presenter里，页面一复杂，Presenter照样可能变成一个新的"上帝类"。应对思路是进一步拆分为UseCase或Interactor，保持单个Presenter只聚焦一个页面场景。
• 手动同步View状态。没有数据绑定机制，每次Presenter调用View的刷新方法都要显式书写。页面里状态多了以后，这种手动回调容易漏掉某个分支。应对思路是列出一份完整的状态清单，保证所有状态都有对应的View方法。
• View层接口粒度难拿捏。接口定义得太细，方法满天飞；定义得太粗，又退回高耦合。这个只能靠经验迭代，在重构中逐渐找到平衡点。

面试官听到你能主动说出这些缺点，并且每个缺点都有合理的应对措施时，他对你架构思维的评判会明显高于那些只背概念的人。

5.3 一分钟说清MVP的讲述框架

想给面试官留下好印象，最好的方式是把回答组织成"问题 → 方案 → 细节 → 反思"的四段式。

第一段，问题。说清楚没有架构约束时你会遇到什么：Activity越写越臃肿、业务逻辑没法脱离Android环境测试、改需求时牵一发而动全身。这个铺垫极其重要，因为它让MVP的出现显得顺理成章。

第二段，方案。一句话概括：MVP把页面拆成Model、View、Presenter三层，View和Model不直接通信，全部经由Presenter中转，交互协议用接口限定。

第三段，细节。拿出你写过的某个真实场景，比如登录模块，讲一下Contract类怎么定义、View如何实现接口、Presenter如何发起异步请求、旋转屏幕时如何处理attach和detach。这一部分是让面试官相信"你真写过"的关键证据。

第四段，反思。主动说这个方案也有代价，比如代码量增加、Presenter维护成本上升，然后补充一句"所以在实际项目里我会根据页面的复杂程度来决定是否使用MVP，而不是无脑套用"。这句话能把你的段位和只会背概念的候选人拉开差距。

6. 实践中踩过的坑：内存泄漏、胖Presenter、回调地狱

6.1 内存泄漏：MVP最容易翻车的地方

MVP最著名的坑就是内存泄漏，而且往往跟Activity和Presenter的生命周期错配绑定在一起。

举个我真实遇到过的场景。某个页面发起了一个网络请求，请求还没回来，用户就退出了。如果此时Presenter还持有Activity的引用，而这个Presenter又被请求回调持有不死，那Activity就会一直被一条泄漏链拽住，无法被系统回收。久而久之，多次进出页面后内存就不够用了。

常规解法已经在前面提到：在onDestroy时调用detachView()把View引用置空，并同时取消所有未完成的异步任务。但我想补充一个更隐蔽的细节——静态引用。有人把Presenter写成静态类的单例，想要全局复用，结果间接拿着Activity飞了一天一夜。getApplicationContext()场景至少还安全一些，但这种"静态Presenter持有Activity View"的设计最好在评审阶段就必须拦掉。

如果你在项目里排查泄漏，最直接的工具就是LeakCanary。装上之后多切换几次页面，它会在LeakTrace里明确告诉你哪个对象被谁持有，顺着引用链改掉问题即可。这个工具在面试中提一嘴也会加分，说明你有实际排查经历。

6.2 胖Presenter：当业务逻辑开始失控

MVP部署了一段时间后，另一个深有体会的问题就像水底浮出一样浮现出来：Presenter开始变胖。

页面的业务逻辑并不少——首次加载数据、下拉刷新、加载更多、空态判断、点击收藏、分享跳转……如果全部塞进同一个Presenter，它的方法数量很快就爆炸了。我在一个二手交易页面里就犯过这个错，那段时间改需求几乎全在跟大Presenter的文件长滚动条作对，每加一个功能都要小心翼翼找到对应的分支，生怕改错一个状态影响其他逻辑。

后来的经验是：当Presenter里职责超过一个"用户场景"时，就该拆分了。把一个页面涉及的业务动作拆成独立的UseCase或Interactor类，比如GetUserInfoUseCase、SubmitOrderUseCase，它们各自管理自己的数据源和异步流程。Presenter负责编排这些UseCase，而不是亲自把所有逻辑都写完。这里也有一个平衡问题：脚本规模小的页面拆UseCase反而显得过度设计，我的经验边界是——当Presenter超过两百行或者方法超过八个时，才考虑动手拆分。

6.3 异步回调的时序问题

最后一个坑在真实项目中虽然不一定频繁出现，但一旦出现往往查到人怀疑人生：回调的时序错乱。

场景还原如下：列表页快速上滑触发多次分页加载，第一次请求比第二次晚返回。如果Presenter不做控制，后发先至的数据会把前面请求回来的最新数据盖掉，列表渲染错乱。还有登录页用户连续点了两次登录按钮，发出两个登录请求，第一个失败、第二个成功，最后一个回调的状态覆盖了前一个，页面状态就无法反映真实结果。

这类问题的通用解法是引入"版本号或请求序列号"——每次新请求递增一个计数，回调回来时检查是否还是自己发起的最后一次，如果不是就直接丢弃。用RxJava的switchMap也能做到，新的请求自动取消或忽略旧的。对于时效性比较强的场景，还应该考虑给请求加超时和重试的控制，避免状态一直挂起。

面试时如果能主动提到这类时序问题，并说出自己的解决方案，会让面试官认为你不是只写过Demo级别项目的人。这也是我从垃圾代码堆里爬出来之后最想告诉后来者的一句话：架构模式的价值不在于画出来的图多好看，而在于它能不能逼你把边界问题想清楚。

7. 最后分享一点个人体会

做完这次梳理，我自己的最大收获其实不是知识本身，而是一种确认感。

以前面试时被问到MVP，我总担心答得不够"标准"，于是去背各种定义。后来发现真正让自己不慌的，不是那些定义，而是自己亲手重构过的项目——我知道三层协作时有哪些坑，知道横竖屏切换时开一个detach有多重要，知道回调先回来的数据会引发怎样诡异的界面状态。这些经验和教训是背不出来的，只能靠踩坑和复盘换回来。

所以如果你在准备面试，我的建议是：别只抱着博文和概念背，打开自己的项目，找到任何一个写了几年、还没有架构约束的页面，用MVP重写一遍，重写过程中把本篇提到的坑都故意踩一遍，再修复掉。这个动作花不了几天，但带给你的理解深度，远远超过看十篇梳理文章。

这篇文章只是帮你把"知道"变成"系统化"，真正让"系统化"变成"肌肉记忆"的，还是动手这件事本身。祝准备面试的朋友都能顺利，也希望你们在架构这条路上越走越稳。