广告 SDK 接入实战：内部架构与 Mediation 决策机制

在移动端广告变现的实战中，开发者往往会面临一系列棘手的工程痛点：为什么接入多家广告源后 App 的崩溃率飙升？为什么预加载的素材总是过期导致计费异常？又该如何在复杂的网络环境下确保广告的高填充率与低延迟？要解决这些问题，仅仅调用几个 API 是远远不够的，我们需要深入理解 SDK 的内部流转机制。本篇作为 App 广告 SDK 深挖的实战与实现侧续篇，将跳出纯粹的理论概念，直接聚焦于具体的工程落地。

本文是端上变现系列的第 3 篇（接入与 Mediation）。 全系列 6 篇：

App 广告 SDK 深挖

广告 SDK 隐性成本

广告 SDK 接入实战

OEM 系统广告

CTV / OTT 与 SSAI

Web 变现深挖

一句话定位：从开发者视角全景拆解 App 广告 SDK 的接入流水线、内部七层架构以及 Mediation 混合统一竞价的决策机制。

TL;DR

标准化的接入流水线：从引入聚合 SDK 与各广告源 adapter 的依赖开始，历经权限与合规配置、App 启动时的异步初始化，再到使用服务端配置的广告位 ID 发起请求并监听回调，最终择机展示，这是一套高度标准化的工程流程。
寄生于宿主的七层架构：SDK 内部可划分为对外 API 层、异步状态机、配置中心、Mediation 决策层、adapter 适配层、网络与缓存层以及渲染与上报层。其核心工程难点在于整套架构完全寄生于宿主 App 进程中。
Mediation 混合统一竞价决策：聚合层的核心目标是将所有候选广告源拉到同一把尺子上对比 eCPM。传统瀑布流依赖预设 eCPM 串行询价，而 In-App Bidding 则支持并行实时出价；现代 SDK 普遍采用混合统一竞价模式，将实时出价与预设价格合并排序，确保价高者得。
聚合平台与广告源厂商全景：市场参与者主要分为两类，一类是负责竞价决策的聚合平台（如 Google AdMob、AppLovin MAX 等），另一类则是以 adapter 形式被挂载并提供实际广告库存的广告源（如 Meta、Mintegral 等）。
端上工程的隐蔽挑战：接入的真正难度并非调用简单的 API，而是如何妥善处理初始化时序、素材预加载、多 adapter 依赖冲突、全局超时收口以及奖励防作弊等复杂的端上工程问题（详见 App 广告 SDK 深挖 §5）。

Open Table of contents

1. App 怎么接入广告 SDK：一条固定流水线
2. SDK 内部是怎么实现的：你进程里跑着的七层架构
- 2.1 配置中心：实现不发版换源的基石
3. Mediation 怎么对这些 SDK 做决策
4. 哪些公司在做这些 SDK
- 4.1 聚合平台（负责竞价决策）
- 4.2 广告源与网络（提供真实库存）
5. 接入实战：几个绕不开的坑
6. 常见误解 ↔ 正解
延伸阅读

1. App 怎么接入广告 SDK：一条固定流水线

无论开发者选择接入 AdMob、AppLovin MAX 还是 Unity LevelPlay，其底层的接入步骤几乎都遵循着同一条标准化的流水线。为了更清晰地展示这一过程，我们将以「聚合 SDK 搭配多家广告源 adapter」的典型业务场景为例，完整梳理整个接入链路。

1.1 第一步：加依赖（聚合 SDK + adapter）

需要强调的是，接入广告 SDK 从来不是简单地引入一个依赖包，而是构建一个「聚合 SDK + N 个广告源 adapter」的生态矩阵。在这个矩阵中，聚合 SDK 负责提供统一的对外接口与全局竞价决策，而每一个 adapter 则扮演着翻译官的角色，将统一的标准接口精准转换为特定广告源的私有通信协议。

Android（Gradle）：

dependencies {
    // 聚合 SDK（这里以 AppLovin MAX 为例）
    implementation 'com.applovin:applovin-sdk:13.0.0'

    // 广告源 adapter：每接一家就多一个
    implementation 'com.applovin.mediation:google-adapter:24.0.0.0'
    implementation 'com.applovin.mediation:facebook-adapter:6.18.0.0'
    implementation 'com.applovin.mediation:mintegral-adapter:16.9.51.0'
    implementation 'com.applovin.mediation:unityads-adapter:4.12.5.0'
}

