三天冲刺手册

每个故事按这个骨架讲：

分水岭「否掉的方案」是主导者与执行者的分水岭，每个故事必备。被追问"为什么不用 X"时，你早有答案。

量化数字清单（面试前尽量凑齐）：

先讲机制（拉开差距的部分）

• Unity 托管堆用的是 Boehm GC：非分代、非压缩、Stop-the-World——不整理内存所以会碎片化；堆扩容后不归还系统，因此控制的是分配峰值，不是均值
• Incremental GC（增量 GC）只是把标记阶段分帧、摊平尖刺，总开销并没有变少——治本还是少分配
• 结论先行：目标是战斗热路径每帧 0 分配（0GC）

常见分配来源（能报菜名说明真排查过）

• 闭包捕获局部变量、装箱（值类型→object、enum 作字典 key 没实现 IEqualityComparer）、字符串拼接与 ToString()、LINQ
• Unity API 返回新数组：mesh.vertices、GetComponents、Physics.RaycastAll；协程里 new WaitForSeconds

手段

• 对象池（子弹/特效/UI 条目）、集合预分配容量并复用、NonAlloc 系 API、StringBuilder 复用 + 常用字符串查表缓存、WaitForSeconds 缓存复用
• 工程化落地：Profiler 按 GC.Alloc 列排查（开 Call Stacks 定位到行）；把「战斗每帧 0GC」做成准入标准，自动化场景跑 CI 卡口

加分点UniTask（0GC 的 async/await 替代协程）、struct + 泛型约束避免装箱、ArrayPool<T>.Shared、Span<T> / stackalloc。

先分类，再选工具

• 第一步分类：尖刺还是持续低帧？尖刺常见于 GC、Instantiate、加载、Shader 首次编译；持续低帧再分 CPU bound 还是 GPU bound
• 判断依据：主线程里 Gfx.WaitForPresent 占比高 = GPU bound；WaitForTargetFPS 只是垂直同步等待，不是瓶颈

工具链（按顺序讲成流程）

• 真机 Development Build 连 Profiler（强调必须真机测，编辑器数据会骗人）；Deep Profile 开销大只用于小范围；自定义 Profiler.BeginSample 打点
• Profile Analyzer：多帧统计 + 优化前后对比；Memory Profiler：快照 diff 查泄漏与重复资源
• Frame Debugger：逐 DrawCall 回放，直接告诉你两个物体为什么没合批的原因
• GPU 深挖：RenderDoc（安卓）、Xcode GPU Frame Capture（iOS）、Snapdragon Profiler / Arm Streamline（看带宽和着色器占用）
• Shader 首次编译卡顿：ShaderVariantCollection 收集变体 + 加载期 WarmUp 预热

加分点讲你建立过性能基线：低/中/高配各定一台代表机型，帧率、内存、发热指标进每日自动化——这是「主导者」级别的答法。

先讲原理

• 发热 = 持续功耗的积分；SoC 到达热墙后热节流（降频）→ 帧率断崖。所以控发热就是控平均功耗：CPU（逻辑量、帧率）、GPU（分辨率、overdraw、后处理）、带宽（对移动端功耗影响极大）、网络/GPS

手段（分档 + 动态降级）

• 帧率分档：Application.targetFrameRate——大厅 30 / 战斗 60；静止界面用 OnDemandRendering 降到 10~15fps
• 接入 Adaptive Performance：监听热状态回调（warning / throttling）→ 自动触发降级链：动态分辨率 → 降 LOD bias → 降阴影档 → 关高开销后处理
• 画质分档系统：启动时按机型（SoC / 内存）落到低/中/高配置档，允许玩家手动覆盖

「长效稳定性」要接住

• 2 小时挂机测试看内存增长曲线；泄漏用快照 diff；后台切换时释放 RT / 暂停下载；断线重连兜底——JD 写「不同档次硬件上的长效稳定性」，就是想听这套

加分点提帧预算概念：30fps = 33ms，给 CPU 逻辑 / 渲染提交 / GPU 各分配目标毫秒数，超预算的系统限期整改——预算制管理是团队级优化的标志。

先报全景（Memory Profiler 视角）

• 典型占比排序：纹理 > 网格 > 音频 > 动画 > 托管堆，另有 Native（引擎 + 第三方插件）容易被忽略

逐项压缩

