从 457KB 到 257MB，微信这 11 年到底往里塞了什么？

从 457KB 到 257MB，微信这 11 年到底往里塞了什么？

2011 年，微信 1.0 发布。安卓安装包多大？457KB。

不是 457MB，不是 45.7MB——是连 1MB 都不到的 457KB。大半个软盘就装得下。

2022 年，微信 8.0.24，安装包 257MB。

11 年，膨胀了 575 倍。

这不是巧合。把 QQ、支付宝、抖音、美团这些国民级 App 排一排，你会发现同一个规律：10 年前的 App 像个瑞士军刀，现在的 App 像个瑞士军刀+电饭煲+吸尘器+游戏机。

我不是来批判的。我是来扒一扒——这些体积到底去哪了？

代码的「熵增」

先说最直观的：代码本身在变多。

B 站有个叫「科技老男孩」的 UP 主，用逆向工程拆了微信的安装包。结果很有意思：

• 2011 年，微信 1.0：199 个文件，实现聊天核心功能
• 2022 年，微信 8.0.24：12639 个文件，代码量暴涨 500 多倍

这还只是文件数。实际上，现代 Android App 的开发方式已经和十年前完全不同了。

十年前写 App，Java + 原生控件一把梭。现在呢？

• Kotlin 替代 Java（更大的运行时）
• Jetpack Compose 声明式 UI（更多依赖注入）
• 第三方 SDK：推送、统计、IM、支付、地图、人脸识别……每个 SDK 都是几十 MB
• Gradle 构建的依赖树：你引入一个库，它再拉五个库，五五二十五

我见过一个 "Hello World" 级别的新项目，依赖项拉完直接 50MB。代码一行没写，包先半个微信了。

这就是现代移动开发的「基础设施税」——你还没开始写功能，框架先吃掉你 1/5 的安装包。

图片：无声的杀手

你可能没注意到，微信安装包里体积最大的不是代码——是图片资源。

拿微信 8.0.24 来说，res 目录下光各种图标、背景图、引导图、表情包预览图加起来就占了将近 100MB。

而且为了适配几百种安卓机型的分辨率，同一张图要存好几套：

• mdpi（1x）
• hdpi（1.5x）
• xhdpi（2x）
• xxhdpi（3x）
• xxxhdpi（4x）

一张 100KB 的图标，五套分辨率下来就是 500KB。 一百张这种图，50MB 没了。

你手机里那几百个 App，每个都是这么干的。叠在一起，几个 G 就这么「图」不见了。

跨平台框架的「原罪」

但微信还算好的——它至少是原生开发。

你知道现在多少 App 用的是 Flutter 或者 React Native 吗？

这两个东西解决了「写一套代码跑 iOS 和 Android」的问题，但它们有自己的代价：

Flutter 自带 Skia 渲染引擎和 Dart 运行时。你啥都不写，一个 Flutter 空项目打包出来就是 20MB+。这 20MB 是引擎——每一行你写的代码都在这 20MB 之上垒加。

React Native 的自带 JavaScript 引擎和 Metro bundler 同样是几 MB 起步。

更骚的是有些团队用 Flutter + WebView + 原生混合开发——三重套娃。一打开 App，三个渲染系统同时工作在屏幕上。好不好用另说，体积翻倍是实打实的。

为什么有的 App「修一个小 bug 更新包就是 100MB」？因为改了一行 Dart 代码，整个 Flutter 引擎得重新打包。

热更新和动态下发：看起来聪明，实际在堆屎山

原生开发还有个骚操作叫「热更新」。

App 发出去之后发现 bug 了，不想重新发版（应用商店审核慢），就搞了个动态脚本引擎——往 App 里塞一个 Lua 或 JavaScript 的解释器，然后服务器下发补丁代码，App 启动时下载执行。

腾讯的 Tinker、阿里的 Sophix、美团的 Robust……每家巨头都有自己的热更新方案。

好处是修 bug 快。坏处是：

• 解释器本身好几 MB
• 补丁代码越堆越多，旧的还没清
• 最终变成「App 里有 App」——原生代码跑一套，动态脚本跑另一套

开发者爽了，用户手机哭了。

你删不掉的缓存

说到存储空间，安装包只是冰山一角。真正吃空间的，是 App 运行后产生的缓存和数据。

还是说微信：

• 聊天记录：图片、视频、文件不会自动删，全部缓存在本地
• 朋友圈：你刷过的图片都会缓存下来
• 小程序：每个小程序都是一个独立的小型 App
• 视频号：预加载的视频内容
• 微信内置浏览器缓存：之前打开的所有网页的资源

一个重度用户手机上，微信占 10GB~30GB 是非常常见的事情。

这其实是个产品设计的取舍问题：要「流畅体验」→ 就得多缓存。要「节省空间」→ 用户每次打开都得重新加载，卡到爆。

微信选择了前者。几乎所有大厂 App 都选了前者。

所以到底是谁的问题？

我们回头看一句话：「小而美」。

张小龙在 2011 年说的。那时候微信真的美，真的小。

但现在你再打开微信——视频号、直播、购物、支付、小程序、看一看、搜一搜、问一问、听一听……这不是一个聊天软件，这是一个操作系统。（微信团队自己内部就叫它「微信 OS」。）

不是微信变大了，是微信从一个功能变成了一整个平台。

同样的道理适用于支付宝（聊天+理财+借贷+支付+公益+团购+……）、美团（外卖+酒店+旅游+买菜+电影+充电宝+……）、抖音（短视频+购物+外卖+社交+游戏+……）。

每个超级 App 都想成为你手机里唯一那个 App。

结果就是：你手机里装了五六个「半套操作系统」，每个都在互相竞争你的注意力和你手机的存储空间。

有解吗？

技术上其实有解。

App 动态化加载做得好一点、图片压缩狠一点、缓存清理策略聪明一点、不走跨平台套壳、每年主动清理技术债——这些都能显著瘦身。

但问题是：没有商业动力。

对产品经理来说，「加功能」= KPI，「瘦身」= 风险（万一哪里崩了呢）。

对开发来说，「堆代码」= 完成任务，「重构精简」= 不涨工资还容易背锅。

所以最后的结果就是：App 就像你租房越住越满的衣柜——东西只会往里塞，不会往外扔。

直到有一天，你的手机弹窗：「存储空间不足，请清理后再试。」

你打开存储管理一看——好家伙，一个微信，32GB。

首发于公众号「星链圈」。技术不只是参数和代码，也是你每天都能感受到的那些事情。