安卓给每个应用划的内存线,十五年只涨了 16 倍

安卓手机内存 8G 足矣，反正一个应用也只能用 256M。

这个说法你可能听过不止一次，听起来特别有道理：一个应用最多吃 256M，那 8G 和 16G 有什么区别？多出来的那些钱不是白花了吗。

但它错在第一句话上。

256M 确有其事，只不过它不是应用真正用掉的内存，是系统给应用划的一块地方，行话叫 Java 堆。应用真正占的那部分，大部分在这块配额管不到的地方。今天一个微信，待在后台要几百兆，开着看视频能吃到 1.5G。多出来那一千多兆，恰恰是这张配额管不到的地方。

所以真问题不是应用能不能用超过 256M，而是这 256M 从哪来、为什么十五年几乎没动、又为什么早就不管用了。

256M 到底是谁划的

系统给应用分配内存这件事，白纸黑字写在安卓的《兼容性定义文档》里，业内简称 CDD。这份文件里有一条规定：厂商必须给每个应用分配不低于某个数的内存。

也就是说，256M 不是建议，是谷歌给所有安卓手机画的一条底线。厂商可以给更多，但不能给得更少。

更反直觉的是，这条底线居然跟屏幕有关。

你手机屏幕的像素密度越高，要求的配额就越高。一块低密度的老屏幕，对应的是 32M；一块精细的旗舰屏，对应 256M。同一年代里，这中间差了 8 倍。

而一台 16G 内存的手机，系统给应用的配额就是 256M——只占物理内存的 1.6%。

顺便一提，这张表在文档里是按屏幕尺寸分了小、普通、大、超大四档，每档下面再按密度细分。比如在超大这一档里，从最低密度的 48M 一路排到 640dpi 对应的 768M。同一台旗舰机，换个屏幕尺寸档位，能给应用的额度差出十几倍。

这条配额落到手机上，是系统文件里的几行参数：一行管着常规状态下应用能用多少，代码里叫 getMemoryClass；另一行管着申请大内存之后的上限，叫 getLargeMemoryClass。

安卓确实留了个口子，应用可以申请更大的堆。但谷歌自己都不推荐用，官方文档的原话是，不要因为内存不够就申请大堆，而且不保证给——内存紧张的机器上，申请了也一点不多给。

这张表最早只有 16M

把时间拨回 2008 年，第一台安卓手机上市，那一年系统给每个应用留的上限是 16M。

这个数字在安卓源代码里还留着痕迹，程序员写下的注释大意是：规范上说 16M，但对我们来说太大了。

往后的十五年，这张表在慢慢长。2010 年的安卓 2.3 还只有两档，低密度屏 16M，高密度屏 24M。到今天，最低一档才抬到 32M，最高到 256M，开大堆能到 768M。

听上去涨了不少。可把两件事放一起看，味道就变了。

同一时期，安卓手机的物理内存从 192M 涨到了 16G 以上，涨了大约八十多倍。而系统给应用的最低配额，从 16M 到 32M，只翻了一倍。

两条线从这儿开始分道扬镳。

安卓亲手把它关进小盒子，又亲手拿出来

那些年安卓最容易被记住的毛病，是动不动就内存不足闪退。这个毛病有一段很有代表性的来历，跟图片有关。

你手机里的每一张照片，在应用里都是一块 Bitmap，这东西的像素数据，十五年间搬过三次家。

最早的时候，像素数据放在 Java 堆外面，应用不好管它，什么时候回收全看运气。到了安卓 3.0，谷歌把它搬进了 Java 堆。好处是能跟着对象一起回收，坏处也跟着来：图片本来就是最吃内存的东西，它一进 Java 堆，就把那点配额挤爆了。安卓 8.0 又把它搬了回去。

这一进一出，安卓自己折腾了五年。

那五年，正是安卓被吐槽内存不够、后台被清、应用闪退最凶的几年。不是用户的手机内存不够，是系统把最占地方的东西，亲手塞进了那个几百兆的小盒子。

配额没怎么涨，安卓怎么就不卡了

按理说，配额涨得这么慢，安卓早该被应用撑爆。可这些年，用户抱怨内存问题的反而少了。

变化不在配额上，在运行时上。

早期那套叫 Dalvik，边跑边现编译，回收内存的活儿也干得笨。2014 年安卓 5.0 换成 ART，安装时就把一部分活干完，回收更聪明，停顿更短。

安卓不再动不动提示内存不足，靠的不是给应用多发内存，是它自己学会了省着用。

多出来那一千多兆去哪了

现在可以回答开头那个问题了。配额 256M，应用实测 1.5G，中间那一千多兆去哪了？

系统的配额只管着 Java 堆这一块。应用还有一大块内存不归它管：底层代码直接要来的内存、画图用的显存缓冲、跟系统交换数据用的共享内存，还有专门跑渲染的那条线程。这些加起来，才是应用真正的占用。

更要紧的是超限的后果不一样。

Java 堆用超了，应用会收到一个错误，程序员能抓到它。可上面那些地方用超了，应用一个提示都不会收到，系统会直接把它的进程结束掉。

你看到的现象是应用突然没了，不是跳出一个报错框。

说到这就能明白，为什么有时候手机明明还剩一半内存，切回一个刚打开过的应用，它却要重新加载。那不是你内存不够，是这套机制在做它该做的事。

十五年过去，那条线终于被重新划了一次

这里要跟另一件事分清楚。

近期安卓确实开始按总内存给每个应用划线了，前台宽松、后台更严，超了先回收、极端情况直接结束进程。这是 2026 年发生的事，谷歌和国内厂商几乎同时出手。

但那件事和 256M 无关。

CDD 那张表管的是 Java 堆的最低保障，是十五年前就写进文档、至今没怎么动过的东西。而现在新划的这条线，管的是整个物理内存，粒度完全不同。

一张是底线，一张是上限；一张 十五年没变，一张一年就换了三轮。

把它们当成同一件事，就会得出一个错误的结论：以为安卓是被逼到今年才开始管内存的。

真实情况是，安卓一直知道应用会膨胀，但它用另一套办法在忍——把图片搬出 Java 堆，把虚拟机换成更聪明的运行时，把回收做得更细。配额是十五年不动的保守承诺，运行时是持续十五年的技术补课。

这也解释了一件更要紧的事：为什么到了今天，安卓还是不敢把那张表大幅往上抬。

因为它一旦抬了，就等于承认了前面十五年的保守是错的。而现在的做法更聪明——承诺不动，办法全换，用运行时的效率去消化应用膨胀。

代价是，256M 这个数字会继续留在所有安卓手机的参数表里，安安静静地摆着，不解释，也不改。

下次你打开手机的开发者选项，看到那两行写着 getMemoryClass 和 getLargeMemoryClass 的参数时，可以知道它指的就是这张表。

它是一份十五年前的合同，签得很保守，但一直在执行。

这张表是安卓身上最老的一份文件留下的东西，比很多人现在用的手机都年轻。

关于它我还有一个没讲完的细节：当年把这个数字定下来的人，后来去了哪里。下一篇写这个。

想接着往下看，关注一下就行。