企业官网建设流程全解析

1. 三种架构模式到底在解决什么问题

做了十来年Android开发，从早期一个人包揽所有模块，到后来带团队做中大型项目，我最大的感受就是：代码写到最后，拼的不是谁写得快，而是谁改得动。一个Activity动辄两三千行，改一个按钮逻辑要翻半天，加个需求就引入三个bug——这种场景我相信很多人都经历过。MVC、MVP、MVVM这三种架构模式，本质上都是在回答同一个问题：界面代码、业务逻辑、数据来源这三者，到底该怎么分工、怎么通信，才能让项目在半年后还改得动、测得起来、交接得出去。

这篇文章我打算把三种模式从头到尾捋一遍，不讲教科书上那种干巴巴的定义，而是结合我自己踩过的坑，说清楚每种模式的核心思路、代码到底怎么写、什么场景该选哪个、以及实际落地时那些文档里不会写的细节。不管你是刚接触Android架构的新手，还是已经用过这几种模式但总觉得哪里别扭的老手，应该都能从里面找到点有用的东西。

先说清楚一个前提：这三种模式没有绝对的优劣，只有适不适合当前项目阶段。一个只有五个页面的小工具，硬上MVVM加一堆框架，纯属给自己找麻烦；反过来，一个要长期迭代的复杂App，还把所有逻辑堆在Activity里，那就是给自己埋雷。所以理解它们各自的适用边界，比死记哪个"更先进"重要得多。

2. MVC模式：最直观但也最容易走样的起点

2.1 MVC的核心分工与Android上的天然错位

MVC是三种模式里最古老的，全称是Model-View-Controller。它的原始设想很清晰：Model管数据和业务逻辑，View管界面展示，Controller负责接收用户输入并协调前两者。在传统的桌面或Web开发里，这三者边界相对清楚，View和Controller往往是分开的。

但到了Android上，事情就变得微妙了。Android的Activity（或Fragment）天生就是个"缝合怪"——它既承载了界面的生命周期，又负责处理用户交互，还经常被拿来当Controller用。于是最常见的MVC落地就变成了这样：Activity同时扮演View和Controller两个角色，Model是独立的数据层。这种错位是Android MVC最被人诟病的地方，也是它容易"走样"的根源。

我见过太多项目，嘴上说着用MVC，实际上Activity里既有findViewById、setOnClickListener这种View的活，又有网络请求、数据校验、业务判断这种Controller甚至Model的活，最后Activity膨胀成一个什么都管的巨无霸。这不是MVC的错，是Android这套框架天然诱导你这么写。

2.2 一个最小可运行的MVC示例

光说概念没意思，直接上代码。假设做一个最简单的用户信息展示页面，从本地或网络拿到用户数据，显示在界面上。

Model层负责数据获取和封装：

public class UserModel { private String name; private int age; public UserModel(String name, int age) { this.name = name; this.age = age; } public String getName() { return name; } public int getAge() { return age; } // 模拟数据获取，实际可能是网络或数据库 public static UserModel fetchUser() { return new UserModel("张三", 28); } }

Activity作为View和Controller的合体：

public class UserActivity extends Activity { private TextView nameText; private TextView ageText; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_user); nameText = findViewById(R.id.name_text); ageText = findViewById(R.id.age_text); loadUser(); } private void loadUser() { UserModel user = UserModel.fetchUser(); nameText.setText(user.getName()); ageText.setText(String.valueOf(user.getAge())); } }

这段代码能跑，逻辑也清楚，但它暴露了MVC在Android上的核心问题：loadUser这个方法里，数据获取和界面更新是揉在一起的。如果后面要加缓存、加错误处理、加加载状态，这个方法会迅速膨胀。而且你没法单独测试"数据获取"这个逻辑，因为它和TextView绑死了。

2.3 MVC的适用场景与实操心得

那MVC是不是就没用了？也不是。我的经验是，MVC适合那种页面逻辑极其简单、几乎不会迭代、或者纯粹做原型验证的场景。比如一个内部工具App，就几个静态展示页，用MVC快速搭起来，两小时搞定，没必要上更重的东西。

但如果你打算用MVC，有几个坑一定要避开。第一，尽量把业务逻辑往Model层推，Activity只做"取数据、刷界面"这两件事，哪怕多写几个Model类也别让Activity变胖。第二，网络请求、数据库操作这些耗时逻辑，绝对不要直接写在Activity的回调里，要么封装成独立的Repository，要么至少抽成一个单独的方法类。第三，提前想好生命周期问题，MVC下Activity销毁时如果还有异步任务在跑，很容易内存泄漏或者空指针，这个后面讲MVP时会详细说。

提示：MVC在Android上最大的敌人不是模式本身，而是Activity的"万能"属性。你越是纵容它什么都管，代码就越难维护。用MVC时给自己定个规矩：Activity里超过200行就该考虑拆分了。

