1. 内存优化概述：为什么内存优化重要、内存占用过高的常见原因、优化目标设定（降低50%）

1.1 为什么内存优化这么重要？

说实话，我见过太多项目死在内存上。

几年前我接手过一个视频处理应用，功能都写好了，一跑就崩。用户反馈说「打开三个视频就闪退」。我查了一下，好家伙，单进程内存占用 1.2GB。用户手机总共才 4GB 内存，后台还有、支付宝在抢资源。你说它能不崩吗？

内存优化不是「锦上添花」，而是「雪中送炭」。我个人习惯把内存问题分成三个层次来看：

• 稳定性层面：内存占用过高，系统就会杀进程。OOM（Out Of Memory）是线上崩溃的头号杀手之一。我在项目中遇到过，某次大促活动页因为一个图片缓存没控制好，直接导致首页白屏率飙升 15%。
• 用户体验层面：内存吃紧，系统就开始「卡」。你滑动列表时掉帧、切换页面时白屏、应用切到后台再回来就重启——这些十有八九是内存问题。用户不会说「你内存泄漏了」，他们只会说「这 App 真垃圾」。
• 商业成本层面：这个很多人容易忽略。你想想看，如果你的应用在低端机上跑不动，就等于放弃了 30%-40% 的用户。尤其是在东南亚、非洲这些新兴市场，低端机是主流。优化内存，说白了就是在拓展你的用户盘子。

1.2 内存占用过高的常见原因

做优化之前，得先知道「钱花哪儿了」。我总结了五个最常见的「内存黑洞」：

原因分类	典型场景	影响程度
图片资源失控	原图直接加载、不做压缩、不做缓存淘汰	★★★★★
数据缓存膨胀	列表数据无限堆积、数据库查询结果全量缓存	★★★★☆
对象泄漏	静态集合持有 Activity、Handler 未解绑、监听器未注销	★★★★☆
序列化/反序列化开销	JSON 解析产生大量临时对象、频繁 GC	★★★☆☆
线程与协程滥用	无限制创建线程、协程作用域未取消	★★★☆☆

嗯，这里要注意。很多人一上来就盯着「对象泄漏」猛查，结果发现泄漏修完了，内存还是高。为什么？因为大头根本不在泄漏，而在「不该存的东西存太多了」。我曾经帮一个团队做优化，他们花了两个月查泄漏，内存只降了 8%。后来我把图片缓存从 LRU 改成基于文件大小的淘汰策略，内存直接降了 35%。

1.3 优化目标设定：降低 50% 可行吗？

你可能会问：「降低 50%？吹牛吧？」

我负责任地告诉你，对于大多数没有做过系统优化的应用来说，降低 50% 是完全可行的。为什么？因为大多数应用的内存管理都处于「原始状态」——图片原图加载、数据不压缩、缓存不设上限、对象随意创建。

我自己带过的项目中，有一个社交应用，优化前内存峰值 480MB，优化后稳定在 210MB 左右。降幅 56%。怎么做到的？其实就三板斧：

1. 图片压缩 + 采样加载：把 4000x3000 的原图缩放到屏幕尺寸，内存从 48MB 降到 2MB。
2. 数据序列化改用 Protobuf：JSON 解析的临时对象减少 70%。
3. 缓存分层 + 容量上限：内存缓存上限设为 32MB，超出部分走磁盘。

你看，没有一个是「黑科技」。都是基本功。但基本功做到位了，效果立竿见影。

1.4 本章知识体系

下面这张图，是我梳理的「内存优化全景图」。你可以把它当成整个课程的地图。后面每一章，都会对应到图中的某个具体节点。

1.5 设定你的优化目标

最后，我想给你一个具体的行动建议。别把「降低 50%」当成一个口号。把它拆成可执行的指标：

• 峰值内存：应用在典型使用场景下的最大内存占用。目标：降低 50%。
• 平均内存：日常操作中的稳态内存。目标：降低 40%。
• GC 频率：每分钟 GC 次数。目标：降低 60%。
• OOM 率：线上 OutOfMemory 崩溃率。目标：降低 90% 以上。

拿个本子记下你现在的基线数据。没有基线，就没有优化。我曾经见过一个团队，优化做了三个月，问他们「降了多少」，答不上来——因为根本没测过优化前的数据。嗯，这是最典型的「白忙活」。