iOS（CocoaPods）：

pod 'AppLovinSDK'
pod 'AppLovinMediationGoogleAdapter'
pod 'AppLovinMediationFacebookAdapter'
pod 'AppLovinMediationMintegralAdapter'
pod 'AppLovinMediationUnityAdsAdapter'

正因如此，每增加一家广告源的 adapter，App 就会相应地增加一截二进制包体、一份外部依赖以及一组 ProGuard 规则或 SO 动态库。这不仅是引发多 SDK 依赖冲突的工程根源，更是开发者在权衡「究竟该接入多少家广告源」时必须算清楚的第一笔技术账。

1.2 第二步：权限与合规前置

在发起任何实质性的广告请求之前，必须先跨越系统权限与隐私合规这两道门槛：

Android 端的权限声明：除了基础的网络权限外，Android 13 及以上版本必须显式声明 AD_ID 权限以访问设备的 GAID。此外，各家广告源 adapter 通常会自带一系列 <meta-data> 或 queries 声明，开发者在打包时需要谨慎处理这些清单文件的合并冲突。
iOS 端的隐私配置：必须在 Info.plist 中配置 SKAdNetworkItems（为每家广告源分配对应的 SKAdNetworkIdentifier 以支持精准归因），并补充 NSUserTrackingUsageDescription 字段以提供 ATT 弹窗的向导文案。
全局的合规同意机制：在严格的隐私法规下，必须先获取 TCF 或 ATT 的用户同意状态，才能启动广告请求。通常情况下，聚合 SDK 会提供 CMP（同意管理平台）的标准化接入点或类似 setHasUserConsent 的 API；如果未能获取用户的明确同意，系统将只能下发低价值的无个性化广告，甚至直接拒绝填充。

1.3 第三步：App 启动时异步初始化

初始化（init）环节往往是整条接入链路中最容易踩坑的雷区。由于初始化过程是异步的且伴随一定的网络耗时，如果在 SDK 尚未完全就绪时就贸然发起广告请求，必然会导致请求失败。因此，工程上的最佳实践是：必须在初始化完成的回调函数中发起请求，或者在业务层实现一套可靠的请求排队机制。

// Android / Kotlin —— 启动时初始化，回调里再请求
AppLovinSdk.getInstance(this).mediationProvider = "max"
AppLovinSdk.initializeSdk(this) { config ->
    // 各 adapter 已就绪，这里再安全地预加载首个广告
    preloadInterstitial()
}

在初始化的底层流转中，SDK 实际上正在并发执行拉取远程配置与唤醒各个 adapter 的操作。为了保证用户体验，这一过程绝对不能阻塞 App 冷启动的主线程。特别是在开屏广告等冷启场景下，开发者必须设定一个严格的硬超时阈值（业内通常设为 3 秒左右）；一旦超时，必须果断放行用户进入 App 主界面，绝不能让用户面对白屏苦等 SDK 的响应（详细的超时治理策略可参考 App 广告 SDK 深挖 §5）。

1.4 第四步：用广告位 ID 请求 + 监听回调

广告位（ad unit ID）本质上是开发者在聚合平台后台创建的一个抽象逻辑节点。这个节点背后动态挂载着复杂的业务策略：究竟接入哪几家广告源、各家分配什么参数、是走传统瀑布流还是实时竞价（In-App Bidding）。由于这些策略全部在服务端进行配置，端上代码只需认准这一个唯一的 ID 即可。这种设计实现了端上逻辑与服务端策略的关键解耦，使得后续调整广告源或竞价策略时，完全不需要重新发布 App 版本。

val interstitial = MaxInterstitialAd("YOUR_AD_UNIT_ID", this)
interstitial.setListener(object : MaxAdListener {
    override fun onAdLoaded(ad: MaxAd) { /* 就绪，可择时 show */ }
    override fun onAdLoadFailed(unitId: String, error: MaxError) { /* 退避重试 */ }
    override fun onAdDisplayed(ad: MaxAd) {}
    override fun onAdHidden(ad: MaxAd) { interstitial.loadAd() } // 关闭后预加载下一个
    override fun onAdClicked(ad: MaxAd) {}
    override fun onAdDisplayFailed(ad: MaxAd, error: MaxError) {}
})
interstitial.loadAd()

