Unity 客户端开发一面凉经

《面试题目》

1. 你在实习时负责的部分，哪个是你投入最多的？讲一下需求是什么、原有代码是什么、哪些是你改的、你改了什么。
2. 框架上是不是没有需要你们做的改动？
3. 具体实现是不是你们自己写需求、比较创新的方式？
4. 你实现的 buff 机制是原有的还是你们自己设计的？buff 涉及时效性、次数、层数这种复杂数据结构，想听你对它的理解。
5. 如果让你自己设计 buff 机制：比如强化子弹 10 发用完就没了、10 秒倒计时的 buff 到期就消失，数据要附加在武器或角色属性上，你会怎么设计？
6. buff 不一定是时间，还有次数，会修改原来的数据，有加算、乘算的区别。你来设计的话，会想象它是一个什么样的结构？
7. 武器有攻击力，有多个跟攻击力相关的 buff，其中一个结束的时候，你怎么确保数据依然实时正确？是倒计时通知，还是获取时通知？
8. 数据发生改变，你觉得实时更新更好，还是下一次获取的时候再更新更好？
9. 新手引导涉及中断、奖励只发一次、从哪儿继续播这些问题，讲一下你的整个设计思路，或者怎么处理这些问题。
10. 你自己写的项目用了 MVC 架构提高扩展性，具体是怎么设计的？
11. 举个具体例子（比如强化升级），讲一下怎么设计的。
12. TCP 和 OSI 的 4 层 / 7 层协议，大概讲一下。
13. 你自己写的项目里，有没有后期觉得之前哪里写得不好、改过的？
14. 指你已经完成的部分，有没有回头 review 想改的？实习的项目也行，别人提的意见也行，你怎么思考、怎么去改的。
15. 让你设计一个换期通行证，策划需求是后面会出很多期、每期基础结构一致要考虑复用性：你怎么决定代码设计？考虑哪些点？怎么跟服务器对接、接口保留什么？美术资源怎么放、怎么划分？
16. 更关注资源和代码结构复用，框架由你来定，后面的人接手按你的规范做就行——多讲一下代码设计和资源划分。
17. 代码上的、资源上的呢？
18. 哪些资源是通用的、哪些换期要换、是不是一次性加载好、同一个界面还是不同界面？
19. 红点系统也讲一下，这也是个很常见的系统。
20. 你对用这个 skill 的看法？做了什么？上线项目肯定不能没人检查就上，对它有什么限制、规范、流程，讲一下你自己的想法？

《参考解析》

项目讲述要先立骨架再填细节：这场面试有一半时间在追问「哪些是你改的、为什么这么改」，说明面试官在看你的真实参与度。准备一个项目的正确顺序是：一句话业务背景，一句话你负责的模块，然后按「原有实现是什么—问题在哪—我做了什么改动—为什么这么改—结果与验证」讲。回答第 2、3 问时不要条件反射地谦虚说「框架都有了、我们没做什么」，也不要夸大；如实区分「框架提供的部分」和「自己写的部分」，再补上你对框架设计的理解，比如「这套框架把 X 抽象掉了，所以我们只需要实现 Y」，这句评价恰恰是面试官想听的。至于第 13、14 问的「有没有回头想改的地方」，一定要提前准备一个真实案例：当时怎么写的、后来发现什么问题、影响面是什么、最终怎么改的。

Buff 机制怎么设计：把 buff 拆成三层来想。数据结构层：一个 buff 实例至少要有 id、来源、剩余时间、剩余次数、层数、叠加规则（独立并存 / 叠层 / 刷新时长），挂载在角色或武器的属性容器上。数值结算层：buff 对属性的修改分加算与乘算，要区分固定值与百分比，并明确乘算的叠乘顺序，否则多 buff 同时生效时结果不可复现；常见做法是「基础值 + 各加算之和，再乘各乘算系数」，层数作为系数的一部分参与计算。失效处理层：推荐「脏标记 + 延迟计算」——属性变化时把缓存标记为脏，下一次读取属性时按当前全部 buff 重算；倒计时或次数耗尽的 buff 只负责摘掉实例并置脏，不去逐个回改数值。这样任何一个 buff 结束，最终值都自动正确，也不依赖「谁先结束」的顺序。

