移动端内存与显存预算
自动关联目录:移动端内存与显存预算
1. 定位
移动端的内存是硬约束:超了不是变慢,是直接被系统杀掉。所以预算必须在项目早期就定死。
一句话定位:先定预算,再倒推每个类别能占多少——而不是做完再祈祷不超。
2. 定预算
| 步骤 | 说明 |
|---|---|
| 1. 确定最低配机型 | 它的可用内存是上限 |
| 2. 留安全边界 | 系统与其它应用要占一部分,不要按标称值算 |
| 3. 分类配额 | 纹理 / 网格 / 动画 / 音频 / 渲染目标 / 引擎底噪 |
| 4. 写入 CI | 超配额报警(见 包体分析的同款做法) |
常见做法:以最低配机型的可用内存为基准,再打个折扣作为引擎可用上限。
3. 各分类与优化方向
| 类别 | 优化方向 |
|---|---|
| 纹理 | 见 移动端纹理与压缩(通常最大) |
| 网格 / LOD | LOD 套数、顶点精度 |
| 动画 | 见 动画压缩与内存 |
| 音频 | 见 音频资源与流式 |
| 光照贴图 | 见 光照与烘焙 |
| 渲染目标 | 分辨率、数量、精度(Mobile HDR 影响大) |
| 着色器 / PSO | 变体数量、PSO 保留(见 PSO 预缓存) |
4. 显存侧要点
| 项 | 说明 |
|---|---|
| 渲染目标 | 分辨率与格式决定显存;Mobile HDR 会显著增加(见 移动端渲染) |
| MSAA | 多样本缓冲占显存,移动端一般不用 |
| 深度/模板 | 精度选择 |
| 纹理流送池 | 需要单独配额 |
Mobile HDR 是显存的一个关键开关:开着需要更高精度的 RT,关掉可以省一大块——但会失去部分效果。这是移动端最典型的取舍之一。
5. 压测方式
| 做法 | 说明 |
|---|---|
| 在最低配机型测 | 不是开发机、不是高配机 |
| 跑完整流程 | 进关卡、战斗、传送、反复进出(查泄漏) |
| 记录峰值 | 平均值没意义,OOM 看的是峰值 |
| 用平台工具 | Android Studio / Xcode(见 UE性能优化工具) |
结合 memreport | 引擎内部账与平台账对照(见 内存剖析) |
"反复进出关卡内存只增不减"是泄漏,不是预算问题——先分清这两者。
6. 代价与权衡
| 设计 | 收益 | 代价 | 什么时候不该用 |
|---|---|---|---|
| 早期定预算 | 后期不返工 | 前期要花时间 | 从不做——这是必须的 |
| 关 Mobile HDR | 省一大块显存/带宽 | 失去部分效果 | 需要 HDR 表现时不行 |
| 严格纹理配额 | 内存可控 | 画质受限 | 核心特写资产可放宽 |
| CI 内存监控 | 防悄悄变胖 | 需要设施 | 长周期项目必须有 |
7. 踩坑与排查
| 坑 | 现象 | 怎么验证 |
|---|---|---|
| 按标称内存算预算 | OOM | 留安全边界 |
| 只在高配机测 | 低端机崩 | 最低配机型测 |
| 只看平均值 | 峰值 OOM | 记录峰值 |
| 开了 Mobile HDR 没评估 | 显存涨 | 开关对比 |
| 反复进出关卡内存涨 | 泄漏 | 见 内存剖析 |
| PSO 保留过多 | 内存涨 | 见 PSO 篇 |
| 没有 CI 监控 | 悄悄变胖 | 建趋势记录 |
8. 排查顺序
1. 定最低配机型 → 定总预算 → 分类配额
2. 按类别优化(纹理 → 网格 → 动画 → 音频 → RT)
3. 关 Mobile HDR 对比(评估效果损失是否可接受)
4. 最低配机型跑完整流程,记录峰值
5. 反复进出查泄漏(那是另一类问题)
6. CI 内存监控防回归参考
许可协议:CC BY
作者:Davids
本文链接:https://hustjjd.github.io/d5a0682c.html
更新于:2026年10月10日