一、性能调优概述：SDK 运行时性能的定义、关键指标与核心目标
1.1 什么是 SDK 运行时性能？
咱们先聊个基础问题：SDK 的运行时性能，到底指的是什么？
你想想看，SDK 不是应用本身，它是嵌入到宿主 App 里的一组代码库。运行时性能，说白了就是 这个 SDK 在宿主环境里“跑起来”之后，对系统资源、响应速度、内存消耗等方面的影响。
我个人习惯把 SDK 运行时性能拆成三个维度看：
- 时间维度：调用接口后多久能返回结果。
- 资源维度：CPU、内存、网络、存储吃了多少。
- 稳定性维度：会不会卡死、崩溃、或者把宿主 App 拖慢。
我在项目中遇到过不少案例——有些团队把 SDK 做成了“黑盒”，集成进去后用户手机发烫、掉帧，甚至被商店下架。嗯，这就是运行时性能没管好。
1.2 三个关键指标：延迟、吞吐量、资源占用
做性能调优，首先得知道拿什么数据说话。我一般盯住三个核心指标：延迟（Latency）、吞吐量（Throughput）、资源占用（Resource Usage）。
延迟（Latency）
延迟指的是从调用 SDK 接口到收到结果的时间差。单位通常是毫秒（ms）。
有个坑要注意：延迟不是越短越好。你强行把延迟压到 1ms，可能把 CPU 占满，导致其他任务饿死。我曾经在一个音视频 SDK 里把编解码线程优先级调得太高，结果主 UI 线程拿不到时间片，画面虽然快了几毫秒，但界面卡成 PPT——得不偿失。
| 场景 | 可接受延迟 | 注意 |
|---|---|---|
| 实时语音 | < 50ms | 否则有回声/撕裂感 |
| 图像识别 | < 200ms | 用户感知不明显 |
| 数据上报 | < 500ms | 可后台队列处理 |
吞吐量（Throughput）
吞吐量是指单位时间内能处理多少个请求或数据量。比如每秒能完成多少次数据库写入、每秒能解码多少帧。
吞吐量跟延迟有耦合关系，但不完全一样。我举个极端例子：一个接口延迟 10ms，但只能跑单线程，那每秒最多 100 次；另一个接口延迟 20ms，但可以多线程并行，每秒能跑 500 次。后者延迟高了，但吞吐量反而大。
资源占用（CPU / 内存 / 网络 / I/O）
资源占用是宿主 App 最敏感的问题。我以前做过一个日志 SDK，上线后用户反馈手机发烫。查了才发现，我把日志压缩放在主线程里做，CPU 瞬间飙升到 80%。
常见资源指标清单：
- CPU 使用率：峰值 < 30%，平均 < 10% 比较健康。
- 内存：避免大对象常驻，注意 Java 堆与 Native 堆的平衡。
- 网络流量：压缩、缓存、批量发送。
- 磁盘 I/O：小文件频繁读写是坑，用 buffer 或写内存映射文件。
我自己的经验：资源占用往往比延迟更容易被忽略，但后果更严重。一个接口慢 200ms 用户或许能忍，但 App 闪退或发烫，用户会直接卸载。
1.3 调优的核心目标
调优不是为了刷数据好看，而是为了找到业务效果与资源成本的平衡点。
我把核心目标归纳为三个层面：
目标一：满足业务 SLA
SLA 是承诺线。比如“95% 的请求延迟 < 100ms”“CPU 峰值不超过 40%”。调优首先要守住这些红线。
目标二：降低宿主负效应
SDK 既然是寄生在别人的 App 里，就要尽量做到“无感”。用户感知不到你的存在，才是最高境界。
目标三：可度量、可复现、可持续
没有度量就没有优化。你需要一个性能基线，每次改代码后重新跑压测。我曾经犯过错误——凭感觉改代码，结果上线后性能反而变差。后来我养成了 “改前压测 → 改后压测 → diff 对比” 的习惯。
1.4 本章知识体系
为了让你一目了然，我画了一张结构图。它把性能调优的脉络串起来了：指标、目标、方法、工具、案例。后面每章都会围绕这张图里的某个分支展开。
1.5 你该怎么用这张图？
后面每章都会围绕图中某个子节点展开。比如第 2 章讲延迟的测量与优化，第 3 章讲吞吐量的提升技巧，第 4 章讲内存泄漏排查。你可以回来对照这张图，理清知识关联。
1.6 闲话两句
我刚开始调优那会儿，总喜欢折腾花哨的算法。后来发现：大多数性能问题都不是算法的问题，而是线程模型、内存模型、I/O 模型没选对。把这几个“大骨架”搭好，剩下的细节优化才有意义。