• 纹理：ASTC 压缩，按用途选块大小——4×4 高质量 UI / 6×6 常规 / 8×8 远景贴图；老安卓回退 ETC2；关闭 Read/Write Enabled（否则 CPU 侧多留一份拷贝）；开 Mipmap Streaming；SpriteAtlas 图集治理，避免超大图集常驻
• 网格：Vertex Compression / Mesh Compression、Index Format 16bit、剔除不用的 normal / tangent / uv2 通道、同样关 Read/Write
• 音频：长 BGM 用 Streaming，短音效 Decompress On Load，中等用 Compressed In Memory；Vorbis 质量压到听感无损即可
• Shader：变体爆炸是隐形大户——shader_feature 与 multi_compile 的区别、变体裁剪（Stripping）
• 资源生命周期：AB 卸载 Unload(true/false) 的时机、Resources.UnloadUnusedAssets + GC 组合拳、引用计数兜底

一句话定义

• SRP（Scriptable Render Pipeline）：Unity 把「怎么画一帧」的调度权开放成 C# 可编程框架——剔除、绘制排序、Pass 组织、后处理都能用 C# 定义；URP / HDRP 都是基于 SRP Core 的官方实现

URP 相对 Built-in 的关键差异（挑三个讲透）

• 单 Pass 前向渲染：一个 Pass 处理多光源（Built-in 每盏逐像素光多一个 Pass）；URP 14+ 引入 Forward+，用分簇光源列表突破逐物体光源数限制——移动端多光源成为可能
• SRP Batcher：新的合批路径（下一题展开）
• Renderer Feature / ScriptableRenderPass 扩展点：描边、扫描、屏幕特效不用改引擎、不用 Camera 堆叠 hack
• Shader 层：纯 HLSL + Shader Library，不兼容 Built-in 的 Surface Shader——迁移成本主要在这

加分点Unity 6 用 Render Graph 重构了 URP：自动管理 RT 生命周期、自动合并 Pass、减少 load/store——直接降带宽（移动端功耗第一大户）；配套 GPU Resident Drawer 和 GPU Occlusion Culling。能讲出这个 = 在跟进引擎演进。

先纠正一个常见误区

• 合批优化的是 CPU 提交开销（SetPass / DrawCall），不是 GPU 像素成本——GPU 瓶颈时合批救不了你

三种机制的原理区别（深度信号）

• SRP Batcher：不减少 DrawCall，减少的是 SetPass 之间的 uniform 提交——把材质属性持久化在 GPU 的 CBUFFER（UnityPerMaterial / UnityPerDraw）里，同一 Shader 变体的连续绘制不重传材质数据；条件是 shader 声明兼容的 CBUFFER 布局
• GPU Instancing：同 Mesh + 同材质的大量重复物（草、树、子弹、地图标记）一次 DrawCall 画 N 个实例，逐实例数据走 instance buffer；需要显式开启
• Static Batching：构建期合并静态网格，用内存和包体换 DrawCall——大场景要算这笔账；Dynamic Batching 顶点数限制太小，URP 下基本可以放弃

主动说坑MaterialPropertyBlock 会打断 SRP Batcher——Built-in 时代的省内存技巧在 URP 下反而负优化；逐物体改属性应改用材质实例或走 Instancing 路径。说出这条 = 真踩过坑。

UI 是另一套体系

• UGUI 合批看 Canvas：Canvas 重建（Rebuild）是 UI 性能第一杀手——动静分离拆 Canvas、图集统一、避免层级交叉打断合批；用 UI Profiler / Frame Debugger 分析

加分点Unity 6 的 GPU Resident Drawer = 建立在 BatchRendererGroup 之上的自动化大规模 Instancing，万级同屏物件收益巨大——正好接你的大地图标记签名题。

先讲硬件特性（这是分水岭）

• 移动 GPU 是 TBDR（Tile-Based 分块渲染）架构：先分 tile 在片上内存渲染，再整块写回主存——带宽是第一敌人，带宽 = 功耗 = 发热（和板块 1 的 Q3 打通）
• 推论一：MSAA 在 tile 片上内存内解析，代价远低于桌面——移动端 4x MSAA 是可用的
• 推论二：减少 RenderTexture 切换和 load/store 操作（每次切 RT 都是整块 tile 写回再读入）；Unity 6 的 Render Graph 自动做这件事

逐项要点

