《Cocos 游戏开发高级编程》11.2 选型方法与迁移成本

11.2 选型方法与迁移成本

11.1 给了一张横向对照表，这一节把它变成可执行的方法。选型要回答两个问题：这款引擎适不适合我，以及如果不适合，换过去要付多大代价。前者是判断题，后者是估算题——两题都答清楚，才算真正做完选型。

先说一个反常识的前提：选型很少是「自由比较」，多数是「带约束的选择」。团队已有语言栈、产品已有目标平台、上线已有时间窗，这些约束一摆出来，候选范围往往只剩一两个。所以方法的第一步不是「比引擎」，而是「认清约束」。

11.2.1 先问三个前置问题

在做任何横向对比之前，先把这三个问题回答清楚。它们排在最前面，因为后面的每一项比较都建立在它们的答案之上。

这三问的共同点是：它们问的不是引擎，而是你自己。跳过这一步直接比引擎，是选型失败最常见的原因——比了一圈发现「都挺好」，因为根本没有约束来淘汰候选。

逐个展开这三问的实操含义：

• 目标平台是硬约束。它不像性能那样可以「优化到位」，而是「过不了就是过不了」——一个不能在微信小游戏上跑起来的引擎，性能再好也与你无关。把平台列成清单（H5、微信、抖音、Android、iOS、桌面、主机），逐条确认候选引擎的支持情况。
• 团队栈是隐性大头。学习一门新语言本身的成本可能只有一两周，但「整个团队用新语言重写、还要达到原有质量」的成本，往往被严重低估。前端背景的团队选 Cocos 或 Phaser，几乎零学习成本；选 GDScript 或 Lua，则要为每个人乘上一段时间。
• 生命周期决定你更看重什么。短周期项目（原型、活动页、比赛作品）优先上手速度，能最快出东西的引擎就是好引擎；长周期项目（持续运营的线上产品）优先生态与可维护性，工具链、社区、长期更新承诺都比「上手快」重要得多。

把这三问的答案写下来，你会得到一张「约束卡」——后面所有比较都在这张卡的边界内进行，任何越界的候选都可以直接划掉。

11.2.2 决策树：按项目特征逐层筛

把三个前置问题展开成一条可执行的判断链。下面这棵树不是「标准答案」，而是一个把约束逐层落地的模板——你可以按自己项目的实际情况增删分支。

Q1 必须发布微信 / 抖音等小游戏吗？
   ├─ 是 → 优先 Cocos Creator（多端适配成熟）
   └─ 否 → 进入 Q2

Q2 团队主力语言是 TypeScript / JavaScript 吗？
   ├─ 是 → Cocos Creator / Phaser 学习成本最低
   └─ 否（愿意学 GDScript 或 Lua）→ 进入 Q3

Q3 对包体与冷启动是否极敏感（例如 < 5 MB）？
   ├─ 是 → Defold，或做过模块裁剪的 Cocos（见第 9 章）
   └─ 否 → 进入 Q4

Q4 是否需要重度 3D？
   ├─ 是 → Godot / Cocos（按团队熟悉度取舍）
   └─ 否 → 默认 Cocos Creator（本卷的 2D 多端场景）

这棵树的读法是「从硬约束往软偏好走」：Q1、Q3 是硬约束（平台与包体过不了就出局），Q2、Q4 是软偏好（影响的是效率，不是可行性）。先硬后软，能避免在软指标上纠结半天、最后被一个硬约束推翻。

决策树还有一个容易被忽略的好处：它把「谁来做决定」这件事显性化了。Q1 由产品与发行决定，Q2 由团队现状决定，Q3、Q4 由技术负责人决定——把每个分支的决策人标出来，能避免「技术团队替产品定了平台」这类越界。

要提醒的是：这棵树不是一次性结论，而是会随项目演进的活文档。早期项目平台未定，树的走向偏保守（选覆盖广的引擎）；产品方向明确后，树的走向会收窄。把它写进项目的技术决策记录（ADR），每次重估都有据可查。

