资源开销评估基础：CPU、内存、网络、磁盘IO

各位好，欢迎来到第三章。今天聊的话题很基础，但也很要命——资源开销评估。说白了，就是搞清楚你写的SDK到底吃掉了系统多少资源，以及这些资源是怎么被消耗的。

我见过太多SDK，功能没问题，一上线就把宿主App搞垮了。不是CPU飙到100%，就是内存涨成OOM。所以这一章，咱们得把资源开销的底牌翻出来看看。

CPU资源模型：别让宿主APP卡成PPT

CPU资源是最直观的。程序跑得快不快，用户一眼就能看出来。但CPU开销不仅仅是“执行时间”这么简单。

CPU开销的核心指标：

• 用户态CPU时间：SDK业务逻辑消耗的时间，比如数据处理、加密解密。
• 内核态CPU时间：系统调用、IO等待、线程调度的时间。这块经常被忽略。
• 上下文切换次数：线程太多，切换太频繁，CPU时间全花在调度上了。
• CPU缓存命中率：内存访问模式不合理，L1/L2缓存频频缺失，性能直接崩盘。

内存资源模型：泄漏是慢性自杀

内存问题最头疼。CPU飙高还能恢复，内存泄漏了，用户只能重启应用。

内存开销的关键维度：

• 堆内存分配：Java/Kotlin对象、C/C++的malloc。要关注分配频次和大小。
• 线程栈内存：每个线程默认分配 1MB 栈空间。创建128个线程，光栈就吃掉128MB内存。
• Native堆外内存：Bitmap、DirectBuffer这些不走GC的区域，最容易泄漏。
• 网络缓冲区：TCP收发缓冲，每个连接10KB~几百KB不等。

怎么评估？ 我用过一个笨办法但很有效——在SDK启动前和运行10分钟后，分别抓一次内存快照，对比对象存活数。比如：

// 在Android上，使用Debug工具
Debug.MemoryInfo info = new Debug.MemoryInfo();
Debug.getMemoryInfo(info);
Log.d("SDK_MEM", "dalvikPss: " + info.dalvikPss + " KB");
Log.d("SDK_MEM", "nativePss: " + info.nativePss + " KB");
Log.d("SDK_MEM", "totalPss: " + info.getTotalPss() + " KB");

网络资源模型：流量不是免费的

现在的用户对流量很敏感。你一个SDK每天后台跑200MB流量，用户很可能会卸载你的应用。

网络开销的核心指标：

指标	描述	警戒线
上行流量	SDK发送的数据量（请求体、上传文件等）	单次请求 < 100KB
下行流量	SDK接收的数据量（响应体、下载等）	单次请求 < 500KB
连接建立次数	TCP三次握手的频次	每分钟 < 5次
DNS解析时间	域名解析的耗时	每次 < 200ms

评估方法：我建议在开发环境用 tcpdump 或 Wireshark 抓包，统计每个请求的字节数和耗时。生产环境可以用网络库自带的监听器，比如 OkHttp 的 EventListener。

磁盘IO资源模型：别把闪存写坏了

磁盘IO很容易被忽略，但它对用户体验的影响很隐蔽。你想想看，用户刷个朋友圈，SDK在后台疯狂写日志，手机就卡住了。

磁盘IO的关键风险点：

• 频繁写小文件：比如每秒写一条日志。闪存的寿命是有限的，小文件写入最伤寿命。
• 读放大：读取一个字节，却触发了整个4KB页的读取。
• 数据库事务频繁提交：每次提交都涉及刷盘操作。
• 缓存未命中：Page Cache命中率低，每次读都走磁盘。

评估工具：

• Linux下用 iostat -x 1 看磁盘繁忙度（%util）。
• Android上可以用 strace 追踪 write() 系统调用的频次。
• iOS用 fs_usage 监控文件操作。

资源泄漏的概念：别拿用户手机当沙包

什么是资源泄漏？就是SDK申请了系统资源，但用完之后没还回去。

常见的资源泄漏类型：

1. 内存泄漏：GC无法回收的对象。比如 Activity 引用被静态变量持有。
2. 线程泄漏：线程创建了没销毁，线程池核心线程数设置不合理。
3. 文件句柄泄漏：打开文件、Socket、数据库 Cursor，忘记关闭。
4. 网络连接泄漏：HTTP 连接池中的连接没有正确释放。
5. 定时器/回调泄漏：注册了 Listener 或 Handler，但没有在生命周期结束时注销。

最后分享一点个人经验。我做SDK性能调优很多年，总结出一个基本原则：从第一个版本开始就要建立资源基线。哪怕是一个demo，也要跑一下CPU、内存、网络、IO的数据。记录下基线值，后续每次迭代都和基线对比。一旦发现资源曲线偏离了基线，立刻定位原因。