3. MVP模式：把View和逻辑彻底切开

3.1 MVP凭什么能解决MVC的痛点

MVP全称Model-View-Presenter，它针对MVC最核心的改进就一句话：把View和业务逻辑彻底解耦，中间加一个Presenter做桥梁。在MVP里，View只负责"显示"和"把用户操作转发出去"，它不关心数据从哪来、怎么处理；Presenter负责所有业务逻辑，它通过接口跟View通信，不直接持有具体的View对象。

这个设计带来的最大好处是可测试性。因为Presenter只依赖View的接口，测试时你可以传一个假的View实现进去，完全脱离Android环境跑单元测试。这一点在MVC里几乎做不到，因为逻辑和Activity绑死了。

另一个好处是职责清晰。View就是View，Presenter就是Presenter，谁该干什么一目了然。团队协作时，一个人写界面，一个人写逻辑，只要接口约定好，可以并行开发，互不干扰。

3.2 契约接口：MVP的灵魂所在

MVP落地时，最关键的设计是契约接口（Contract）。我习惯把View接口和Presenter接口写在一个Contract类里，这样一眼就能看出这个模块对外暴露了哪些能力。

public interface UserContract { interface View { void showUserName(String name); void showUserAge(int age); void showError(String message); } interface Presenter { void loadUser(); void detachView(); } }

View接口定义了"界面能做什么"，Presenter接口定义了"逻辑层能接受什么指令"。注意detachView这个方法，它是MVP处理生命周期问题的关键，后面会细说。

Presenter的实现：

public class UserPresenter implements UserContract.Presenter { private UserContract.View view; private UserModel model; public UserPresenter(UserContract.View view) { this.view = view; this.model = new UserModel(); } @Override public void loadUser() { if (view == null) return; UserModel user = model.fetchUser(); if (user != null) { view.showUserName(user.getName()); view.showUserAge(user.getAge()); } else { view.showError("加载失败"); } } @Override public void detachView() { this.view = null; } }

Activity实现View接口：

public class UserActivity extends Activity implements UserContract.View { private UserContract.Presenter presenter; private TextView nameText; private TextView ageText; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_user); nameText = findViewById(R.id.name_text); ageText = findViewById(R.id.age_text); presenter = new UserPresenter(this); presenter.loadUser(); } @Override public void showUserName(String name) { nameText.setText(name); } @Override public void showUserAge(int age) { ageText.setText(String.valueOf(age)); } @Override public void showError(String message) { Toast.makeText(this, message, Toast.LENGTH_SHORT).show(); } @Override protected void onDestroy() { super.onDestroy(); presenter.detachView(); } }

3.3 生命周期与内存泄漏：MVP最容易翻车的地方

看到detachView和onDestroy里的调用了吗？这是MVP里必须处理、但新手最容易忽略的一环。原因很简单：Presenter里持有View的引用，如果View是Activity，而Presenter又在做异步任务（比如网络请求），那么当用户退出页面、Activity该销毁时，Presenter还活着，它手里的Activity引用就导致Activity无法被回收，这就是典型的内存泄漏。

解决办法就是在View销毁时主动断开引用。detachView把view置为null，之后Presenter里所有对view的调用都要先判空。上面代码里loadUser开头的if (view == null) return;就是干这个的。

但这里有个更隐蔽的坑：异步回调的时机。假设网络请求发出去了，用户立刻退出页面，detachView被调用，view变成null。等网络请求回来，回调里如果直接调view.showUserName()，就会空指针。所以所有异步回调里都必须判空，这是铁律。

注意：detachView只是断开引用，并不能取消已经发出的异步任务。如果任务本身持有Context或者做重活，最好在detachView里一并取消，比如调用网络库的cancel方法。否则任务还在后台跑，白白浪费资源。

3.4 MVP的取舍：什么时候值得用

MVP的代码量比MVC明显多——每个模块都要写Contract、Presenter、View实现，接口一大堆。所以它适合中大型、需要长期维护、对可测试性有要求的项目。我待过的一个团队，核心业务模块全用MVP，Presenter层的单元测试覆盖率能到80%以上，改逻辑时心里特别有底，因为跑一遍测试就知道有没有破坏原有功能。

但如果是小项目，MVP的模板代码会显得很啰嗦。我个人的判断标准是：如果一个页面的业务逻辑超过三四个分支，或者需要写单元测试，就值得上MVP；如果只是展示静态数据，MVC甚至直接写Activity就够了。

4. MVVM模式：数据驱动界面的现代解法

4.1 MVVM的核心思想：让数据自己"流"到界面