从 API 层面来看，SDK 对外暴露的其实是一组异步回调接口与内部状态机。通过将 loadAd() 与 showAd() 彻底解耦，开发者可以在后台静默完成素材的预加载；等到合适的用户交互时机（例如游戏关卡结束或页面切换时），再调用 show() 进行展示。这种机制成功地将网络请求的延迟从用户的核心等待路径中剥离了出去。

1.5 第五步：渲染、上报、关闭与奖励

当调用 show() 之后，SDK 便会全面接管后续的渲染流程（包括 Banner 的内嵌渲染以及插屏或激励视频的全屏接管），并自动完成广告曝光（Impression）与点击（CTR）的数据上报，这些数据正是后续计费与对账的核心依据。

需要特别警惕的是，对于激励视频广告，SDK 会额外触发奖励发放的回调。为了防止黑产通过 Hook 客户端逻辑进行刷量作弊，奖励的最终发放必须严格以服务端到服务端（S2S）的回传校验为准，端上的回调仅仅用于更新 UI 状态（防作弊细节详见 App 广告 SDK 深挖 §6）。

1.6 第六步：测试与上线前自检

在将 App 推向生产环境之前，必须经过严密的自检流程：

启用测试模式（Test Device）：每一家广告源都提供了专属的测试模式。在开发与测试阶段必须强制启用该模式，否则研发过程中的真实流量误点极易触发广告平台的反作弊风控机制，导致账号被封禁。
利用 Mediation Debugger 排障：主流聚合平台（如 AdMob 或 AppLovin MAX）均内置了端上调试面板。该面板会清晰列出哪些 adapter 已成功集成、当前版本号以及是否存在配置缺失。当面临「某家广告源为何始终无填充」的困境时，这里永远是排查问题的第一站。
执行填充与时延体检：重点监控整体的广告填充率、各个 adapter 的网络延迟（Latency）以及 SDK 的初始化耗时。特别是在弱网环境下，必须严格验证全局超时收口机制是否能够正常触发并兜底。

2. SDK 内部是怎么实现的：你进程里跑着的七层架构

如果我们将一个看似黑盒的广告 SDK 从对外的 API 一路向下拆解到端上的底层执行，大体可以剥离出七层核心架构。深刻理解这张分层架构图，是开发者在面对「广告无法填充、计费数据异常、宿主 App 崩溃」等复杂故障时，能够精准定责与排查的前提。

广告 SDK 的内部七层：对外 API → 状态机 → 配置中心 → Mediation 决策 → adapter 适配 → 网络 / 缓存 → 渲染 / 上报。整套都寄生在宿主 App 进程里。

沿着数据流转的方向逐层拆解，这七层架构分别承担着不同的使命：

对外 API 层：这是开发者唯一直接接触的边界，主要暴露 load、show 以及一组状态回调。这层接口被设计得极其轻薄，其目的就是将所有的异步复杂度深埋于底层。
异步状态机：内部维护着 IDLE → LOADING → READY → SHOWING → CLOSED 的核心流转，并辅以 FAILED 异常分支。预加载与展示的解耦正是由这台状态机驱动的；如果在 Activity 已销毁后依然强行调用 show 导致崩溃，其根源往往就是状态机未能与宿主 App 的生命周期严密对齐。
配置中心（remote config）：在 App 启动时，该层会从服务端拉取一份包含「广告位映射、瀑布顺序、Bidding 开关、超时预算以及 A/B 分组」的策略清单，并缓存在端上。这构成了「调整广告源无需发版」的工程基石。
Mediation 决策层：根据配置中心的策略，将候选广告源组织成传统的串行瀑布流或并行的 In-App Bidding，随后统一按 eCPM 排序决出胜者，并在此处执行全局的超时收口。
adapter 适配层：针对每一家广告源部署一个专属的 adapter，负责将聚合 SDK 的标准指令翻译为对应网络的私有调用。更重要的是，核心的故障隔离机制就部署在这一层：通过调用边界的 try/catch 拦截、超时弃权策略以及崩溃面包屑归因，防止单一广告源的异常拖垮全局（详见 App 广告 SDK 深挖 §5 故障隔离）。
网络与缓存层：负责处理询价与素材拉取的 HTTP 请求，并管理素材的预下载、缓存生命周期（TTL）以及重试退避策略。实战中常见的「预加载素材过期导致计费异常」问题，往往就是这层的缓存治理出现了漏洞。
渲染与上报层：最终将广告素材（涉及 MRAID 或 VAST 协议）安全地渲染到屏幕上，并精准上报广告曝光（Impression）与点击（CTR）数据，同时处理激励视频的 S2S 奖励回传。

