性能剖析：CPU Profiling、内存分析、协程性能、JVM调优
性能调优这件事，说实话，很多开发者容易走两个极端。要么觉得「跑得动就行」，要么一上来就搞各种玄学参数。我个人的经验是——先搞清楚瓶颈在哪，再动手。今天我们就聊聊Kotlin项目里最常用的四种性能剖析手段：CPU Profiling、内存分析、协程性能、JVM调优。
一、CPU Profiling：找到谁在吃CPU
CPU Profiling说白了就是看你的代码把CPU时间花在哪了。我见过不少项目，上线后CPU飙到90%，结果一查，是某个循环里做了无意义的字符串拼接。
1.1 采样 vs 插桩
两种主流方式：
- 采样（Sampling）：每隔一段时间拍一张快照，看看当前线程在干嘛。开销小，适合生产环境。
- 插桩（Instrumentation）：在每个方法入口出口插入计时代码。精度高，但会拖慢运行速度。
我个人习惯先用采样定位热点，再用插桩深挖细节。你想想看，如果一开始就全量插桩，那性能数据本身就已经失真了。
1.2 实战：用Android Studio CPU Profiler
// 一个典型的性能陷阱：频繁创建临时对象
fun processData(list: List<String>) {
val result = mutableListOf<String>()
for (item in list) {
// 这里每次循环都创建了一个新的StringBuilder
result.add("Prefix_$item".toUpperCase())
}
}
用CPU Profiler跑一下，你会发现toUpperCase()和字符串拼接占用了大量时间。优化方案很简单：
fun processDataOptimized(list: List<String>) {
val result = ArrayList<String>(list.size) // 预分配容量
for (item in list) {
result.add("Prefix_${item.uppercase()}") // 用模板字符串
}
}
Bitmap.createBitmap()调用占了60%的CPU时间。后来改成复用Bitmap对象，性能直接翻倍。
二、内存分析：别让GC成为你的噩梦
内存问题比CPU问题更隐蔽。CPU飙高你马上能感觉到卡顿，但内存泄漏往往要跑几个小时甚至几天才会触发OOM。嗯，这里要注意——Kotlin的lambda表达式和协程很容易造成隐式内存泄漏。
2.1 常见内存泄漏模式
| 模式 | 原因 | 解决方案 |
|---|---|---|
| 匿名内部类持有外部引用 | lambda捕获了Activity/Fragment | 使用弱引用或Lifecycle感知 |
| 协程未取消 | Job/CoroutineScope泄漏 | 使用viewModelScope或lifecycleScope |
| 静态集合 | 对象被静态引用无法回收 | 及时清理或使用WeakHashMap |
| 未关闭的资源 | Cursor、File、Socket | 使用use{}扩展函数 |
2.2 用MAT分析堆转储
我推荐用Eclipse MAT（Memory Analyzer Tool）来分析hprof文件。操作步骤：
- 用Android Studio或jmap生成堆转储文件
- 用MAT打开，运行「Leak Suspects」报告
- 查看GC Root路径，找到谁在持有对象
三、协程性能：别让挂起变成阻塞
协程是Kotlin的杀手锏，但用不好反而会拖慢性能。我见过有人把协程当线程池用，每个网络请求都开一个GlobalScope.launch——这其实跟开线程没区别，还多了协程调度的开销。
3.1 协程调度器的选择
// 错误示范：所有任务都跑在Dispatchers.IO
GlobalScope.launch(Dispatchers.IO) {
// 这里只是简单的计算，不应该用IO调度器
val result = (1..1000).sum()
}
// 正确做法：CPU密集型用Default，IO密集型用IO
GlobalScope.launch(Dispatchers.Default) {
val result = (1..1000).sum()
}
3.2 协程泄漏检测
协程泄漏比线程泄漏更隐蔽。线程泄漏会导致线程数暴涨，而协程泄漏只是默默占用内存。我建议在Debug模式下开启协程的调试模式：
// 在Application.onCreate中设置
System.setProperty("kotlinx.coroutines.debug", "on")
这样在Logcat中就能看到每个协程的创建堆栈。配合StrictMode使用效果更佳。
四、JVM调优：参数不是越多越好
JVM调优这块，我见过最夸张的配置——一个Spring Boot项目配了30多个JVM参数，结果大部分都没生效。说白了，调优的核心就三个方向：堆内存、GC策略、线程栈。
4.1 堆内存配置
| 参数 | 作用 | 建议值 |
|---|---|---|
| -Xms | 初始堆大小 | 设为与-Xmx相同，避免动态调整 |
| -Xmx | 最大堆大小 | 不超过物理内存的70% |
| -XX:NewRatio | 新生代与老年代比例 | 2~3（即新生代占1/3~1/4） |
| -XX:SurvivorRatio | Eden与Survivor比例 | 8（默认值通常够用） |
4.2 GC策略选择
Kotlin项目通常跑在JDK 8+上，我推荐以下组合：
- 响应优先（如Web服务）：G1GC + -XX:MaxGCPauseMillis=200
- 吞吐优先（如批处理）：ParallelGC + -XX:GCTimeRatio=19
- 低延迟（如实时系统）：ZGC（JDK 11+）或Shenandoah
五、知识体系总览
下面这张图概括了性能剖析的四个维度和它们之间的关系：
六、总结
性能剖析不是一锤子买卖，而是一个持续的过程。我个人习惯在每个迭代周期结束时，跑一次完整的性能基线测试。这样一旦性能回退，马上就能发现。
最后送你一句话：没有测量就没有优化。别凭感觉调优，让数据说话。