上一篇我们说过一个反直觉的结论：手机发烫，烧的不是"算力"，而是"搬运"——Arm 官方给出的数字是 DRAM 访问每 GB/s 要付 80–100mW 的电。 这一篇把这个结论的物理基础彻底讲透：带宽到底是什么、为什么在手机上如此金贵、以及怎么用 5 分钟判断自己的游戏是不是"带宽瓶颈"。
本文是《Unity 游戏为什么发烫》系列的第 2 篇。看懂这一篇，后面讲 Overdraw、纹理压缩、后处理的所有优化手段，你都会知道它们"为什么有效"。
一、先分清三个天天被混淆的概念
很多开发者聊优化时把这三个词混着用，其实它们说的是三件完全不同的事：
|
概念 |
说的是什么 |
类比 |
常见单位 |
|
内存容量 |
能存多少数据 |
仓库面积 |
GB |
|
带宽（Bandwidth） |
每秒能搬多少数据 |
马路每小时能过多少车 |
GB/s |
|
延迟（Latency） |
一次往返要多久 |
单程耗时 |
ns |
三个概念里，"容量"是最好理解的，"带宽"是最容易被忽视的。买手机看参数都是"12GB 内存"，没人宣传"带宽多少 GB/s"——但对做游戏的人来说，带宽才是决定帧率和发热的那条命脉。
一个直观的数字对比：手机主流的 LPDDR5 带宽大约在 25–60 GB/s 这个量级，而 PC 独立显卡的 GDDR6 显存能到几百 GB/s。手机天生比 PC 窄一个数量级，而你的游戏要跑的画面，复杂度可没有低一个数量级。
二、为什么"搬运"这么贵：存储层级金字塔
要理解带宽为什么贵，得先看数据住在哪。现代芯片的存储是一个金字塔：
金字塔越往上越快越小，越往下越大越慢。关键在于：缓存（SRAM）和内存（DRAM）是两种完全不同的物理器件：
|
DRAM |
SRAM |
|
|
存一个 bit |
1 个电容 + 1 个晶体管 |
6 个晶体管 |
|
速度 |
约 100ns |
几 ns（快几十倍） |
|
容量/成本 |
便宜，能做几十 GB |
贵，只能做几 KB～几十 MB |
|
用途 |
内存（手机 LPDDR） |
CPU/GPU 的缓存 |
注意 DRAM 的第一个特点：它靠电容存电荷记 bit，电容会漏电，所以每隔几十毫秒必须把所有数据读一遍再写回去——这就是"Dynamic（动态）"的含义。也就是说，DRAM 即使没人访问它，光维持数据就在耗电。
所以 GPU 干活的真实流程是：先问缓存要数据，缓存里有（命中）就便宜快速；缓存里没有（未命中）就得去 DRAM 搬——跨芯片跑一个来回，延迟上百倍，功耗几十倍。这就是那句"一次内存访问的耗电，够 ALU 算几十次"的来历。
推论：优化带宽有两个方向——要么少搬（减少总量），要么搬得巧（让数据在缓存里挨得近、命中率高）。后面你会看到，纹理压缩走的是第一条路，Mipmap 走的是第二条路。
三、手机的先天劣势：一条马路，两家合租
PC 的架构是"各住各家"：CPU 用内存条，GPU 用独立显存，各有各的带宽通道。
手机是 SoC（System on Chip）：CPU、GPU、ISP 等模块挤在一块芯片里，共用同一块 LPDDR，走同一条总线——一家马路，两家合租，还要跟 ISP（拍照时）、基带抢路。
这带来两个直接后果：
四、移动 GPU 的自救：TBDR 架构
正因带宽金贵，移动端 GPU（Mali、Adreno）在设计上和 PC GPU 走了完全不同的路线——TBDR（Tile-Based Deferred Rendering，基于分块的渲染）：
对比一下 PC 的"立即模式渲染"——画什么写什么，帧缓冲读写全走显存。TBDR 相当于"攒一批货，用小推车在车间里倒腾完，最后只跑一趟大仓库"。Arm 官方文档明确说明：这种架构比传统渲染需要的带宽更少、功耗更低——它是被"手机带宽窄、搬运贵"逼出来的设计。
理解 TBDR 还有个实用副产品：你会明白为什么某些在 PC 上无害的写法在手机上格外致命——比如频繁切换渲染目标、大量乱序小绘制，都会破坏 tile 的批处理，让"本该一趟的搬运"变成多趟。
五、你的带宽被谁吃掉了
搬进 DRAM 又搬出来的数据，主要就三个流向：
1. 纹理采样（最大头）——片元着色器每输出一个像素基本都要读纹理。纹理越大、每像素采样次数越多（多重采样、法线贴图、光照贴图……），搬运越猛。
2. 帧缓冲读写——每个透明像素 = 读旧色 + 混合 + 写新色。Overdraw 叠 N 层，这里就乘 N。这是上一篇"搬运惯犯"Overdraw 的账单明细。
3. 全屏后处理——每个 pass 都把整屏像素读写一遍。Bloom + 景深 + Color Grading 挂三个，整屏数据就多跑六个来回（读+写各算一次）。
对着 Arm 的账本算一笔：假设 1080p、RGBA32 帧缓冲、平均 Overdraw 3 倍、再加 2 个全屏后处理 pass，每秒 60 帧——纹理加帧缓冲的搬运量很容易冲到几个 GB/s 的量级。对照 650mW 的 DRAM 功耗预算，你就知道自己为什么烫了。
六、5 分钟判断：你是不是带宽瓶颈
原理讲完了，给一个立刻能用的土办法——降分辨率测试：
把 URP 的 Render Scale 降到 0.5 跑一遍（就是改一个参数的事），观察 GPU 帧时间：
- GPU 帧时间大幅下降（比如 12ms 掉到 5ms）→ 基本是带宽瓶颈。因为像素数是平方关系：分辨率减半，像素量降到 1/4，带宽需求随之大降；
- GPU 帧时间几乎不变 → 瓶颈在别处。去查 Draw Call（CPU 提交成本）或顶点量。
为什么这招好用？因为它只精准打击"随像素数线性增长的搬运"，其他瓶颈不随分辨率变化——这是一个天然的隔离实验。顺带一提，它反过来也告诉你一件事：如果你是带宽瓶颈，那"降 Render Scale 到 0.75"本身就是最便宜的救命药（像素量降 44%），比改任何代码都快。
再补一个进阶的：真想看精确数字，Mali 机器用 Arm Streamline、高通机器用 Snapdragon Profiler，都有现成的带宽计数器（bytes/sec）——优化前后带宽降了多少，一目了然。带宽降了 40%，功耗基本同比例下降，不用拆机测电流。
七、省带宽的四大方向（后续各篇展开）
|
方向 |
手段 |
原理 |
详见 |
|
少搬 |
纹理压缩（ASTC） |
每像素字节数降到 1/9 |
第 4 篇 |
|
搬得巧 |
Mipmap |
数据在缓存里挨得近、命中率高 |
第 4 篇 |
|
别重复搬 |
减 Overdraw |
帧缓冲读写 ×N → ×1 |
第 3 篇 |
|
少生成像素 |
降 Render Scale |
像素数平方级下降 |
第 8 篇 |
八、总结
把这一篇压缩成三句话：
下一篇，我们收拾名单上的第一个惯犯：Overdraw。我会展示两幅肉眼完全一样的画面，帧率却差一倍——视觉相同、成本不同，这是全系列最"眼见为实"的一篇。