需要强调的是，这七层架构全部寄生于宿主 App 的进程之中，与 App 共享内存、线程池与包体空间。任何底层的 OOM 或 ANR，最终都会算在宿主 App 的头上。

2.1 配置中心：实现不发版换源的基石

在代码接入时，开发者仅仅填入了一个 ad unit ID，但这个 ID 背后却隐藏着庞大的服务端策略矩阵：究竟接入哪几家广告源、瀑布流的优先级顺序如何、是否开启 bidding 竞价、全局超时预算设为多少、以及流量的 A/B 分组规则。配置中心的存在，彻底将这套复杂的业务策略与端上的发版周期解耦：

热更广告源策略：假设今天需要新增一家 Mintegral 广告源，或者明天需要关停一家表现低迷的网络，运营人员只需在后台修改配置，端上在下一次拉取配置时即可无缝生效，完全无需等待漫长的 App 发版与用户升级周期。
A/B 测试与灰度验证：针对同一个广告位，平台可以精准地将 5% 的流量切分给「全新的瀑布流排序」或「开启 Bidding 竞价」的实验组，通过对比真实的 eCPM 数据后再决定是否全量推行。
动态风险熔断机制：一旦监控到某家 adapter 在线上的崩溃率异常飙升，服务端可以直接在配置清单中将其剔除，端上接收到新配置后会立即触发熔断机制，从而保障宿主 App 的稳定性（这正是对前文 adapter 适配层故障隔离机制的有效补充）。

正因如此，现代广告 SDK 绝非一个单纯的客户端代码库，而是一个深度融合了「端上执行引擎」与「服务端动态决策」的复杂系统。

3. Mediation 怎么对这些 SDK 做决策

当 App 成功接入了 AdMob、Meta、Mintegral 等多家广告源后，随之而来的核心挑战是：在每一次广告请求中，究竟应该向谁询价？谁又能给出最高的出价？这正是 Mediation（聚合层）需要解决的核心命题。其本质逻辑是将所有候选广告源拉到同一把 eCPM 的尺子上进行横向比对，确保价高者得。然而，工程上的难点在于：部分广告源支持返回实时竞价，而另一部分传统广告源却只能依赖后台的预设底价。

Mediation 的混合统一竞价：瀑布的预设 eCPM 与 bidding 的实时价被拉进同一个有序列表，按 eCPM 排序、从高到低尝试填充。这就是移动端的 Header Bidding。

3.1 瀑布（Waterfall）：按预设 eCPM 串行问

这是行业内最古老的竞价机制：聚合层完全依赖后台的人工配置或历史 eCPM 数据，为各家广告源排定一个静态的优先级顺序。在发起请求时，系统会从高到低进行串行询价，一旦某家广告源成功返回素材，整个流程便立即终止。

这种机制存在两个致命的工程痛点：首先，预设价格仅仅是历史估值而非实时出价，排在顺位靠后的广告源即便在某次请求中愿意给出更高的价格，也根本没有参竞的机会，导致媒体收益白白流失；其次，串行询价的模式不可避免地会拉长整体的网络延迟。

3.2 In-App Bidding：并行实时竞价

为了解决瀑布流的痛点，In-App Bidding 将传统的「串行猜价」彻底升级为「并行真实竞价」。在这种机制下，聚合层会同时向所有支持竞价的广告源发起询价，各家根据当前流量的价值返回一个真实的 bid，最终价高者得。这实际上就是 Web 端 Header Bidding 技术在移动 App 领域的完美复刻。

对比前一种方案，引入并行竞价的工程代价是：端上必须具备强大的并发控制能力，以管理多路异步的网络请求，并严格执行全局的超时预算。一旦到达设定的时间阈值，系统必须果断使用已收到的最高出价进行收口，无情地丢弃那些尚未返回的迟到者（关于超时收口的底层细节，请参阅 App 广告 SDK 深挖 §5）。

3.3 混合统一竞价：现实里两者并存

在真实的生产环境中，纯粹的 Bidding 或纯粹的瀑布流往往难以覆盖所有场景，两者几乎总是混合并存的。聚合层会将 Bidding 机制获取到的实时出价，与瀑布流中各档位的预设 eCPM 统一丢进一个全局的有序列表中，严格按照 eCPM 的高低进行重新排序，并从高到低逐一尝试填充。结合前文架构图中的具体数值，我们可以清晰地看到两者的收益落差：