• Overdraw：半透明堆叠是大头——特效层数预算、全屏遮罩用不透明、UI 隐藏时禁 Canvas 而不是 alpha=0
• URP 两个昂贵开关：Depth Texture / Opaque Texture 按需开——各多一次全屏拷贝，中低端机成本显著
• 后处理：合并全屏 Pass、Bloom 降分辨率采样、中低端档直接关
• 阴影：Shadow Distance 压短、Cascade 1~2 档、静态烘焙 + 近距动态实时的混合光照
• Shader 精度：能用 half 不用 float（mediump 在移动 GPU 上吞吐翻倍）、避免复杂动态分支

• 结构：ScriptableRendererFeature（注册与配置）+ ScriptableRenderPass（实际渲染逻辑），通过 RenderPassEvent 指定插入时机（如 AfterRenderingOpaques）
• 可讲的实例：描边（法线外扩 or 后处理边缘检测）、UI 毛玻璃背景（抓屏 + 降采样模糊）、扫描线 / 径向模糊、遮挡剔除后的 X-Ray 透显
• 主动说成本：抓屏类 Pass 有全屏拷贝的带宽成本，中低端机要降分辨率做或直接关——接回 TBDR 那题的带宽逻辑

加分点提一句 Unity 6 下 RenderPass 迁移到 Render Graph API（RecordRenderGraph）的写法变化，说明你的知识在保鲜。

先定义「数据驱动」（JD 第一条的核心词）

• 数据驱动 = 行为由数据描述而非硬编码——策划改配置就能改玩法，不进代码、不发版本。这是 JD 「数据驱动架构」四个字要听的定义

SO 的三层用法（逐层给场景）

• ① 配置资产：技能 / 关卡 / 剧情节点做成 ScriptableObject——Inspector 可视化编辑、版本管理 diff 友好、能直接拖引用其他资产（图标、特效 prefab），这是纯文本配置做不到的
• ② SO 事件通道：GameEvent 资产 + Listener 组件，系统间零引用解耦——UI 和战斗逻辑互不依赖，只共享一个事件资产
• ③ 运行时共享状态（RuntimeSet）：如「当前活着的敌人集合」做成 SO 容器，各系统读同一份，替代满天飞的 Singleton

主动说坑编辑器下运行时修改 SO 会持久化（退出 Play 不还原，和 MonoBehaviour 相反）；打包后 SO 只读，运行时改动仅存内存——所以 SO 不能当存档用。

赢过大多数人的一句数千行大表（道具/数值）走 Luban 这类 Excel → 二进制的自动化管线（生成代码 + 数据、支持热更、CI 里跑表校验）；SO 留给策划就地调参、强类型少量配置、编辑器工作流。讲清这个边界 = 真的搭过配置体系。

选型一句话

• FSM 回答「我处于什么状态」，行为树（BT）回答「我此刻该做什么决策」——UI 流程 / 网络重连 / 角色移动用 FSM；AI 决策用 BT；复杂 Boss 可以 BT 节点里内嵌 FSM

实现要点（防止被追问「怎么写的」）

• FSM：状态接口 Enter / Tick / Exit，转换表数据化（而不是 switch 巨兽）；状态爆炸就升级 HFSM（层级状态机）——「移动」大状态内嵌走/跑/跳
• 行为树：组合节点（Sequence / Selector / Parallel）+ 装饰器 + 叶子节点；黑板（Blackboard）共享数据；性能优化用事件驱动——不每帧 Tick 全树，条件变化时才重新评估（观察者中止）；节点定义与运行时实例分离（享元），千个 AI 共享一棵树定义

贴 JD「多阶段业务流程的稳定运行」

• 举主流程状态机：登录 → 设备检查 → 热更（下载/校验/重试） → 资源预载 → 大厅 ⇄ 战斗；每个状态定义超时和失败的转移目标；断线重连可从任意状态进入并正确归位——异常态设计才是「稳定运行」四个字想听的

加分点做过状态机可视化调试工具（编辑器里画状态图、高亮当前状态）；主流程每个状态耗时埋点上报，用来定位启动漏斗——工具意识是骨干的标志。

引用计数机制

• 每次加载返回 AsyncOperationHandle，Load 与 Release 严格配对；bundle 的计数归零才真正可卸载——handle 不释放 = bundle 常驻 = 隐形内存泄漏（Addressables 详解见词条）
• 排查：Event Viewer 看引用计数曲线；封装加载器统一托管 handle 生命周期（绑定 UI/场景生命周期自动 Release），不让业务代码裸调
• 坑：WaitForCompletion 同步加载在真机上的卡顿；一个小资源因依赖链拖出整个大 bundle

