你怎么知道一个小游戏在真实环境里真的稳？
你旗舰测试机上 0.1% 的崩溃率不是稳定。那是对一台设备、连着 wifi 的猜测。真正的稳定，是跨上千种设备型号、厂商内存杀手和摇摇欲坠的网络的分布——而且小游戏还背着原生应用没有的一道褶皱：你和大家共享一个运行时。下面讲怎么量、怎么拥有它。
Q：为什么你自己的设备告诉不了你游戏稳不稳？
因为它是错误的样本。你的开发机是近年的旗舰、连着快网；你的玩家在两千种安卓机型、低内存设备，以及会话中途丢包的运营商网络上。一个在你桌上永远复现不了的崩溃，能在你从没摸过的一款热门低端机上打到 5%。稳定是个分布问题，不是你从一个数字算出的平均值。唯一的学法，是来自现场的、真机的遥测——模拟器和你的笔记本每次都会骗你，因为它们被设计成最佳情况。
Q：真正该盯的指标是什么？
两个，分开盯。无崩溃会话率（或用户级）是头条——你要让它高于 99%，因为一旦跌破约 98%，你就在流失那些永远不会提交报告的玩家，他们只是走人。第二个是 ANR——"应用无响应"——玩家感受上和崩溃一样，却不会出现在崩溃日志里，于是团队乐观地报告着他们并没有的稳定性。两者都要按设备型号、系统版本、以及运行时版本来切分，因为一个糟糕的运行时版本，能一次性把跑在它上面的每一款游戏的崩溃率都打崩。
Q：为什么小游戏在共享运行时上，稳定性是特别的？
你的小游戏住在宿主运行时里，而那个运行时一更新，你游戏的行为就可能变——哪怕你一行没改。一次 WebView 引擎变更、一次权限收紧、一次内存上限调整——任何一条都能让你整片舰队出问题，而症状看起来恰好像你的 bug。所以你必须按运行时版本监控，而且你需要一条不依赖宿主重新部署你的回滚路径。要内化的不对称是：原生应用拥有自己的整条技术栈；小游戏共享一条，而邻居的一次回归，能在你打开的每一个仪表盘里，伪装成你的错。
Q：怎么建一个能早早发现火情的稳定性机制？
从第一天起就接上崩溃上报（Crashlytics、Sentry）——不是等第一条一星差评之后。每个运行时和游戏版本都先灰度一小部分再全量。对崩溃率的回退报警，而不是对原始崩溃数报警，因为原始数会随流量缩放、把信号藏起来。备好一键回滚。还要诚实地闭环：一个复现不了、也没修的崩溃，是你已经决定接受的流失，所以给它打标签，按"受影响用户数"而不是按某人贴的严重度来排优先级，并在它变成留存曲线拐点的原因之前把修复发掉。
| 信号 | 该行动的阈值 | 按什么切分 | 动作 |
|---|---|---|---|
| 无崩溃会话率 | < 99% | 设备、系统、运行时 | 排查 + 灰度 |
| ANR 率 | 上升趋势 | 设备型号 | 主线程打样 |
| 按运行时的回退 | 较上一版任何下降 | 运行时版本 | 回滚路径 |
| 不可复现崩溃 | > N 用户 | 受影响数 | 排优先级，别埋 |
