一、性能优化全景图：为什么要做性能优化？

说实话，我刚开始做Android开发那会儿，对性能优化这事儿真没太当回事。

那时候觉得，功能能跑起来不就行了？直到有一次，我负责的一个电商App上线后，用户反馈说「打开商品详情页要等3秒，卡得想摔手机」。嗯，那是我第一次被性能问题逼到加班到凌晨三点。

从那以后我明白了——性能不是锦上添花，而是生死线。

1.1 为什么要做性能优化？

你想想看，用户装一个App，打开后卡顿、闪退、加载慢，他会怎么想？

我见过太多项目，功能做得花里胡哨，结果因为启动慢被用户直接卸载。说白了，性能就是用户体验的底线。

我个人习惯把性能优化比作「给房子做体检」——平时不查，等漏水了再修，代价就大了。

1.2 性能优化的核心指标

做优化不能凭感觉，得有数据说话。我常用的几个核心指标，咱们一个一个说。

1.2.1 FPS（帧率）

FPS就是每秒画面刷新的次数。Android系统要求每16ms绘制一帧，也就是60FPS。

低于60FPS，用户就会感觉到卡顿。低于30FPS，基本就没法用了。

1.2.2 内存

内存问题最头疼。为什么？因为OOM（内存溢出）是直接Crash，用户根本不给第二次机会。

我常用的内存指标：

• PSS（实际占用物理内存）：这个值超过应用本身需求太多，就要警惕了
• GC频率：频繁GC会导致卡顿，尤其是并发GC
• 内存泄漏：Activity泄漏是最常见的，我排查过最离谱的一个案例——一个单例持有Activity引用，导致用户切换了20个页面后直接OOM

1.2.3 CPU

CPU占用过高，直接导致手机发热、耗电快、卡顿。

我一般关注两个维度：

• CPU使用率：超过80%就要警惕了，尤其是UI线程
• 线程数：线程不是越多越好。我见过一个App开了50多个线程，结果大部分都在等待锁，CPU全浪费在线程切换上了

1.2.4 网络

网络优化是「性价比最高」的优化方向。为什么？因为改一行代码，可能就省了几百毫秒。

核心指标：

• 请求耗时：P50、P90、P99分位值
• 请求失败率：超过1%就要排查
• 数据量：接口返回的数据是不是太大了？我优化过一个接口，把JSON从200KB压缩到30KB，加载速度直接快了3倍

1.2.5 启动时间

启动时间是用户对App的第一印象。我个人习惯把启动时间分为三段：

阶段	定义	优化目标
冷启动	进程从无到有	< 2秒
温启动	进程存在，Activity重建	< 1秒
热启动	Activity从后台切回	< 0.5秒

1.3 性能优化的方法论与流程

做优化最怕什么？最怕「瞎优化」——不知道问题在哪，就乱改代码。

我总结了一套流程，用了好几年，分享给你：

1.3.1 发现问题

别靠感觉，靠工具。我常用的工具有：

• Profiler：Android Studio自带的，看CPU、内存、网络
• Systrace：看UI线程卡顿的利器
• LeakCanary：内存泄漏检测，我几乎每个项目都会集成
• 自定义埋点：线上监控FPS、启动时间、网络耗时

1.3.2 定位根因

发现问题后，别急着改。先问三个问题：

1. 这个问题是必现还是偶现？
2. 是特定机型还是所有机型？
3. 是特定场景还是所有场景？

举个例子，我遇到过一个问题：某个页面在低端机上卡顿，高端机上流畅。定位后发现是布局嵌套太深，低端机渲染压力大。嗯，这就是典型的「特定机型问题」。

1.3.3 制定方案

方案要分优先级：

• P0：影响核心流程的，比如启动、支付、列表滑动
• P1：影响体验但不致命的，比如图片加载慢
• P2：锦上添花的，比如动画流畅度

我个人习惯先搞定P0，因为「先解决有没有，再解决好不好的问题」。

1.3.4 实施与验证

改完代码后，一定要验证。怎么验证？

• 用同样的工具再测一遍，看指标是否改善
• 灰度发布，看线上数据
• 对比实验，A/B测试

1.3.5 持续监控

优化不是一次性的。代码在迭代，性能也会变化。

我建议每个项目都建立性能监控体系：

• 线上监控FPS、内存、网络、启动时间
• 设置告警阈值，比如FPS低于40就告警
• 每次发版前做性能回归测试

1.4 总结

性能优化这件事，说白了就是「用数据说话，用工具定位，用方案解决」。

我见过太多人一上来就改代码，结果越改越糟。记住：没有数据的优化，都是耍流氓。

下一章，咱们会深入讲FPS优化的具体技巧。到时候我会分享一个我亲手优化的案例——一个列表从卡成PPT到丝般顺滑的全过程。