你集成到应用中的每一个广告SDK都有隐性成本。每个SDK都会增加二进制包体积、拉长冷启动时间、引入潜在的兼容性冲突，并形成新的依赖项——在新版本OS发布时需要同步更新。对于集成了五个、八个甚至十二个SDK的发布商来说，对应用性能和用户体验的累积影响可能非常显著，而且往往因为是渐进发生的而难以察觉。
SDK膨胀的真实代价
应用二进制文件每增加一个兆字节都至关重要。研究反复表明，应用安装转化率会随着下载体积每增加一兆字节而出现可测量的下降。在存储空间有限、网络连接较慢的新兴市场，这种影响更为明显。一个集成了三个广告SDK、总计增加15兆字节的发布商，可能因安装量减少而损失的收入比这些SDK带来的增量需求收入还要多。
除了下载体积之外，SDK还会消耗运行时资源。每个在应用启动时初始化的SDK都会增加启动耗时。等待超过三秒的用户更有可能直接放弃。而每个在后台运行的SDK都会消耗内存和电量——这些是用户能够感知到的，也是平台应用商店日益关注并加以惩罚的指标。
SDK审计
首先审计你当前的SDK技术栈。对应用中的每个广告SDK，衡量三项指标：它增加的二进制体积、它产生的收入以及它的fill rate。你几乎一定会发现，一两个SDK贡献了你绝大部分的收入，而其他几个SDK贡献微薄却带来了显著的性能开销。
80/20法则同样适用
在大多数发布商的应用中，两到三个广告SDK产生了80%甚至更多的广告总收入。其余的SDK虽然填补了一些空缺，但如果将性能影响计算在内，它们的成本往往超过了其贡献。目标不是消除所有SDK——而是找到能够获取最大收入的最小SDK组合。
服务端解决方案
在不损失需求多样性的前提下减少SDK数量，最有效的方式是将需求聚合从客户端转移到服务端。例如Google的Open Bidding允许多个需求方合作伙伴竞争你的广告库存，而无需在你的应用中集成各自的SDK。你获得了多方竞价的竞争压力，却只需维护一个SDK的集成复杂度。
托管式需求方案
托管式需求合作伙伴将这一理念推进得更远。你不再需要自己集成多个SDK，只需接入一个连接点——通过你现有的mediation平台或通过一个轻量级的服务端集成。托管合作伙伴在自己的基础设施上聚合来自数十个来源的需求，你的应用只看到一个需求源。最终效果是：更多的需求多样性，更少的SDK开销。
最聪明的发布商不是在问“我还能加多少个SDK？”，而是在问“我需要的最少SDK数量是多少才能获取最大收入？”答案几乎总是比他们当前集成的数量要少。
减少SDK膨胀的实操步骤
1. 移除表现不佳的SDK
如果一个SDK产生的收入不到你广告总收入的5%，请认真考虑移除它。其性能成本很可能已经超过了收入贡献。
2. 通过Mediation进行整合
尽可能使用mediation平台内置的adapter，而非独立的SDK集成。Mediation adapter通常比完整的SDK集成要轻量得多。
3. 利用服务端竞价
将支持服务端竞价的需求方合作伙伴迁移到该模式。这会从你的应用中移除他们的SDK，同时保留他们在waterfall中的需求。
4. 用托管合作伙伴处理长尾需求
与其为区域性或细分需求集成五个小众SDK，不如使用一个托管合作伙伴在服务端聚合这些需求。
衡量效果
在减少SDK数量之后，请监控三个指标：应用体积缩减情况、启动时间改善情况以及广告总收入。执行得当的SDK精简应该在前两项上展现出可测量的改善，而第三项则不会出现显著变化——甚至可能提升，因为应用体积缩小会带来更高的安装率和更好的用户留存。