第1章：你不得不面对的开销现实

做SDK开发这么多年，我见过太多“功能完美、上线崩溃”的案例。说到底，多数问题都出在运行时开销上。

什么叫运行时开销？说白了，就是你的SDK集成到宿主App之后，多出来的那部分性能消耗。包括CPU多算了多少、内存多占了多大、网络多跑了几趟，甚至是启动慢了那么一丁点。

我2018年接手过一个音视频SDK。功能很全，但集成到电商App后，冷启动直接慢了1.2秒。用户那边炸了，说“你们这SDK往里一塞，启动都转菊花”。你看，这就是典型的运行时开销没兜住。

1.1 开销从哪来？一张图看明白

先看看整个链路。我习惯把SDK运行时开销画成这几类：

1.2 开销到底分几类？

我个人习惯把运行时开销分成五类。你在项目里也可以按这个框架去对号入座：

开销类型	典型场景	影响指标
启动开销	SDK初始化、so加载、类加载	App冷启动时间
内存开销	缓存、对象池、大块内存分配	PSS、Java堆/Dalvik Heap
线程开销	线程创建、锁竞争、上下文切换	CPU使用率、卡顿率
IO开销	文件读写、SP读写、数据库操作	IO Wait、ANR率
网络开销	DNS解析、建立连接、数据序列化	网络延迟、流量消耗

1.3 优化的目标是什么？

你可能会想，是不是把开销减到零才算赢？不是的，别钻牛角尖。

我经历过一个搜索SDK项目。为了优化启动速度，把全部预热逻辑砍了。结果第一次搜索耗时多了一倍，产品经理直接找上门来。你看，过度优化反而伤核心体验。

真正的优化目标，其实是这三条：

• 启动时间可控： 保证SDK初始化不影响App冷启动。我一般定标“首帧前完成初始化”。
• 内存占用有界： 申请多少、释放多少要清楚。上限设好，超出就降级。
• 主线程不阻塞： 这是底线。所有耗时操作必须异步，包括配置加载、资源解密、模型预热。

1.4 怎么衡量开销？

先摆两个我常用的公式：

// 性能分解公式
总耗时 = 启动耗时 + 主流程耗时 + 后台任务耗时
总内存 = 常驻内存 + 临时内存 + 缓存内存 + 碎片内存

举个具体例子。我在图像处理SDK里做过一次量化：

阶段	优化前	优化后	优化手段
启动时间	850ms	120ms	懒加载 + 异步初始化
内存峰值	76MB	31MB	内存池 + 大小端适配
线程调度	11次	3次	复用线程池 + 减少锁粒度

1.5 一个真实案例的启发

讲一个我踩过的坑，你听完应该会更有感觉。

有个广告SDK，上线后发现宿主App用户留存掉了3%。一开始以为是广告内容不行，数据一查——不是。

真正的问题是：该SDK在应用启动时，自动在主线程初始化了网络连接池。这一下就干了600ms。而且，它用了MappedByteBuffer加载模版文件，直接引发了一次次页面滑动GC。内存波动那叫一个剧烈。

你怎么看？其实问题不在于代码写错了，而在于 没有把运行时开销作为版本验收项。从那次之后，我所在团队定了个规矩：

1. 每次发版前，用Profiler完整跑一轮五种开销指标
2. 启动时间超过300ms直接卡门
3. 内存泄漏检测不过关不发版
4. 主线程有任何耗时操作，一票否决

这套流程看起来简单，但坚持下来，再也没出现过类似问题。

1.6 小结：你得记住的几件事

• 运行时开销是SDK集成后多出来的额外性能消耗，分类越清晰，优化越好做
• 优化的目标是“可控”，不是“归零”
• 五种核心开销：启动、内存、线程、IO、网络。缺一不可
• 量化是前提，没有数据就没有优化
• 把开销检查做成发版卡门条件，比什么都管用

嗯，框架搭好了。后面的章节我们会一步步深入每种开销的优化细节。你先把这个结构装进脑子里，后面都好办。