分组策略（JD 说「自动化资源构建」，讲成管线）

• 分组三维度：更新频率（常改的活动资源独立成组）× 功能模块 × 依赖关系——共享依赖单独成组，避免被多组各复制一份（duplicate dependency）
• 构建管线：CI 触发 → BuildPlayerContent 产出 bundle + catalog + hash → 上传 CDN → 客户端启动 CheckForCatalogUpdates → 增量下载；首包资源与边玩边下的划分是包体优化的核心决策

加分点提 YooAsset 对比（引用计数更透明、原生支持边玩边下、贴国内 CDN 习惯）；打包前跑资源静态分析（冗余引用/丢失引用检测）；热更下载成功率埋点——正好回应 JD 的「引用计数管理及热更新管道」。

原理对比（一句话见高下）

• HybridCLR：给 il2cpp 运行时补了一个 IL 解释器，AOT 代码与解释执行可以互操作——所以全 C# 语法可用（泛型/委托/async），开发体验和原生一致，心智负担趋近于零
• ILRuntime：独立实现的 C# 解释器，热更域和主工程跨域调用要写适配器（绑定代码、值类型装箱问题），性能差一个量级，社区维护已放缓——新项目直接 HybridCLR，这在 2026 年是行业共识

完整热更流程（背下来，会被要求走一遍）

• 工程划分：AOT 程序集（框架/启动器，进包）vs 热更程序集（业务逻辑，dll 随资源下发）
• 处理两个经典问题：AOT 泛型实例缺失 → 补充元数据 dll（LoadMetadataForAOTAssembly）；link.xml 防裁剪，保住反射用到的类型
• 启动链路：校验版本清单（hash 比对）→ 下载热更 dll + 资源 → 补充 AOT 元数据 → Assembly.Load → 反射进入热更入口
• 工程化：清单 + hash 校验 + 断点重试；灰度发布（白名单/渠道放量）；回滚方案——说到灰度和回滚，就是主导者视角

如果你项目用的是 Lua坦率说背景（xLua/toLua 是上一代主流，双语言心智成本 + 跨语言调用开销），再给出对 HybridCLR 的调研判断——主导者视角是「我知道什么时候该迁移、迁移的代价是什么」。

方案选型

• VideoPlayer（自带）：本地短片够用，移动端格式兼容差、流媒体弱；商用选 AVPro Video：HLS 流媒体、硬解码、透明视频、精准 seek；重度视频产品自研封装原生播放器（安卓 ExoPlayer / iOS AVPlayer 插件桥接）
• 编码：H.264 保兼容基线；H.265/HEVC 省 30~50% 带宽但低端安卓硬解不稳；服务端备码率阶梯（ABR）

多级缓存（JD 原词「多级本地缓存」）

• 三级：内存（解码帧/热点短片）→ 磁盘 LRU（容量上限 + 过期清理，按分片存储）→ CDN
• HLS 的 m3u8 + 分片天然支持边下边播、断点续传、分片级缓存复用；WiFi 下预取下一集
• 渲染侧：视频输出到 RenderTexture 上 UI / 3D 表面；安卓走 OES 外部纹理减少一次拷贝；注意视频 RT 的内存占用

• 讲的时候把每一环接到其他板块：享元（设计模式题）、对象池与 0GC（性能题）、合批与 Instancing（渲染题）——一个案例串起四个板块，这就是签名题的价值
• 数据结构：四叉树做视口查询与聚合；动态对象多时说出松散四叉树 / 网格哈希的取舍
• 再备一手：坐标映射精度——经纬度 → 墨卡托投影 → 世界坐标，float 在大坐标下精度崩 → 浮动原点（Floating Origin） / 分块局部坐标
• 多级缩放：瓦片金字塔 + LOD 切换，缩放阈值处的标记聚合/展开动画如何做到无感知

加分点Unity 6 的 GPU Resident Drawer 对大量同屏物件收益巨大——接进签名题，顺带展示你跟进引擎进展。

市场信号来源：牛客 · 2026 游戏客户端秋招总结 · 知乎 · 大厂都在用什么（游戏开发篇） · 猎聘 · Unity 客户端专家岗位列表 · 知乎 · Unity 转 3D 微信小游戏上线踩坑记录