11.2.3 量化：把直觉变成加权打分

决策树能筛掉明显不合适的，但剩下的候选之间往往「各有优劣」。这时候可以用加权打分把直觉量化——权重的选择才是真正的决策，分数只是让分歧显性化。

下面这段是纯 TypeScript，不依赖任何引擎，可以直接用 vitest 断言。

// 引擎选型：加权打分（纯逻辑，可直接单测）
export type Criterion = 'platform' | 'team' | 'bundle' | 'online' | 'ecosystem';

export interface Weights {
  readonly platform: number;
  readonly team: number;
  readonly bundle: number;
  readonly online: number;
  readonly ecosystem: number;
}

export interface Candidate {
  readonly name: string;
  // 每项为 0..1 的适配度，由团队按项目特征评估
  readonly scores: Readonly<Record<Criterion, number>>;
}

const CRITERIA: readonly Criterion[] = ['platform', 'team', 'bundle', 'online', 'ecosystem'];

export function total(weights: Weights, candidate: Candidate): number {
  let sum = 0;
  let weightSum = 0;
  for (const c of CRITERIA) {
    const w = weights[c];
    weightSum += w;
    sum += w * candidate.scores[c];
  }
  return weightSum === 0 ? 0 : sum / weightSum;
}

export function rank(weights: Weights, candidates: readonly Candidate[]): Candidate[] {
  return [...candidates].sort((a, b) => total(weights, b) - total(weights, a));
}

用《方块冲刺》的特征代入一次：要发 H5 / 微信 / 原生，团队是前端背景，包体要求中等，联机需求轻。对应的权重会自然偏向 platform 与 team，打分结果也会明显倾向 Cocos。注意：打分不能替你做决定，它的作用是让「我们到底更看重什么」这件事从模糊变清晰——如果打分结果和你的直觉相反，先别改分数，去检查权重是不是写错了。

五个评估维度的含义如下，评分时建议团队分开打分再取平均，避免一个人的偏好主导全局：

打分最容易犯的错是给所有维度打相近的分数——那等于没有权重。如果两个候选打出来分数接近，正确的做法不是「随便选一个」，而是回去重新审视权重：是不是有些维度你其实并不真的在意？

11.2.4 迁移成本怎么估

选型的另一半是「万一要换，代价多大」。迁移成本最容易被低估，因为人们只算「重写代码」，忘了资产、配置与回归。

估算的关键是分项：把迁移拆成互不重叠的几块，每块单独估，再相加。这样既不容易漏项，也方便在预算吃紧时判断「哪一块可以砍、哪一块不能砍」。一个更接近真实的公式是：

迁移成本 ≈ 引擎相关代码量 × 重写系数
         + 资产转换工作量
         + 工程与构建配置重做
         + 原生与三方 SDK 重接
         + 回归测试与磨合期

逐项拆开口径与参考系数：

这些系数是量级参考，不是精确值，请按你项目的实际结构复测。它们想传达的规律是：引擎无关的部分越多，迁移越便宜。这也解释了为什么第 10 章反复强调「模块化」与「引擎无关核心」——那不只是架构洁癖，它直接决定了你未来换引擎时的议价能力。

还有一个常被忽略的分项：磨合期。即使代码全部迁完、测试全部通过，团队熟悉新引擎的工作流、调试方式、构建流程，仍然需要一段时间。这段成本很难量化，但可以按「迁移工期的 20% ~ 30%」粗估。把它写进预算，能避免「代码写完了却迟迟发不出去」的窘境。

11.2.5 三种迁移策略

真到要迁移时，有三条路线，风险和工期差异很大：

对绝大多数团队，逐模块替换是现实解：先把「引擎无关」的部分（数据、逻辑、协议）抽出来，这部分迁移几乎零成本；再按业务模块逐个把「引擎相关」的部分重写，每迁一个就回归验证一个。双引擎并存适合产品确实需要长期多引擎支持的情况，但它的抽象层一旦设计过度，维护成本会反噬——这也是第 10 章「模块化」话题的延伸。

