打开活动监视器，Slack 吃了 800MB，VS Code 占 1.2GB，一个名叫「Figma Agent」的后台进程正静悄悄地消耗 600MB——它甚至不是笔者主动打开的。这是 2026 年一台 32GB 内存 MacBook Pro 上的日常。而在 2010 年的 ThinkPad 上，4GB 内存跑着 Photoshop CS5、Firefox（开了 20 个标签页）和一个完整的 LAMP 开发环境，还能剩几百兆给 Winamp 放歌。
这不是怀旧滤镜。这是 David Bushell 在《The Modern App》里用一整篇讽刺「现代编辑器」提出的问题，也是 Lobsters 上 52 个赞同背后共同的困惑：为什么硬件性能翻了十倍，软件体验反而倒退了？
设计趋同：当所有 App 共用同一张脸
打开微信、钉钉、飞书、Teams、Slack、Discord——如果把图标遮住，你能在第几秒区分它们？左侧是联系人列表，中间是聊天流，右侧是「AI 智能助手」侧边栏（关不掉的那种）。所有界面都遵循同一套逻辑：圆角卡片、弥散阴影、底部三 Tab、顶部分段控制器、每个角落都在闪烁的「✨AI✨」按钮。
这套逻辑的名字叫设计系统（Design System）。Google 有 Material Design 3，Apple 有 Human Interface Guidelines，Microsoft 有 Fluent。它们的初衷是好的——让同一平台上的 App 有一致的交互语言，用户不需要重新学习。但问题出在，当一个设计系统被跨平台框架（Flutter、React Native、Electron）不加区分地搬运到另一个平台时，它就不再是「一致性的工具」，而变成了「差异性的抹除剂」。
iOS 用户习惯了 navigation bar 左上角的返回按钮和底部 tab bar；Android 用户习惯了底部导航栏和 Material 浮动按钮。但当开发者选择用一套 React Native 代码同时交付 iOS 和 Android 时，他们面临一个现实选择：是投入额外成本维护两套平台特有的交互模式，还是让两个平台的用户都适应同一套「够用」的交互？答案几乎总是后者。结果就是，iOS App 上出现了 Material 风格的浮动按钮，Android App 上出现了 iOS 风格的半屏模态——两头不讨好。
ACM 在 2021 年发表的一项混合方法研究已经指出了这个趋势：Web 设计正在经历统计上可测量的同质化（homogenization），颜色选择、布局结构和交互模式在不同网站间的差异正在缩小。到了 2026 年，这个趋势从 Web 蔓延到了移动端，而且从「自发的趋同」升级成了「设计系统规训下的标准化」。当一个初创公司的产品经理说出「就照着 Slack 抄吧」的时候，趋同就不再是偶然——它是战略。
性能臃肿：Hello World 吃掉 80MB 的时代
设计趋同还只是审美层面的代价。真正让用户每天感受到的，是性能的塌方。
一组公开基准测试数据可以说明问题：一个简单的「Hello World」桌面应用，用原生 Swift 或 C++ 编写，内存占用大约 5–15MB。用 Electron 实现同样的功能，起步就是 60–80MB。背后的原因很直白——Electron 本质上是打包了一个完整的 Chromium 浏览器引擎，你的「Hello World」本质上是一个被迷你 Chrome 渲染的网页。对于 Slack、Teams、Discord 这类复杂应用，内存占用在长时间运行后超过 500MB 是常态。JavaScript 的垃圾回收（GC）周期每次暂停 UI 线程 50–100 毫秒——用户在打字时感受到的「卡一下」，就是 GC 在工作。更糟糕的是，Electron 应用中常见的闭包和 DOM 节点泄露会导致内存持续增长，许多用户反馈需要每周重启一次 Slack 或 Teams 才能回收被泄露的内存——这类问题在原生应用中几乎不存在。
移动端的情况稍好，但逻辑一致。Flutter 使用自绘引擎 Skia，能以一致的高帧率渲染 UI，冷启动时间控制在 200 毫秒以内。React Native 则仍然受制于 JavaScript Bridge 的通信开销——虽然新架构（New Architecture）和 Hermes 引擎在 2026 年已经显著改善了这一瓶颈，但桥接层带来的序列化开销和内存额外占用仍然无法完全消除。跨平台框架的共同承诺——「write once, run anywhere」——在工程实践中的实际含义往往是「write once, debug everywhere, and accept the performance tax」。
那么，是谁在替这些性能税买单？不是开发者。用户买的是 32GB 内存的手机和 M4 芯片的笔记本，而 App 厂商则节约了维护三套原生代码库的人力成本。性能臃肿本质上是成本转移：将本该由商业侧承担的工程成本，通过消耗用户设备的硬件资源来「化解」。
为什么没人停手？商业逻辑的三层枷锁
到这里，一个自然的问题是：这些道理开发者难道不懂吗？他们当然懂。但「懂」和「能做」之间隔着三层壁垒。
第一层：功能竞赛的无终点跑道。 现代 App 的商业模式——无论是订阅制、广告驱动还是投资人烧钱换增长——都要求产品保持「持续迭代」的姿态。一个「已完成」的 App 在资本市场叙事中是危险的，它意味着增长到头了。于是，功能膨胀（feature bloat）成为商业生存的必需品：聊天 App 要加短视频，笔记 App 要加协作，邮箱 App 要加日历，日历 App 要加 AI 自动安排会议。每一个新功能都需要新的 UI 组件、新的依赖包、新的后台线程。David Bushell 在文中调侃：「你们本来有一个好点子，把它做完不行吗？现在你们有了一万个 GitHub issue。」
第二层：跨平台的经济诱惑。 维护 iOS（Swift/SwiftUI）、Android（Kotlin/Jetpack Compose）、Web（React/Vue）三套代码库，需要的工程师数量和薪资开支大约是维护一套 React Native 或 Flutter 代码库的 2.5–3 倍。对于一家拿到 A 轮融资、需要在 18 个月内证明用户增长的初创公司来说，这个选择题的答案几乎写在投资人脸上。跨平台是财务最优解。
第三层：应用商店和平台的政策规训。 iOS App Store 和 Google Play 都越来越倾向于推荐使用最新设计语言和平台 API 的 App。Apple 的 Human Interface Guidelines 虽然不是强制性的，但不符合规范的 App 在审核过程中会被反复打回修改。Google 的 Material Design 3 与其说是一套「指南」，不如说是一个自带的组件库——开发者用官方组件拼 App，就像用乐高积木搭房子，省时省力，但搭出来的房子自然都长一样。
谁在赢？谁在输？
这是一场零和博弈吗？不完全是。跨平台框架确实降低了创业门槛。2026 年，一个三人团队用 Flutter + Firebase 可以在四周内交付一个功能完整的 MVP 并同时上架 iOS 和 Android。这在 2015 年是不可想象的。对于资源有限的小团队和新兴市场的开发者来说，这种效率增益是真实且重要的。
但代价也真实且普遍。用户得到的是：启动更慢、耗电更快、交互更不跟手的 App；需要一年一换手机、两年一换电脑才能勉强维持「流畅」的使用体验；以及——打开三个聊天 App 和两个笔记 App 之后，32GB 内存就不够用了的荒谬日常。
Cory Doctorow 用「enshittification」（平台衰败）来描述这个循环：平台先用优质体验吸引用户 → 然后牺牲用户体验来讨好商业客户 → 最终在榨干两边后走向崩溃。现代 App 显然正在这个大循环的某个阶段。区别在于，App 不是平台——用户不需要「迁移」社交网络就能换掉一个聊天软件。但吊诡的是，当所有替代品都走入了同一条臃肿的路径，用户实际上已经没有「好」的选项可以逃去。
Lobsters 讨论中，用户「nrvous」写了一段耐人寻味的话：「这个趋势越糟糕，Emacs 看起来反而越好。我几乎希望 VS Code 变得更烂，这样我就能对自己的人生选择感到满意了。」这固然是半开玩笑，但它指向了一个更深层的转变：一部分用户正在从默认的「主流 App」向精心维护的开源工具和终端工具回撤——因为这些工具没有商业动机去膨胀。
性能预算：被遗忘的传统工程纪律
在航空和嵌入式软件领域，有一个概念叫「性能预算」（performance budget）——开发者必须在设计阶段就明确系统有多少 CPU 周期、多少内存、多少功耗可用，然后在每个迭代中严格监控，超标即驳回。这个纪律在消费级 App 开发中几乎完全消失了。
为什么？因为惩罚机制不存在。如果一个 SpaceX 火箭的飞控软件内存泄露，火箭会炸，工程师会被追责。如果一个聊天 App 内存泄露，用户只是觉得「手机该换了」。没有反馈回路来纠正臃肿，臃肿就变成了系统性的默认状态。
笔者的判断是，这个问题不会通过 App 厂商的自我约束来解决，因为约束它意味着主动放弃竞争优势（功能少 = 「落后」）。可能的改善来自两个方向：一是平台层面更激进的内存和功耗限制（iOS 已经在后台任务管理上比 Android 更严格，效果显著）；二是如 Tauri 这样的新一代框架——用操作系统的原生 WebView 替代打包 Chromium，将安装包从几百兆压缩到 10MB 以内，空闲内存控制在 30–40MB。但 Tauri 目前只覆盖桌面端，移动端还没有成熟方案。
David Bushell 的文章结尾是无奈的：「I used to enjoy making things on a computer :(」——这句话翻译过来是：技术本该让创造变得更有趣，而不是让创造者觉得被工具吞噬。
这也许是整场讨论里最值得记住的一句。
以上分析基于 David Bushell 的《The Modern App》原文、Lobsters 社区讨论、公开的性能基准数据（包括 Electron 官方文档、Flutter 与 React Native 基准测试、及 ACM 设计同质化研究），以及笔者对移动开发生态的持续观察。文中不涉及任何闭源 App 的内部实现细节。
参考链接：