MVVM全称Model-View-ViewModel，它跟MVP最大的区别在于通信方式。MVP里Presenter是主动调View的方法去更新界面，而MVVM里ViewModel不直接操作View，它只负责暴露数据，View通过观察（订阅）这些数据的变化来自动更新自己。这种"数据变了界面自动跟着变"的机制，就是所谓的数据驱动。

在Android上，实现这种观察机制的主流工具是LiveData（配合ViewModel组件）或者RxJava的Observable。Google官方推出的Android Architecture Components里，ViewModel和LiveData就是为MVVM量身定做的。ViewModel的生命周期比Activity长，能在屏幕旋转等配置变更时保留数据，这是它相对MVP的一个天然优势。

4.2 用ViewModel和LiveData搭一个MVVM

还是用户信息那个例子，看看MVVM怎么写。

ViewModel层：

public class UserViewModel extends ViewModel { private MutableLiveData<String> userName = new MutableLiveData<>(); private MutableLiveData<Integer> userAge = new MutableLiveData<>(); private MutableLiveData<String> errorMsg = new MutableLiveData<>(); public LiveData<String> getUserName() { return userName; } public LiveData<Integer> getUserAge() { return userAge; } public LiveData<String> getErrorMsg() { return errorMsg; } public void loadUser() { UserModel user = UserModel.fetchUser(); if (user != null) { userName.setValue(user.getName()); userAge.setValue(user.getAge()); } else { errorMsg.setValue("加载失败"); } } }

Activity里观察数据：

public class UserActivity extends AppCompatActivity { private UserViewModel viewModel; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_user); TextView nameText = findViewById(R.id.name_text); TextView ageText = findViewById(R.id.age_text); viewModel = new ViewModelProvider(this).get(UserViewModel.class); viewModel.getUserName().observe(this, name -> nameText.setText(name)); viewModel.getUserAge().observe(this, age -> ageText.setText(String.valueOf(age))); viewModel.getErrorMsg().observe(this, msg -> Toast.makeText(this, msg, Toast.LENGTH_SHORT).show()); viewModel.loadUser(); } }

对比一下就能看出差别：Activity里完全没有业务逻辑，只有"观察哪个数据、数据来了怎么显示"。数据怎么来的、怎么处理的，全在ViewModel里。而且observe(this, ...)里的this是LifecycleOwner，LiveData会自动感知生命周期，Activity销毁后自动停止回调，从根本上避免了MVP里那种手动detach和空指针的问题。

4.3 DataBinding：锦上添花还是必要组件

提到MVVM，很多人会想到DataBinding。DataBinding允许你在XML布局里直接绑定ViewModel的数据，进一步减少Activity里的代码。比如：

<layout> <data> <variable name="viewModel" type="com.example.UserViewModel" /> </data> <LinearLayout> <TextView android:text="@{viewModel.userName}" /> </LinearLayout> </layout>

这样连observe里的setText都省了，数据一变界面自动刷新。听起来很美，但我的实际经验是：DataBinding是可选组件，不是MVVM的必需品。它确实能减少样板代码，但代价是布局文件变复杂、编译变慢、出错时调试困难（尤其是表达式写错时，报错信息很不友好）。我见过不少团队用了一阵DataBinding后又退回到手动observe，就是因为维护成本太高。

我的建议是：小项目或者对开发效率要求高的场景，可以上DataBinding；大型项目或者团队水平参差不齐时，老老实实用LiveData加手动observe，代码更直白，出问题也好排查。

4.4 MVVM的坑：ViewModel不是万能的

MVVM虽然优雅，但也不是没有坑。第一个坑是ViewModel里不要持有View的引用。ViewModel的设计初衷就是跟View解耦，如果你在里面存了Activity或者Context，那跟MVP就没区别了，还会引入内存泄漏风险。需要Context时，用AndroidViewModel或者Application Context。

第二个坑是LiveData的粘性事件问题。LiveData有个特性：当一个新的观察者开始观察时，如果LiveData已经有值了，它会立刻把这个旧值推给新观察者。这在某些场景下是好事（比如屏幕旋转后恢复数据），但在另一些场景下是灾难（比如一个"显示Toast"的事件，旋转屏幕后Toast又弹了一次）。解决办法是用SingleLiveEvent或者事件包装类，这个细节后面讲常见问题时再展开。

第三个坑是过度设计。有些团队一上来就MVVM加Repository加UseCase加一堆分层，结果一个简单页面要写七八个类。架构是为了解决问题，不是为了炫技。按需分层，够用就好。

5. 三种模式横向对比与选型决策

5.1 一张表看清核心差异

这张表不是让你照着选，而是帮你快速定位。比如你手上是个要快速验证想法的小Demo，看第一列和最后一行，MVC就够了；如果你在做一个要维护两三年的核心业务，看可测试性和生命周期那两行，MVVM或者MVP更合适。

5.2 选型时我实际会问自己的几个问题

