附录 B 双案例唯一事实表

这份附录的效力

卷一使用拾光工作室的两款产品作为案例。所有章节引用的规模、包体、帧率、内存、崩溃率、时延，只能来自本附录。正文与其它附录出现不一致时，以本表为准。

需要先说清楚性质：表中的数字全部是案例设定值，用于演练口径、比较取舍、验证判断，不是任何一台设备的实测结果，也不是任何真实产品的运营数据。书里需要真机才能得出的结论，会明确标注「需真机验证」。

一、工作室与产品

拾光工作室持有「潮汐」IP，同时运营两款移动游戏，共用账号、支付、活动、数据与发行中台。

从这张表可以直接读出两组相反的约束：

• 消消：DAU 高、单局短、低端机多、包体小、弱联网、广告收入过半。它的架构优先级是「低端机不崩、首启转化高、广告加载不打断玩法」。
• 方舟：DAU 低、单场长、低端机少、包体大、强联网、内购为主。它的架构优先级是「战斗不断线、进度可恢复、版本可控」。

这两组优先级不可能同时满足一套实现，这就是1.1 一个 IP 两款产品 要讨论的核心问题。

二、共用与隔离

发布节奏：消消每周二更新活动资源；方舟每两周周四发版本，每周更新活动。两者共用同一套 CDN 与灰度平台，但灰度批次、回滚窗口和放量比例各自独立。

**这张表是卷四「平台化与长线治理」的起点。**卷一只关心客户端侧的隔离边界：哪些能力可以共用一套实现，哪些必须按产品分叉。

三、客户端基线

指标定义与常见误用见附录 A 术语与指标速查 。读这张表时有三个陷阱需要避开：

1. 崩溃率低不等于体验好。 方舟 0.12% 低于消消 0.18%，但方舟一场 8–12 分钟，一次崩溃的损失远大于消消的一局 90 秒。同样的比率，方舟的玩家感知更差。
2. Jank 率不能直接横比。 方舟 60fps 下总帧数约为消消 30fps 的两倍，分母不同，同样的长帧数量会算出更低的比率。
3. 内存水位不是设备上限。 420MB 和 1,150MB 是「产品可接受的上限」，不是「设备能扛的上限」。真正的杀进程线由系统决定，水位必须留出余量。

四、各章主案例分工

卷一每节只选一个主案例，另一个案例在关键分歧处作对照，每段不超过 150 字。

如果某个结论只对主案例成立，正文会明确写「在消消的约束下」或「对方舟这种单场时长」。没有条件限定的结论，默认对两款产品都成立。

五、数字使用规则

写作与评审时遵循以下五条：

1. **写「案例设定」，不写「实测」。**除非同时给出本机命令与输出，否则不得使用「实测」「生产数据」「线上真实」等措辞。
2. **不引入第二套数字。**需要新数字时，先补进本附录，再在正文引用。禁止在正文里临时编一个「大约 5%」，与主表冲突。
3. **整数口径。**包体用 MB，内存用 MB，时间用毫秒或秒，金额用微元。不要用浮点四舍五入后再引用。
4. **比较前先对齐口径。**跨产品比较帧率、崩溃率、内存之前，先确认分母、目标帧率与机型分档一致。
5. **区分模型与设备。**凡是需要真机才能得出的结论（温控曲线、实际功耗、传感器噪声），正文必须标注「模型，不是设备实测」。

六、案例之外

这套案例刻意没有覆盖三件事，读到时不必寻找数据：

• 品类数值与关卡设计：三消的难度曲线、卡牌的战力公式，属于产品设计，不属于客户端架构。
• 服务端实现细节：协议格式、同步算法、分布式部署，属于服务端书稿的范围，卷一只写客户端责任。
• 真实市场数据：买量成本、渠道分成、留存曲线不在本表范围内，卷三讨论商业化时另行设定。

案例的目的不是模拟一家真实公司，而是提供一组稳定、自洽、可对照的约束条件。只要约束稳定，书里的判断就能被复核；一旦约束漂移，所有结论都要重算——这也是团队在使用任何架构建议前，第一步就该确认自己的约束表的原因。