• 帧同步：只传输入指令，各端做确定性模拟——带宽极小、回放天然（存指令流即回放）；难点：确定性（浮点差异 → 定点数学、随机种子统一、遍历顺序固定）、断线追帧（加速重演）、反外挂难（需服务器校验和）
• 状态同步：服务器权威模拟、下发状态——安全、断线恢复容易；难点：带宽与插值、延迟对抗（客户端预测 + 服务器和解回滚 + 延迟补偿）
• 选型：MOBA / RTS / 格斗（确定性 + 回放）→ 帧同步；MMO / 射击（安全 + 大世界）→ 状态同步

加分点命令模式在帧同步里 = 网络包本体——和架构板块的命令模式打通，一条线讲两题。

• ECS：数据按 Archetype 分 chunk 连续存储（SoA），批量处理时 CPU cache 命中率高、天然可并行——「为什么快」的答案是内存布局，不是玄学
• Job System：带安全检查（依赖图、竞态检测）的多线程任务调度，C# 里放心用工作线程；Burst：把 job 编译成 SIMD 优化原生码，数值计算常见数量级提速
• 务实定位（2026 共识）：混合架构——主体 OOP，热点系统（大规模单位、寻路、弹幕、标记聚合计算）用 Jobs + Burst，不必全盘 ECS

加分点接签名题：「万级标记的聚合计算就是我项目里最值得 Job 化的一段」——判断力比经历更稀缺。

包体（先审计再动手）

• 先跑构建报告（Build Report）做资源审计——大头永远先查纹理规格与 Shader 变体
• 手段：纹理压缩档复查、音频码率、无用资源剔除（静态分析工具）、首包最小化 + 边玩边下（首包只留新手 30 分钟内容）、IL2CPP 代码裁剪档位、AAB / App Thinning 按设备分发

启动（先度量再优化）

• 分阶段埋点：引擎初始化 → 首帧 → 热更检查 → 资源预载 → 大厅可交互，每段有数字才知道优化谁
• 手段：延迟初始化（非首屏系统后置）、热更检查与资源预载并行、Shader 预热挪到加载幕后、首场景瘦身

加分点用数字讲故事：「包体 X→Y MB、启动 X→Y 秒」——这题就是为量化叙事准备的。

• 运行环境是 WebAssembly：三大差异——① 内存红线远低于原生（低端机实际可用几百 MB）、② 首包/分包限制严格、③ 无 JIT
• 应对：资源全量远程 CDN 化、首包极小化、纹理音频降档、杜绝同步加载、贴图内存精打细算
• 有趣的反转：小游戏代码随版本直接发布，传统热更方案反而被简化——说出这点很显理解深度
• 团结引擎：Unity 中国分支，官方支持微信/抖音小游戏与鸿蒙——选型题的新变量

没做过怎么答「我没上线过小游戏，但调研过移植评估：我们项目要改的三件事是内存预算、首包拆分、放弃 HybridCLR 改随版发布」——评估结论照样是资深答案。

好答案的公式：具体工具 + 具体场景 + 边界意识（忌空谈"提效"）。参考回答：

"日常用 Cursor / Claude Code 这类 Agent 工具写 Editor 扩展、构建脚本、单测和 shader 原型——工具性代码 AI 产出快且风险低；核心玩法和性能敏感路径的代码，AI 只做 review 辅助，合入前必须过人工审查和真机验证。美术侧用 AIGC 出概念图和贴图初稿。排查线上问题时用 AI 归因 crash 堆栈，效率提升很明显。"

资深版还要多一层——把 AI 织进团队工作流：

• 制定团队的 AI 使用规范（哪些代码可以 AI 生成、review 标准、安全红线）
• AIGC 资产管线化：概念图 → 贴图初稿 → TA 精修的流水线，而不是各画各的
• AI 参与自动化测试：跑机器人压测、日志归因、崩溃聚类

可自然带出的行业进展（择一两个，别背诵）：

• Unity 6：URP Render Graph、GPU Resident Drawer
• HybridCLR 已是国内热更事实标准，配套生态（混淆、构建工具链）成熟
• 端侧推理（Unity Sentis）：AI NPC、手势识别跑在设备上
• 小游戏平台：微信小游戏、团结引擎是国内 Unity 岗位的重要增量

• 「JD 里空间可视化 + 音视频流媒体的组合很有意思，产品是大世界地图类游戏还是可视化互动产品？」——解开产品形态之谜，也显得你读得细
• 客户端团队规模与这个岗位的定位（带人还是攻坚）
• 目前的热更方案和性能基线目标机型——用问题展示专业习惯