机制	这次发生了什么	媒体到手
纯瀑布	配置最高的 A（$10）先问 → A 无填充 → 问 B（$6）→ B 填充，命中即停	$6
混合统一竞价	bidding 实时价（X $8 / Y $11 / Z $5）与瀑布预设价（$10/$6/$3）同排序 → 最高 Y $11 先填	$11

这种巨大的收益差距源于：纯瀑布流的静态排序机制根本无法感知到「广告源 Y 在这一次请求中给出了高达 $11 的实时出价」，它在命中 B 的 $6 档位后就草草结束了交易。而混合统一竞价机制则打破了壁垒，让真实的实时出价与预设底价同台竞技，从而成功地将这部分流失的收益重新捞回。从底层逻辑来看，这与媒体 Ad Server 的 dynamic allocation / 统一竞价完全是同一道经典架构题在移动端的翻版。

3.4 决策之外：自动调价、实例与 A/B

除了针对单次请求的竞价比对之外，现代聚合平台还提供了一系列用于持续优化收益的工程旋钮：

Auto eCPM（自动调价机制）：针对那些只能依赖预设价格的传统瀑布流广告源，平台会基于其近期的历史跑量表现，利用算法自动估算并动态调整其在瀑布流中的档位与排序，从而大幅降低人工调价的运营成本。
多实例并发（instances）：允许同一家广告源在一个广告位下挂载多个配置了不同地板价的实例（例如为 Meta 同时配置 $10、$5、$1 三个档位）。这种策略使得单一广告源能够在瀑布流中占据多个生态位，显著提升其整体的参竞概率与竞争力。
动态 A/B 测试：平台层原生支持将线上流量精准切分，用于对比「开启 Bidding vs 纯瀑布流」或「排序策略 A vs 排序策略 B」的真实 eCPM 表现。一旦实验组的数据胜出，即可依赖前文提到的配置中心迅速完成全量下发。

总结而言，In-App Bidding 负责在实时竞价的候选池中决出最高出价，而混合统一竞价则负责将这个实时最高价与所有瀑布流的预设底价拉到同一把尺子上进行终极对决。

4. 哪些公司在做这些 SDK

在当前的程序化广告生态中，市面上的 SDK 厂商主要扮演着两类截然不同的角色。在实际的工程落地中，一个 App 通常会选择集成「一个聚合平台 SDK」加上「多家广告源 adapter」。

4.1 聚合平台（负责竞价决策）

这类平台是端上流量的调度中枢，负责制定竞价规则并分配流量。

平台	母公司	特点
AdMob / GAM	Google	装机量最大、广告源最广；与 Google 需求（AdX）深度打通
AppLovin MAX	AppLovin	游戏变现霸主，In-App Bidding 接入广度领先
Unity LevelPlay（原 ironSource）	Unity	游戏引擎自带，与 Unity Ads 一体；ironSource 合并后整合
Digital Turbine FairBid（原 Fyber）	Digital Turbine	老牌聚合，欧洲背景
TopOn	江平智能	国内主流聚合，聚合海内外广告源，开发者侧透明度高
GroMore	字节跳动（穿山甲）	国内聚合，与穿山甲 / Pangle 需求打通

4.2 广告源与网络（提供真实库存）

这类厂商是真正的买方代表，它们以 adapter 的形式被聚合平台挂载，为媒体提供真实的广告预算。

广告源	母公司	备注
Google Ads / AdMob 需求	Google	既是聚合平台也是最大需求源
Meta Audience Network	Meta	社交流量需求，强 bidding 支持
Mintegral	汇量科技（Mobvista）	国内出海主力广告源
Pangle / 穿山甲	字节跳动	抖音 / TikTok 系流量，出海 + 国内
Unity Ads	Unity	游戏内激励 / 插屏强势
Liftoff（含 Vungle）	Liftoff	视频 / 激励见长（Vungle 已并入 Liftoff）
InMobi	InMobi	老牌移动广告网络，亚洲背景
Chartboost	Zynga / Take-Two	游戏起家的网络 + 轻量聚合
Moloco / Bigo / Kuaishou 等	各自	新兴或区域性 ML 驱动 / 短视频系需求

