一、性能优化全景图：从“能跑”到“跑得爽”
做Android开发这么多年，我见过太多“能跑就行”的项目。说实话，让App跑起来不难，难的是让用户觉得“爽”。
性能优化，说白了就是解决两个问题：快不快和稳不稳。快，指的是启动快、响应快、滑动不卡顿；稳，指的是不闪退、不OOM、不发热、不耗电。
我个人习惯把性能优化拆成五个核心维度：流畅度、启动速度、内存、电量、包体积。这五个维度不是孤立的，它们互相影响。比如内存泄漏会导致GC频繁，GC频繁又会让界面卡顿。你想想看，是不是这个理？
核心观点：性能优化不是“头痛医头”，而是系统性的工程。你需要一张全景图，知道每个维度在哪儿发力。
1.1 流畅度：用户的“第一印象”
流畅度是用户最直观的感受。你想想看，一个App如果滑动都掉帧，用户大概率会直接卸载。
衡量流畅度的核心指标是FPS（帧率）。Android系统要求每16.6ms完成一帧的渲染，也就是60FPS。一旦超过这个时间，就会出现掉帧。
我在项目中遇到过最典型的问题：某个列表页滑动卡顿，用Systrace一抓，发现是Item布局嵌套太深，measure耗时超过20ms。后来把RelativeLayout改成ConstraintLayout，卡顿直接消失。
我的习惯：每次写列表页，我都会在真机上打开“Profile GPU Rendering”看柱状图。绿色柱状图代表流畅，红色代表掉帧。如果红色柱子频繁出现，说明有优化空间。
常用的流畅度工具：
- Systrace / Perfetto：抓取系统级trace，定位卡顿发生在哪个线程、哪个方法。
- Profile GPU Rendering：开发者选项里的柱状图，直观显示每帧渲染耗时。
- BlockCanary：检测主线程卡顿，自动输出堆栈。
1.2 启动速度：别让用户等
启动速度是App的“黄金3秒”。我记得有数据说，启动时间每增加1秒，用户流失率就增加7%。
启动分为冷启动和热启动。冷启动是从进程创建到首屏显示，热启动是从后台切回前台。我们通常优化的是冷启动。
我曾经接手过一个项目，冷启动要5秒。一查，Application里做了大量初始化：图片库、网络库、数据库、推送SDK……全在主线程同步初始化。后来改成按需加载、异步初始化，启动时间降到1.8秒。
避坑指南：我曾经在Application里直接new了一个超大Bitmap作为启动图，结果导致启动时直接OOM。后来改用WebP格式，内存占用降了70%。记住，启动阶段不要做任何“重”操作。
启动速度的衡量指标：
| 指标 | 说明 | 优秀值 |
|---|---|---|
| 冷启动时间 | 从点击图标到首帧显示 | < 2秒 |
| 热启动时间 | 从后台切回前台 | < 500ms |
| 首屏渲染时间 | 首屏内容完全展示 | < 1.5秒 |
1.3 内存：App的“健康指标”
内存问题是最容易引发崩溃的。说白了，Android给每个App分配的内存是有限的，超过就会OOM。
衡量内存的核心指标是PSS（按比例分摊的内存）。我习惯用Profiler看PSS的变化曲线，如果曲线持续上升，大概率有内存泄漏。
内存优化的几个方向：
- 减少内存占用：使用更高效的数据结构，比如ArrayMap代替HashMap。
- 避免内存泄漏：注意匿名内部类持有外部引用、静态变量持有Activity、Handler未移除等。
- 合理使用缓存：LRU缓存要设置上限，别让缓存吃掉所有内存。
个人经验：我曾在项目中用LeakCanary抓到一个泄漏：一个Fragment被销毁后，它的View被一个静态的EventBus回调持有，导致Fragment无法被GC。修复后，App的OOM率从0.3%降到了0.02%。
1.4 电量：别让用户“没电”
电量优化经常被忽视，但用户很敏感。如果一个App耗电快，用户会直接卸载。
耗电大户通常有三个：WakeLock、网络请求、GPS定位。
我遇到过最离谱的情况：某个版本上线后，用户反馈手机发烫。一查，是某个第三方SDK在后台每隔5秒发起一次网络请求，而且没有释放WakeLock。后来限制网络频率、使用JobScheduler代替定时器，耗电问题解决。
我的建议：使用Battery Historian工具分析耗电情况。它会生成一个时间轴，清晰显示每个组件的耗电行为。比如你可以看到GPS在什么时间段被频繁调用。
1.5 包体积：小就是美
包体积直接影响下载转化率。我记得Google Play有数据：APK每增加1MB，下载转化率下降约1%。
包体积优化的核心思路：删、压、转。
- 删：删除无用的资源、代码、so库。
- 压：使用WebP代替PNG，使用AndResGuard资源混淆。
- 转：大图转网络加载，so库按需加载。
我曾经把一个APK从45MB瘦身到18MB。主要做了三件事：把所有PNG转成WebP（省了12MB）、删除未使用的语言资源（省了8MB）、把部分so库改成按需下载（省了7MB）。
注意：瘦身不要过度。我曾经为了减小包体积，把一些核心so库也改成按需下载，结果导致部分低端机在下载so时闪退。后来改成“首次启动后台静默下载”，问题解决。
1.6 工具链概览：工欲善其事
做性能优化，工具比经验更重要。我整理了一份常用工具清单：
| 工具 | 用途 | 适用维度 |
|---|---|---|
| Android Profiler | 实时监控CPU、内存、网络、电量 | 全维度 |
| Systrace / Perfetto | 系统级trace分析，定位卡顿 | 流畅度 |
| LeakCanary | 自动检测内存泄漏 | 内存 |
| MAT | 深度分析heap dump | 内存 |
| Battery Historian | 电量消耗分析 | 电量 |
| APK Analyzer | 分析APK组成，定位体积问题 | 包体积 |
说实话，这些工具不需要全用。我个人习惯是：日常用Profiler，卡顿用Systrace，内存泄漏用LeakCanary，电量用Battery Historian。够用了。
最后说一句：性能优化不是一蹴而就的。我见过很多团队，上线前才做优化，结果改出一堆bug。正确的做法是：把性能监控嵌入到开发流程中，每次提交都跑一遍性能基线。这样，问题在早期就被发现了。