实时更新还是下次获取时更新：这不是对错题，而是「什么时候必须精确」的问题。延迟计算（脏标记）省性能、天然避免重算顺序错误，缺点是读取那一刻必须保证缓存已失效；实时更新（属性变化立刻广播事件）能让飘字、UI 数值、战力显示即时响应，代价是高频 buff（持续伤害、攻速加成）会把重算次数放大。工程上通常混合：战斗数值走脏标记、按帧或按次结算，表现层走事件驱动，数值变化后发一次通知让 UI 刷新。被追问「倒计时通知还是获取时通知」时的正解是：先讲清两种模式的代价，再说明自己选哪种以及边界情况——比如 buff 到期的那一帧必须先结算再摘除，否则会多打一下或少打一下；又比如同一帧内有多个 buff 变化时，合并成一次重算而不是结算多次。

新手引导与红点系统的共性：这两个系统考的都是「状态机 + 一次性发奖 + 断点续播」。新手引导把每一步做成可序列化状态（步骤 id、是否完成、触发条件、引导目标），存档里只落「已完成到哪一步」而不是整个流程对象；奖励只发一次必须在结算入口做幂等，服务端也存一份已领取记录，客户端用本地标记挡住重复点击；玩家下线、跳场景、断线后按存档重放未完成步骤即可恢复。红点系统的标准做法是数据驱动的树形结构：叶子节点是一条可判定的规则（有新邮件、可升级、有奖未领），父节点是子节点的逻辑或，任一叶子变化时自下而上递归刷新；关键是别每帧遍历全树，而是由事件触发对应节点重算，并把「已读」状态和「可领取」状态分开存，避免玩家点进界面红点却消不掉。

换期通行证与资源复用怎么答：面试官想听的是分层与复用意识。先拆「不变的」和「每期变的」：不变的是一套通用框架——通行证本体（等级、经验、奖励轨道、进度结算）、通用控制器与数据表结构；每期变的是配置（奖励内容、期数、时间、主题文案）与美术资源（立绘、背景、图标）。设计上把内容全部外置成配置表，代码只认字段不认具体道具；界面做一套通用面板，按配置动态生成奖励格子，切期时只换配置与资源引用。资源划分按「通用（按钮、通用特效、底图）／主题专属（每期立绘、背景、图标）」分开目录，专属资源按期按需加载，避免把所有期的资源打进包体。与服务器对接要提前约定几类接口：拉取当前期配置与进度、领取某一档奖励（必须带期号与档次做幂等）、上报经验，并预留期号与版本号字段，方便加期不改协议。

架构与网络基础怎么讲：MVC 这类问题不要只背定义，要落到项目里的真实分层：Model 只管数据与业务规则（角色属性、背包、战斗结算），View 只负责渲染、不持有逻辑，Controller 接收输入与流程调度并把结果回写 Model。扩展性体现在「加一个新功能要改几个文件」——理想情况只加一个 Model 和一个 View；再补一句你对 MVC 局限的认识（UI 状态多时 Controller 容易变胖，所以后来常见 MVP/MVVM 把绑定前移）。网络部分要讲清分层关系：OSI 七层是理论模型（物理、数据链路、网络、传输、会话、表示、应用），TCP/IP 四层是工程实现（链路、网络、传输、应用），HTTP 属于应用层跑在 TCP 之上，UDP 不保证可靠但延迟低，适合实时同步。最后回到这场面试的复盘：全程被引导说明基础面够、深度不够，把 buff、红点、通行证这三个系统各写一份设计文档，下次面试就能反过来主导节奏。