一个 runtime 怎么摊起一整个小游戏目录？
"通用 runtime" 的卖点听着太整齐了：写一次、处处跑，让一套基础设施扛下一整个小游戏目录。怀疑它是应该的——但这套经济账不是空口白话。它来自删掉一整类成本，而不是打个折。我们把引擎盖打开看。
Q：共享 runtime 到底省了什么？
发布一款游戏贵的地方不是创意，是工厂：每个平台一份构建、每个商店一次提审、每个市场一套支付接入、每次发版一轮 QA。runtime 把这些都压成一份。你针对 runtime 的 API 写一次游戏，剩下的构建、商店关系、支付、分发都由 runtime 兜着。省下来的不是折扣，是整类成本的消失。
Q：游戏越加越多，边际成本怎么走？
往下走，而这正是关键。runtime 上的第一款游戏扛了大部分固定成本——接入、学习、搭建。第十款游戏更接近一个配置文件：新内容、新皮，管道不变。你的单游戏成本曲线陡降，这和跑 N 个独立原生 App 截然相反——后者每款都要把整座工厂再付一遍。
Q：跨游戏的共享用户池值多少钱？
这是电子表格算漏的部分。当几款游戏同处一个 runtime、共用一个目录，从 A 游戏跳走的玩家可以被轻轻推到 B 游戏，无需重新安装、也无需新的获客成本。runtime 内的交叉推广，把你的存量玩家变成最便宜的买量渠道——近乎免费，而且比任何广告网络都"温热"。目录会复利，一堆互不相通的 App 不会。
Q：耦合风险在哪？
你是在赌 runtime 的稳定性和路线图。如果 runtime 改了某个 API 或宕机，所有游戏同时受影响。这才是真正的交易：你把 N 种独立故障模式，换成了一个共享故障模式。缓解办法是让游戏逻辑保持可移植、对 runtime 专属特性的依赖降到最低，这样切换或分叉始终有可能。
Q：对单个独立游戏值得吗？
如果你只有一款游戏、也没做目录的野心，runtime 主要给你的是免商店税的发行与支付——值，但复利的优势还没启动。真正好听的经济账，是在你跑三款及以上时才奏效，因为那时边际成本的下坡和共享池才开始回哺你。一款游戏省一点；一个目录省的是结构性的。
| 成本项 | 自己来 | 用 runtime |
|---|---|---|
| 跨平台构建 | N 份 | 一份 |
| 商店提审 | N 次 | 已处理 |
| 支付接入 | 逐市场 | 共享通道 |
| 用户获取 | 每次都冷启动 | 温热的共享池 |
| 交叉推广 | 自己搭 | 内置 |
