从一个让人困惑的现象说起上一篇提到善用增量构建能大幅提速但你在实际用的时候一定遇到过这种诡异的情况“同样是改一行代码点 Build——有时候 30 秒就好了有时候却要等 20 分钟从头来过。明明改动量差不多凭什么差这么多”这背后就是增量构建Incremental Build在起作用或者说在失效。增量构建不是一个你能开启的开关而是 IL2CPP 内部一套自动运转的机制。它有时帮你省下巨量时间有时却悄悄失灵让你全量重来——而决定它灵不灵的规则恰恰是很多人从没搞懂的。这篇我们就钻进去看清它到底是怎么判断什么该重编、什么能复用的。搞懂了你就能主动创造让它生效的条件而不是碰运气。先建立核心概念全量 vs 增量全量构建Full Build 不管你改了什么把所有代码从头到尾重新走一遍完整流程 C# → IL → C → 机器码一个不落全部重来 → 稳但极慢 增量构建Incremental Build 只重新处理【改动过的部分】没变的直接复用上次的成果 → 快但前提是能准确判断出什么变了、什么没变增量构建的全部难点就浓缩在最后那句话里怎么准确判断什么变了。判断错了会出大问题——该重编的没重编你的改动没生效构建结果是错的不该重编的重编了白白浪费时间退化成全量。所以整套机制的核心就是一个精密的**“变化侦测系统”**。IL2CPP 的流程回顾增量发生在哪几层要理解增量在哪起作用先回顾 IL2CPP 那条流水线因为增量构建在每一层都可能发生C#代码 ──① 编译──▶ IL(托管DLL) ──② 转译──▶ C代码 ──③ 编译──▶ .obj目标文件 ──④ 链接──▶ 最终可执行文件 │ │ │ │ 增量点① 增量点② 增量点③ 增量点④ 只重编改动的 只重转译 只重编改动的 重新链接 C#程序集 变化的类型 C文件 这步通常绕不过关键认知增量不是整体要或不要而是流水线上一层层的、细粒度的复用。你改一行代码理想情况下改动一个方法的实现 → ① 只有它所在的程序集重新编成 IL ② 只有受影响的类型重新转译成 C ③ 只有变化的 C 文件重新编成 .obj ④ 重新链接用大量复用的 .obj 少量新的绝大部分 .obj 文件可能成千上万个都原封不动地复用了——这就是增量构建快的根本原因真正重新干的活只占总量的极小一部分。核心机制一靠什么判断变了没变——指纹比对那 IL2CPP 到底怎么知道某个文件没变、可以复用答案是——给每个东西算一个指纹比对指纹是否一致。这个指纹通常是哈希值Hash把文件内容或某段输入通过算法压成一个短短的、几乎唯一的字符串。内容变一个字节指纹就完全不同。指纹比对的逻辑 上次构建算出 C文件A 的指纹 a3f9...存进缓存 并把它编译出的 A.obj 也存进缓存 这次构建重新算 C文件A 的指纹 ┌─ 指纹还是 a3f9... → 内容没变 → 直接拿缓存里的 A.obj跳过编译 └─ 指纹变成 b7c2... → 内容变了 → 老老实实重新编译为什么用指纹而不是用修改时间早期很多增量系统靠文件的时间戳判断文件修改时间变了就重编。但时间戳不可靠——比如从版本控制拉取文件、切换分支时间戳会变但内容其实一样导致明明没变却触发重编。用内容哈希则精准得多只认内容不认时间。内容一样指纹就一样就一定复用。用一个类比这就像海关比对指纹而不是比对你几点来的。只要指纹内容对得上就是同一个人同一份成果几点来的时间戳根本不重要。核心机制二光比对自己不够——还要追踪依赖这里有个更深的问题也是增量构建最精妙的地方。你可能会问“我改的是文件 A那重编 A 不就行了为什么有时候改一个文件一堆别的文件也跟着重编了”因为代码之间有依赖关系。文件 A 如果被文件 B、C 引用那 A 变了B、C 编译出来的结果可能也得跟着变。依赖传染的例子 你改了一个结构体 Foo 的字段比如加了个成员 │ ▼ 所有 #include 了 Foo、用到 Foo 的 C 文件 │ 它们编译出的机器码布局都可能受影响 ▼ 这些文件全都必须重新编译哪怕你没直接碰它们所以增量系统不能只看这个文件自己变没变还必须维护一张依赖关系图Dependency Graph记录谁依赖谁。判断一个文件要不要重编时它要综合看一个 C 文件需要重编当且仅当 ① 它自己的内容变了指纹变了 或 ② 它依赖的任何东西变了被依赖项指纹变了 或 ③ 编译它用的参数/环境变了见下一节这就解释了改一行却带崩一片的现象你改的那行如果动到了一个被广泛依赖的核心类型比如一个到处都在用的基类、结构体、常量依赖它的一大片文件都会顺着依赖图被判定为需要重编。反过来如果你改的是一个没人依赖的孤立函数实现那就真的只重编它一个飞快。给你一个实用推论改动越底层、越被广泛依赖的东西增量构建能省的越少。想让增量快尽量把改动局限在叶子节点没人依赖的具体实现少动根节点被大量引用的公共定义。核心机制三为什么有时什么都没改也全量重来——缓存全局失效现在解答开头那个最气人的情况改动明明很小却触发了 20 分钟的全量重建。原因是有些改动会让整个缓存全局失效逼着所有东西重来。这些通常是改变了编译的前提条件的操作会导致缓存大面积/全局失效的典型操作 ① 切换 Code GenerationFaster runtime ↔ Faster builds → 生成 C 的策略变了 → 之前所有 C 和 .obj 全作废 ② 切换 Managed Stripping Level剥离等级 → 保留/删除的代码范围变了 → 转译输入全变 → 全量 ③ 切换目标平台 / 架构如 armv7 ↔ arm64 → 机器码目标都不同了 → 之前的 .obj 完全没法用 ④ 升级 Unity 版本 / IL2CPP 运行时 → 转译器和运行时本身变了 → 一切归零 ⑤ 手动删除 Library 或构建缓存目录 → 缓存本体都没了 → 只能从头来 ⑥ 改动全局编译宏 / 预处理符号Scripting Define Symbols → 相当于改变了所有代码的编译条件 → 大范围失效看懂这些的共同点没有它们改的都不是某个文件的内容而是编译所有文件的前提/规则。前提变了之前基于旧前提算出来的所有成果就全部作废——哪怕你一行业务代码都没动。这也是为什么前一篇强调别频繁切 Stripping Level、别乱清缓存——这些操作会把你辛苦攒下的增量缓存一次性清零代价就是一次完整的全量构建。用类比说增量缓存就像你按某个菜谱做好的一堆半成品。如果你只是换一道菜的一个配料改一个文件大部分半成品还能用。但如果你换了整本菜谱改了全局编译规则或者把冰箱清空了删缓存那所有半成品都得重做。把三个机制串起来一次增量构建的完整决策现在把整套逻辑合起来看一次构建时 IL2CPP 内部是怎么决策的构建开始 │ ├─▶ 先检查全局前提变了吗平台/剥离等级/CodeGen/Unity版本/缓存是否存在 │ │ │ ├─ 变了 → 缓存全部作废 → 全量构建那 20 分钟的来源 │ │ │ └─ 没变 → 进入细粒度增量判断 ↓ │ ├─▶ 对每个 C 文件算指纹 查依赖图 │ │ │ ├─ 自己没变 且 依赖没变 → 复用缓存的 .obj跳过 │ │ │ └─ 自己变了 或 依赖变了 → 重新编译这个文件 │ └─▶ 用【大量复用的 .obj 少量新编的 .obj】重新链接 → 出包 链接这步基本每次都要做所以增量再快也有个下限这张图就是开头那个困惑的完整答案“改一行 30 秒搞定” 全局前提没变且你改的是叶子节点只有极少数文件重编“改一行 20 分钟” 要么你触发了全局失效切了某个设置/清了缓存要么你改的是被广泛依赖的核心类型带崩了一大片。实践建议主动为增量构建创造条件理解了原理就能主动让增量构建站在你这边① 开发期锁定构建设置别来回切。把平台、Stripping Level、Code Generation 在开发阶段固定下来。每切一次就是一次全量的代价。要切也集中切别今天开明天关。② 别手贱清缓存。清一下缓存试试是很多人遇到问题的下意识动作但它直接毁掉增量的基础。除非你确信是缓存损坏导致的问题否则别动 Library 和构建缓存目录。③ CI/构建机上持久化缓存目录。自动化构建最容易犯的错是每次都在全新的干净环境里从零构建——那永远是全量。把 IL2CPP 缓存目录在构建机之间持久化/复用下来第二次之后就能吃到增量红利。④ 让改动尽量局部化。把频繁改动的逻辑尽量与被广泛依赖的核心定义隔离开。改具体实现叶子很快改公共基类、公共结构体、全局常量根会牵连一大片。合理的架构分层本身就在帮增量构建减负。⑤ 结合程序集拆分asmdef。上一篇提过清晰的程序集划分让改 A 模块只重编 A。在 IL 编译这一层增量点①它的收益尤其明显——改动被关在一个程序集里不会污染整个 IL 编译。总结IL2CPP 增量构建的本质一套精密的变化侦测 成果复用系统 三大核心机制 ① 指纹比对给每份输入算内容哈希指纹没变就复用成果 只认内容不认时间戳 → 精准 ② 依赖追踪维护依赖图被依赖的东西变了依赖方也要重编 这就是改一行带崩一片的来源 ③ 全局前提平台/剥离等级/CodeGen/Unity版本/缓存存在与否 这些一变整个缓存作废 → 全量重来 这就是没改啥却等 20 分钟的来源 一次构建的决策 先看全局前提变没变 → 变了就全量 没变 → 逐文件用指纹依赖图判断只重编真正受影响的 → 最后用大量复用 少量新编链接出包增量构建之所以时快时慢从来不是玄学——它背后是一套有明确规则的判断系统。它快是因为绝大多数成果都能靠指纹比对复用它偶尔慢要么是你的改动通过依赖链波及了一大片要么是你无意中改动了全局前提让缓存整体作废。看清这套规则后你就从碰运气变成了主动创造条件锁定设置、爱护缓存、局部化改动、拆分程序集——每一条都是在帮那套侦测系统更多地判定这个能复用。这其实还是这个系列反复出现的那个内核——优化的本质是不做重复和无用的功。全量构建的浪费在于它把上次已经算对、这次根本没变的东西又老老实实重算了一遍。增量构建的智慧就是精准地认出这部分没变、不必再做然后把省下的时间还给你。理解它你等的就不再是一顿饭而是一杯还没凉的咖啡。