性能优化概述
移动端性能问题的根源
做Android开发这些年，我见过太多App上线后各种“扑街”。说白了，性能问题从来不是单一原因造成的。硬件资源有限、系统调度复杂、开发者习惯不同，三重夹击下，手机很容易变成“暖手宝”。
我习惯把问题分成三类：
- 硬件瓶颈：内存不足、CPU频率低、GPU渲染慢。记得有一次项目上线，低端机直接闪退，后来发现是Bitmap加载没做缩放，一张图吃掉20MB。
- 软件设计缺陷：主线程做耗时操作、布局层级过深、网络请求频繁。你想想看，一个RecyclerView嵌套三层，卡顿是必然的。
- 系统资源竞争：后台进程抢占CPU、内存碎片、IO等待。Android进程优先级那个坑，我曾被它害得不轻。
核心观点：性能问题的本质是“资源供不应求”。App需要的东西，系统给不了或给得慢，于是就卡了。
用户体验的隐形杀手
用户体验这件事，说白了就是“快、稳、省”。帧率低于30fps，用户立刻能感觉到卡顿。我做过一个实验，把按钮点击响应从100ms拖到300ms，留存率掉了8%。
- 卡顿与掉帧：每次垂直同步间隔内没完成渲染，画面就“跳一下”。用户会怀疑手机坏了。
- 内存泄漏：Activity无法回收，内存像漏水的桶。我调过一个App，连续打开20次页面就OOM。
- 耗电与发热：频繁唤醒CPU、过度定位、持续联网。夏天手机会烫到不敢握。
- 网络延迟：DNS解析慢、请求超时、数据量过大。用户等3秒没反应，大概率就关掉了。
避坑指南：我曾经遇到一个诡异bug——列表滑动偶尔卡顿，查了三天发现是系统因内存紧张频繁触发GC。后来我们做了对象池，卡顿直接消失。
优化目标与核心衡量指标
优化不是盲目炫技。我建议先定目标，再找指标。这章我们只讲“衡量的尺子”，后面再教你怎么用工具。
| 指标 | 说明 | 目标值参考 |
|---|---|---|
| 帧率（FPS） | 每秒渲染帧数，掉帧时立即反映 | 稳定60fps，最低不低于30fps |
| 内存占用 | PSS、RSS、堆内存等 | 避免OOM，闲置时尽量低于200MB |
| CPU使用率 | 主线程与后台线程占比 | 空闲<5%，负载峰值<60% |
| 网络延迟 | 首包时间、请求耗时、吞吐量 | 首包<1s，失败率<1% |
| 启动时间 | 从点击图标到可交互 | 冷启动<5s，热启动<1.5s |
| 耗电速率 | 每小时耗电百分比 | 正常使用<5%/h |
嗯，这里要注意：指标不是死数字，要结合机型、网络环境、用户场景来看。比如抖音这类视频App，掉帧容忍度就比新闻阅读App高。你自己的App，心里要有个谱。
衡量指标深度解读
我常跟团队说：没有数据就没有优化。你感觉卡，但用户可能还行；你觉得流畅，中低端机可能卡成狗。所以指标必须量化。
- 帧率（FPS）：用Choreographer或Systrace抓。掉帧时关注“丢帧数”而非平均FPS。我见过有些项目只看平均值50fps，但掉帧波形有大量抖动，那是假平稳。
- 内存：关注Java堆、Native堆、PSS。GC频繁时，看Allocation Tracker。我说过一句话：内存泄漏就像漏雨的屋顶，不修迟早塌。
- CPU：用top或SimplePerf。分析主线程是否有长时间task。一次定位问题，我们发现某SDK在后台每5秒做一次JSON解析，CPU直接飙到20%。
- 网络：抓包看首字节时间、传输速率。DNS解析慢可以用HTTPDNS解决。记住，网络优化是性价比最高的优化之一。
注意：不要只盯着一个指标优化。比如把动画帧率调高但导致CPU满载、发热更严重，那就得不偿失。性能优化是系统工程，要找到平衡点。
小结：优化思维框架
这一章我们理清了理念：问题成因 → 用户体验 → 优化目标 → 衡量指标 → 优化手段。后面的章节会逐一深入工具使用、代码优化、布局优化、内存治理、网络加速、启动优化等。
最后分享一个经验：性能优化不是一次性工作，而是持续迭代的过程。每次版本发布前，跑一轮自动化性能测试，定个“红绿灯”指标。过了就发，不过就回炉。简单粗暴，但非常有效。