iOS应用架构设计：MVC、MVVM、VIPER对比 —— 一个被裁后回老家前的深夜复盘
去年十月，北京深秋。凌晨两点，我蹲在出租屋阳台抽着烟，左手是刚收到的裁员邮件截图，右手是老家HR发来的offer——月薪15k，包三餐，双休。房租3500的房子还没退，老婆在微信里问：“要不要回来？孩子快上幼儿园了。”
那一刻，我盯着电脑屏幕上一堆乱成蜘蛛网的ViewController代码，突然意识到：六年大厂生涯，我到底学会了什么？除了会写“优雅”的爬虫脚本抢演唱会门票，是不是连最基础的iOS架构都没搞明白？
今天不聊职业焦虑，也不劝你“逃离北上广”。就聊聊这几年在真实项目里踩过的坑——关于MVC、MVVM和VIPER这仨“祖宗”，到底该怎么选。
起点：MVC不是原罪，但用不好就是屎山
2018年刚进大厂那会儿，组里有个老哥指着一个3000行的UserCenterViewController说：“这叫经典MVC，苹果亲儿子。”
我当时信了。
结果呢？业务一复杂，View和Controller直接耦合到一起。UI刷新逻辑混在数据请求回调里，测试？别想了，跑个单元测试要启动整个App。更离谱的是，有次产品临时改需求，说“用户头像点击要跳转到爬虫抓取的社交动态页”——好家伙，我硬是在VC里塞了个网络层+解析HTML的逻辑，还用了正则匹配（别骂了，是真的）。
开发心得第一条：MVC本身没问题，问题出在人。
如果你的VC只负责协调View和Model，把业务逻辑剥离出去，它依然是轻量又高效的。但现实中，90%的团队都把它玩成了“Massive View Controller”。我后来统计过，我们那个App里70%的Crash都来自VC生命周期管理混乱——dealloc没清delegate、block循环引用、异步回调时View已经销毁……
转折：MVVM让我以为找到了救世主
2020年，团队决定重构核心模块。技术组长拍板上MVVM，“解耦！可测试！响应式编程YYDS！”
于是我们引入RxSwift（后来换成Combine），ViewModel负责所有逻辑，View只管绑定。
刚开始真香。比如做商品详情页，ViewModel拉数据、处理缓存、格式化价格，View只监听几个Published属性。单元测试覆盖率从12%飙到60%，连QA都夸我们“这次没半夜call她”。
但很快问题来了。
首先，学习成本高。新来的实习生一脸懵：“为什么改个按钮颜色要写三个binding？” 其次，过度抽象。为了“纯粹”，我们甚至把简单的点击事件也扔进ViewModel，导致ViewModel膨胀得比原来的VC还大。最搞笑的是，有次为了抓取竞品价格，我在ViewModel里嵌了爬虫逻辑——对，你没看错，一个本该“无状态”的ViewModel，偷偷调了URLSession + HTML解析库。同事吐槽：“你这是MVVM还是MVCVMVVM？”
开发心得第二条：MVVM适合数据驱动型页面，但别为了模式而模式。
如果你只是做个静态展示页，硬套RxSwift纯属自虐。而且记住：ViewModel不该持有View的引用，更不该碰UIKit。否则，你只是把Massive VC换成了Massive VM。
冒险：VIPER——大厂炫技，小厂劝退
2022年晋升答辩前，我想搞点“高大上”的东西。于是盯上了VIPER（View, Interactor, Presenter, Entity, Router）。
理论上，它把职责拆得明明白白：View只管UI，Presenter处理逻辑，Interactor干脏活（比如调API、数据库、甚至……爬虫），Router管跳转。
我拿一个订单跟踪页试水。代码结构确实清爽，每个文件不超过200行。测试也方便——Mock Interactor就能测完整链路。
但现实很骨感。
第一，代码量爆炸。一个简单页面要建5个类，光文件命名就吵了三天（“Interactor放Network层还是Domain层？”）。第二，沟通成本飙升。产品改个需求，前端要改View、Presenter、Router三处；后端接口字段变了，Interactor和Entity都得动。第三，性能开销。多层转发导致帧率掉得肉眼可见，尤其低端机上。
最崩溃的是上线前夜。因为Router跳转逻辑写错，用户点“查看物流”直接闪退。排查三小时，发现是Presenter没正确传递参数给Interactor——而这一切，仅仅是因为我们想“严格遵循VIPER规范”。
开发心得第三条：VIPER适合超大型、多人协作、长期维护的项目。
如果你团队不到10个人，或者App生命周期就一两年，别碰它。你省下的架构时间，够你重写三次MVC。
回到现实：没有银弹，只有权衡
上周五晚上，我和老婆视频。她说：“老家那家公司主要做政务App，稳定，但技术栈老。”
我翻了翻他们GitHub（是的，我偷偷看了），果然是纯MVC，连Swift都还没全切。
但我突然不焦虑了。
因为在大厂这些年，我终于明白：架构不是目的，交付价值才是。
- 如果你在创业公司，赶着上线抢市场，MVC+合理分层就够了。把爬虫逻辑封装成独立Service，别塞进VC就行。
- 如果你在中型团队，追求可维护性，MVVM+Combine是甜点。但记得给新人写模板，别让他们自由发挥。
- 如果你在银行/航空这类超大型系统，且有专职架构师，VIPER可以考虑——但务必配套严格的Code Review和文档。
前端也好，iOS也罢，技术永远服务于业务。
我见过用MVC写出百万DAU精品App的团队，也见过用VIPER做出半成品就烂尾的项目。关键不在模式，而在人是否清醒。
尾声：回老家，还是留下？
昨天，我接受了老家的offer。月薪15k，但通勤10分钟，孩子能天天见到爸爸。
临走前，我把那套混合架构方案交给了接任的同事：核心交易流程用MVVM保证可测性，营销活动页用MVC快速迭代，只有后台管理系统尝试VIPER（反正没人催进度）。
有人问我后悔吗？
不后悔。大厂教会我技术深度，生活教会我技术之外的东西更重要。
如果你也在纠结架构选型，别光看理论。问问自己：
- 团队有多少人？
- 项目生命周期多长？
- 下个版本 deadline 是什么时候？
答案比任何设计模式都重要。
最后送句实在话：别让架构成为你逃避业务复杂度的借口。
毕竟，连爬虫都能写进ViewModel的人，还有什么理由说自己不懂解耦呢？
（完）
P.S. 老家房子首付还差8万，如果有朋友需要兼职做iOS架构咨询，私聊。支持远程，时薪按北京打七折，但必须双休。
评论 0