三条路线不是互斥的，可以组合：先用「全量重写」搭出新引擎的空壳骨架（场景、启动流程、构建配置），再用「逐模块替换」把业务一个个搬过去，最后如果确实要多引擎，再补一层「双引擎并存」的适配层。先立骨架、再搬业务、后加抽象，比一上来就设计完美抽象层要务实得多。

一个具体的判断标准：如果「引擎无关核心」的占比超过一半，逐模块替换的性价比最高；如果低于三成，全量重写往往更省事——因为大部分代码都要重写，保留旧结构反而碍事。

11.2.6 L2：平台能力探测与分支（可类型检查）

迁移与多端发布都绕不开「同一份代码在不同平台走不同分支」。Cocos 把这层能力放在 sys 上。下面这段组件读取平台信息并按分支初始化——所有符号均可在 cc.d.ts（3.8.8）中核到。

import { _decorator, Component, sys, view, screen } from 'cc';

const { ccclass, property } = _decorator;

@ccclass('PlatformGate')
export class PlatformGate extends Component {
    @property
    public minNativeVersion = 1;

    onLoad(): void {
        if (sys.isNative) {
            // 原生平台：走 JSB 能力（见第 8 章）
            this.setupNative();
        } else if (sys.platform === sys.Platform.WECHAT_GAME) {
            // 微信小游戏：走小游戏适配层
            this.setupMiniGame();
        } else if (sys.isBrowser) {
            this.setupWeb();
        }
    }

    private setupNative(): void {
        void this.minNativeVersion;
    }

    private setupMiniGame(): void {
        const visible = view.getVisibleSize();
        void visible;
    }

    private setupWeb(): void {
        const windowSize = screen.windowSize;
        void windowSize;
    }
}

这段代码本身很简单，但它是多端项目里唯一应该出现平台分支的地方：业务代码只调用 PlatformGate 暴露的接口，不直接问「现在是不是微信」。把分支收口到一处，迁移或加平台时你只需要改这一个组件，而不是全局搜 sys.platform。

这也呼应了 11.2.4 的迁移成本公式：sys.platform 这类判断就是典型的「引擎相关代码」，散得越广，重写系数越高。把它收进一个适配层，等于人为降低了未来的迁移成本——这是选型之后、真正动手前就该做好的准备。注意这里用的 sys.isNative、sys.platform、sys.Platform.WECHAT_GAME、view.getVisibleSize()、screen.windowSize 都是 3.8.8 的稳定 API，可在 cc.d.ts 中逐一核对。

11.2.7 什么时候不该换引擎

最后给一份「别换」的清单。它的价值不低于「该换」的判断：

判断标准可以浓缩成一句话：换引擎应该是一个有明确收益目标的工程决策，而不是一次技术情绪的宣泄。 如果你只能用「感觉更现代」来描述收益，那就还没到换的时候。

把这一节的方法浓缩成三步：认清约束 → 走决策树筛候选 → 用打分与迁移成本做最终权衡。任何一步跳过，选型都会变成凭感觉。这套方法不只在选引擎时有用——选框架、选后端语言、选云服务，骨架都是同一套。

最后再强调一次本节开头那句话：选型很少是自由比较，多数是带约束的选择。真正专业的选型，不是把所有引擎研究一遍，而是在认清约束之后，快速、有据地把候选缩到一两个，再为最终决定留下可复盘的理由。

换句话说，一份好的选型文档不是「我们选了 X」，而是「我们在什么约束下、排除了什么、为什么」。

下一节收尾：把整卷 11 章的线索收成一张全景图，并给出几条继续深入的方向。

阅读导航：上一节：11.1 跨引擎对照：Cocos / Godot / Phaser / Defold · 下一节：11.3 全景回顾与展望 。