被抽成 30% 之后，还有活路吗？
每个小游戏团队都做过同一道餐巾纸背面的算术：收入减 30% 等于能活。然后他们就停在这儿了，好像 30% 是物理定律。它不是。它是一条特定路上的过路费——而路不止一条。我们把这笔抽成到底是什么、以及把那些被大字标题藏起来的成本算清之后还剩什么，拆开来看。
Q：应用商店的 30% 抽成是固定的吗？
如果是通过 App Store 或 Google Play 分发的原生 App，是的——写进合同、在支付层强制执行。但"30%"只描述了一条分发路径。一旦你的游戏跑在 runtime 或超级 App 里、而不是一个独立的原生二进制包，费率结构就变了，因为收钱的主体不再是拥有设备的那一方。这笔税是路上的过路费，不是地心引力税。
Q：runtime 或小游戏平台真能打穿 30% 吗？
看它收的是什么钱。一个托管你的游戏并替你处理支付的 runtime，会拿走一份平台分成，但这份分成是谈出来的、通常低于商店；而且关键是，它往往把托管、分发、以及一个你原本要花钱买量才能拿到的共享用户池打包进去了。跑在 runtime 上的团队，留下的通常远多于被商店税刮剩的 70%——部分原因是 runtime 的分成同时替掉了商店费和一块营销开支。
Q：用 webview 把支付绕开商店抽成，合规吗？
这是条不能随便踩的线。商店禁止在原生 App 内把数字商品的支付引向外部，而且会强制执行。而活在 runtime 里的小游戏是另一回事：runtime 本身就是分发面，所以支付关系是和 runtime 发生的，而不是原生 App 外面违规接的旁路。在原生商店的支付墙之外另起炉灶是合法的；从里面偷偷绕过去，是团队被封号的常见姿势。
Q：我到底该怎么算"我留下多少"？
别盯着大字标题的费率，把整条栈算全：平台分成，加上 2–3% 的支付手续费，加上买量成本——那个沉默的杀手——再加上拒付和退款。一款先被商店抽 30%、又把 40% 收入拿去买量的游戏，比一款 runtime 分成 15%、还继承了一池温热用户的游戏更惨。净到手才是那个发得出工资的数字。
Q：小团队该选哪条渠道？
选那条"渠道的抽成能换回你单干买不起的东西"的：一池用户、一条在你目标市场能跑通的支付通道、或者免应用商店审核的即时分发。小团队死在获客上，不是死在费率百分比上。先选一个能把玩家递到你手里的渠道，再从那里优化净到手。
| 渠道 | 典型抽成 | 你得到什么 | 坑 |
|---|---|---|---|
| App Store / Google Play | 15–30% | 计费、信任、覆盖 | 支付被锁、审核周期 |
| runtime / 小游戏平台 | 约 10–20% | 托管 + 共享用户 + 本地支付 | 上了它的轨道 |
| Web 直连（webview） | 仅支付手续费（约 3%） | 完全掌控 | 买量全自己扛 |
| 运营商 / 电子钱包代扣 | 10–25% | 触达无卡人群 | 逐个市场接 |