光看表格还不够，实际选型时我会问自己几个更具体的问题。第一，这个项目要活多久？如果只是临时工具，别折腾架构。第二，团队里几个人？水平如何？如果新人多，MVP的接口约束反而比MVVM的响应式更容易上手，因为它是命令式的，逻辑一眼能看懂。第三，有没有历史包袱？如果项目已经用MVC写了一年，全面重构风险太大，可以考虑新模块用MVP或MVVM，老模块逐步迁移，别一刀切。

还有一个很现实的考量：招人成本和生态。现在市面上MVVM的资料和框架最丰富，新人学习路径也最成熟。如果你的团队要扩招，MVVM的生态优势是实打实的。但如果你团队就两三个人，都是老手，那用什么模式其实差别不大，关键是约定统一、执行到位。

5.3 混合使用：现实项目里的常态

说个可能让教科书作者不高兴的事实：真实项目里很少纯用一种模式。我做过的一个项目，列表页用MVVM（数据驱动，刷新频繁），表单页用MVP（交互复杂，逻辑分支多），一些静态页直接MVC。这不是不专业，而是根据页面特点选最顺手的工具。

架构模式是手段不是目的。目的是让代码可维护、可测试、可协作。只要达到这个目的，混着用完全没问题。反倒是那些为了"架构纯洁性"硬套一种模式的项目，经常写得别扭又难改。

6. 实操中的常见问题与排查技巧

6.1 内存泄漏：三种模式都可能中招

内存泄漏是Android架构里绕不开的话题，三种模式各有各的漏法。MVC里最常见的是匿名内部类持有Activity引用，比如在Activity里new一个Thread或者Handler，任务没结束Activity就销毁了，引用还在。MVP里是Presenter持有View引用但没detach。MVVM里相对少，但如果ViewModel里存了Context或者View，一样会漏。

排查内存泄漏我一般用LeakCanary，集成简单，跑起来自动检测，报告也直观。定位到泄漏点后，对症下药：MVC里把内部类改成静态内部类加弱引用，MVP里确保detachView被调用，MVVM里检查ViewModel有没有持有不该持有的东西。

提示：detachView一定要放在onDestroy里，而且要在super.onDestroy()之前调用。放错位置或者忘了调，泄漏就找上门了。

6.2 配置变更导致的数据丢失

屏幕旋转、切换语言这些配置变更，默认会重建Activity。MVC和MVP下，如果数据存在Activity里，重建后就没了，得重新加载。MVP可以把数据暂存在Presenter里，但Presenter本身也可能被重建。MVVM的ViewModel天生就是干这个的——它在配置变更时不会被销毁，数据自然保留。这也是我推荐新项目用MVVM的重要原因之一。

如果非要用MVP处理这个问题，可以用onSaveInstanceState手动保存，或者把Presenter做成单例（但要小心泄漏）。相比之下MVVM的方案优雅得多，几乎零成本。

6.3 LiveData粘性事件引发的重复响应

前面提过这个坑，这里展开说。假设你用LiveData发一个"显示Toast"的事件，用户旋转屏幕，Activity重建，新的观察者订阅时LiveData会把旧值再推一次，Toast又弹一遍。用户会觉得莫名其妙。

解决办法是把事件和状态分开。状态（比如用户名）用普通LiveData，粘性无所谓；事件（比如Toast、导航）用SingleLiveEvent，它只把值推给第一个观察者，推完就消费掉。SingleLiveEvent的实现不复杂，核心是用一个AtomicBoolean标记是否已消费。或者用更现代的Channel/Flow方案，Google现在更推荐用Kotlin的Flow来处理事件流。

6.4 常见问题速查表

这张表是我这些年排查问题时总结的，基本覆盖了八成以上的常见故障。遇到问题先对号入座，能省不少时间。

7. 我个人的一些实操体会

架构这东西，看再多文章不如自己动手写一遍。我的建议是，拿一个你熟悉的小功能，用三种模式各实现一遍，写完你自然就明白它们的差别在哪、痛点在哪。光看代码示例是体会不到MVP那一堆接口的繁琐，也感受不到MVVM数据驱动的那种顺畅的。

另外，别迷信"最佳实践"。网上很多文章把某种模式吹得天花乱坠，但那是建立在特定项目背景下的。你的项目规模、团队水平、迭代节奏跟别人不一样，照搬往往水土不服。架构选型的本质是权衡，是在可维护性、开发效率、学习成本之间找平衡点。

最后分享一个小技巧：不管用什么模式，先把接口或者数据契约定下来。MVP的Contract、MVVM的ViewModel暴露的LiveData，本质上都是契约。契约定好了，界面和逻辑可以并行开发，测试可以提前写，后期改动也有据可依。这一步花的时间，后面会加倍还给你。