当一次会话因崩溃而中断时，你失去的不只是用户信任，还有本应在这次会话剩余时间内展示的所有广告、会话结束时本应触发的所有回传，以及相当一部分次日留存。把这笔账算清楚，结果并不轻松。
损失是如何层层叠加的
一款运行稳定的移动应用，平均会话时长为 6–9 分钟。考虑广告频次上限后，每次会话平均产生 2.4 次广告展示。如果会话在第 2 分钟崩溃，平均就会损失约 1.6 次展示，且无法挽回。
如果崩溃率为 1%、DAU 为 500 万，每天就会损失 80,000 次广告展示。按 7 美元的 eCPM 计算，每天损失 560 美元收入，而这仅仅是 1 个百分点的稳定性差异所造成的。
完整的收入损失模型
公式很简单：每日收入损失 = DAU × 崩溃率 ×（每次会话的广告展示次数 − 崩溃前的广告展示次数）× eCPM / 1000。代入实际业务数据后，你就会直观地感受到损失有多大。
- 100 万 DAU × 1.5% 崩溃率 × 1.6 次展示损失 × 6 美元 eCPM ≈ 每天 144 美元，每年 5.2 万美元
- 500 万 DAU × 1.0% 崩溃率 × 1.6 次展示损失 × 7 美元 eCPM ≈ 每天 560 美元，每年 20.4 万美元
- 2500 万 DAU × 0.6% 崩溃率 × 1.6 次展示损失 × 8 美元 eCPM ≈ 每天 1,920 美元，每年 70 万美元
- 而且，这些数字只计算了广告展示损失，尚未计入留存下降带来的影响，后者通常更大
ANR 对变现的伤害比崩溃更大
Android 上的 ANR（应用无响应）是隐形杀手。用户看到界面卡死，强制退出，然后卸载应用，但系统并未触发崩溃报告，因此只盯着 Crashlytics 的团队可能完全看不到问题。在主线程初始化广告 SDK 的应用中，ANR 率超过 0.5% 并不少见。
iOS 上对应的问题是 watchdog 终止，退出码为 0x8badf00d，通常也源于同一个问题：启动期间在主线程执行同步任务。对这两类问题，都应像对待崩溃一样处理：设置告警，用同样的模型计算收入损失，并在每次发版时将其纳入发布准入检查。
各平台的防御性开发实践
以下是我们在每次 Apps Kit SDK 集成中默认采用的做法。没有哪一条是什么高深技巧，但在我们审查的大多数代码库中，这些措施都没有落实。
- Android：通过 WorkManager 任务初始化 SDK，而不是在 Application.onCreate 中初始化
- Android：使用 WeakReference 持有广告视图，并在 onDestroyView 中将引用置空
- iOS：在 didFinishLaunching 中将 SDK 初始化任务派发到 utility QoS 队列，切勿阻塞主线程
- iOS：在 viewWillDisappear 中解除广告代理并打破循环引用，不要等到 deinit
- 双平台：通过状态机统一控制每次广告请求，确保满足用户同意、网络可用和 SDK 就绪条件后再发起请求
崩溃从哪里来
- 在主线程初始化 SDK——这是我们遇到的最常见原因
- 在 onCreate / didFinishLaunching 中同步加载广告
- 广告视图已不再使用，却仍被持有，造成内存压力
- 用户同意状态与广告请求之间存在竞态条件
按收入影响设置崩溃告警
崩溃率告警通常绑定一个固定的百分比阈值，触发后却往往被忽略。不妨改为按收入影响触发告警：当某类崩溃按模型估算的每日收入损失超过 X 美元时发出通知。这样的告警，才值得值班工程师半夜起来处理。我们提供的 Cloud Function 模板，就是基于 BigQuery 导出数据来实现这一功能的。
防御性集成方案
在后台调度器上初始化 SDK，通过用户同意状态机控制每一次广告请求，并在广告位关闭时立即释放广告视图引用。这些都不是什么新方法，但在我们审查的大多数集成方案中，都没有落实。
把崩溃率视为提升收入的杠杆，而不是基础工程质量指标，稳定性工作的优先级就不必再反复讨论。
这周就可以做什么
打开崩溃监控看板，把排名前三的崩溃类型逐一代入上面的模型，并在每一项旁边标出具体的美元损失金额。优先修复收入损失最大的问题，这次发版在下一个 App Store 审核窗口结束前，就能收回修复成本。