需要强调的是，在真实的商业生态中，这两类角色往往是高度重叠的。例如，Google、AppLovin 和 Unity 既是制定规则的聚合平台，又是手握海量预算的广告源。它们既在打造「决策的尺子」，又在不断地往这把尺子上输送自己的需求。这正是程序化广告生态全景中「一家公司戴多顶帽子」现象在移动端的真实翻版。正因如此，聚合平台作为「裁判兼运动员」的中立性时常受到行业的严厉审视（关于拍卖机制的公平性探讨，可参见 last look 与拍卖透明度）。

5. 接入实战：几个绕不开的坑

在实际的工程落地中，开发者往往会遭遇以下几个绕不开的技术暗礁：

初始化未就绪即发起请求：这会导致广告请求直接被底层状态机拦截并抛出失败异常。正确的做法是必须在 init 的成功回调中发起请求，或者在业务层实现一套可靠的请求排队机制。
缺乏预加载机制直接调用 show：这会让用户在屏幕前干等素材的实时下载，极大地损害用户体验。对于插屏或激励视频这类全屏广告，必须提前调用 loadAd() 做好素材储备。
在宿主页面销毁后强行触发 show：当异步的网络回调返回时，如果底层的 Activity 已经被系统回收，强行渲染必然引发崩溃。因此，在调用渲染接口前，必须严格校验宿主的生命周期状态。
多 adapter 导致的依赖与 SO 库冲突：在升级某一家广告源的 SDK 时，极易引发底层依赖冲突，把另一家正常工作的 adapter 顶崩。开发者必须严格对齐各家的依赖版本，并依赖聚合层的故障隔离机制，确保单一 adapter 的崩溃不会引发全局雪崩。
单一慢源拖垮整条竞价链路：如果在并行询价时缺乏全局超时控制，一家响应缓慢的广告源就会严重拖累整条链路的填充效率。因此，在实施 Bidding 竞价时，必须设定严格的超时收口策略。
轻信端上回调发放激励奖励：如果仅仅依赖端上的回调事件来发放游戏道具等奖励，极易被黑产通过 Hook 技术或请求重放进行刷量作弊。奖励的最终发放必须无条件地以 S2S 服务端回传为准。
隐私合规与归因配置缺失：在 iOS 平台上，如果漏配了 SKAdNetworkItems，将直接导致广告归因链路断裂；而如果未能成功获取用户的隐私同意状态，系统将只能下发低 eCPM 的无个性化广告。

关于更系统的端上工程取舍（涵盖内存治理、OOM / ANR 防范、故障隔离与超时收口等深度话题），请参阅 App 广告 SDK 深挖 §5–§6。

6. 常见误解 ↔ 正解

常见误解	正解
接广告 SDK 就是简单加个包、调个 API	实际上是接入聚合 SDK、多个 adapter、服务端配置与异步状态机的复杂合体
调整广告源策略必须依赖 App 发版	广告位映射策略托管在服务端的配置中心，端上拉取后热更即生效
Mediation 聚合层一定在进行实时竞价	传统瀑布流仅按预设 `eCPM` 串行询价；真正的实时竞价依赖 `In-App Bidding`
Bidding 竞价与瀑布流必须二选一	生产环境中普遍采用混合统一竞价，实时出价与预设底价同台排序
聚合平台是绝对中立的流量裁判	头部平台往往既当裁判又当运动员，向自己的聚合生态中输送自有需求
多接几家广告源必定能带来收益增长	盲目增加广告源会导致包体膨胀、内存飙升以及崩溃风险加剧，需谨慎权衡
激励视频的奖励发放只需依赖端上回调	为防范刷量作弊，奖励的发放必须严格以 S2S 服务端回传校验为准

行业黑话总结：聚合平台（Mediation）居中调度；adapter 翻译私有协议；广告源（Ad Network）提供真实预算；ad unit ID 解耦端上与服务端；配置中心（remote config）支撑热更不发版；Waterfall 按预设 eCPM 串行询价；In-App Bidding 驱动并行实时竞价；混合统一竞价合并排序价高者得；eCPM 衡量千次曝光收益；多实例（instance）占据多个瀑布档位；超时收口（timeout budget）斩断长尾延迟；故障隔离（fault isolation）兜底崩溃风险；S2S 服务端回传防范刷量作弊；SKAdNetwork 与 ATT 构筑隐私归因底座；CMP 采集用户合规同意；Mediation Debugger 端上排障兜底。

在彻底掌握了移动端 SDK 的接入流水线与内部流转机制后，为了更宏观地理解这些端上组件在整个广告交易链路中的位置，建议继续阅读本系列的母篇：App 广告 SDK 深挖。