写了两三年 App第一次打开 Unity 的时候说实话我有点懵同样是写代码怎么一切都不太对劲对象不用 new事件不用自己注册UI 不是 View 而是组件挂在节点上连坐标原点都在屏幕左下角。更要命的是以前写的那些“界面刷新逻辑”在这里好像完全没用了——游戏不允许你只在数据变化时才更新它每帧都在跑。后来我意识到从 App 开发切到 Unity 游戏开发真正需要的不是重新学一遍语法而是建立一张“认知地图”把你已经知道的 Android、iOS 或小程序开发经验映射到 Unity 的世界里找出哪些是同构的、哪些是彻底不同的、哪些需要保留但换一套表达方式。这个映射过程做完加上现在 AI 辅助工具已经能分担大量代码编写和排查工作转型效率会高很多。这篇东西就是我个人这段时间实践下来的完整记录写给同样想做这个切换的客户端开发者参考。1. 认知地图App 开发者的经验坐标如何映射到 Unity 的版图1.1 一张表看清“同构点”和“不同构点”先别急着去背 API。我建议把 App 开发里的核心模块一个个列出来再看 Unity 里对应的东西是什么。下面这张表是我自己整理后一直在用的基本框架没有变过你在 App 开发里熟悉的东西Unity 里的对应物是否直接迁移Application 生命周期回调MonoBehaviour 的 Awake/Start/OnEnable否触发时机完全不同页面跳转 / 导航栈场景切换、UI 面板控制否没有系统返回栈数据变化后手动刷新 UI每帧 Update 事件驱动否主循环模式是根本差异依赖注入容器场景引用、Prefab 绑定、ScriptableObject部分迁移思路保留网络层 / 数据层分离同样适用C# 里照样分层是完全保留异步网络请求async/await 或协程是不过要遵守 Unity 的线程规则图片加载 / 缓存Resources / Addressables / Sprite否资产管线需要重新学MVVM / MVC 架构可以继续用但绑定方式不同部分迁移本地存储PlayerPrefs / ScriptableObject简单场景可用复杂数据选其他方案打包和发版Build Settings 各种平台模块部分迁移坑更多这张表的意义不是让你背下来而是让你在遇到具体问题的时候有一个“定位坐标系”这个东西我在 App 里是怎么做的Unity 里对应的东西叫什么两个方案的底层逻辑是否一致大部分情况下你会发现思路层面是通的只是表达方式变了。1.2 最根本的转变主循环模型 vs 事件驱动模型在我所有踩过的坑里最深的一个就是“刷新模型”的差异。App 开发里UI 通常是事件驱动的用户点击了按钮回调触发网络数据回来ViewModel 更新属性页面局部刷新。没有事件就没有刷新帧率是省出来的。但游戏不是这样。游戏是主循环驱动的每一帧都要重新计算、重新渲染哪怕什么事情都没发生Update 里面的逻辑照样要跑。我一开始写游戏逻辑时习惯性地把状态变化放在事件回调里只在“需要更新”的时候更新界面结果角色动起来一顿一顿的。后来才意识到游戏里的“界面”不是静态面板而是每帧重绘的画布你的逻辑必须配合这个节奏。这不是技术差异是思维方式的差异。App 开发者的很多优化直觉——减少刷新、按需加载、延迟绑定——在游戏里依然有价值但必须建立在“每帧都在执行”这个前提之上。你要优化的不是“少跑一点”而是“每次跑得足够快”。1.3 能带过来的工程习惯分层架构依然有效好消息是App 开发里磨练出来的工程能力大部分还是有效的。我最初担心 Unity 是个“什么都往场景里拖”的世界、代码架构会很随意实际做完几个 Demo 之后发现只要你严格把代码分成三个层次——数据层负责存取和网络、逻辑层负责玩法规则、表现层负责场景和 UI——整个工程依然是清晰可维护的。唯一的区别是App 里你用接口和依赖注入把各层串起来Unity 里你更多的是通过组件引用来做同样的解耦。比如说数据层需要一个网络服务的实例App 里你会从容器里拿Unity 里你可以在场景里放一个挂某个网络组件脚本的空节点其他人通过 GetComponent 或者 inspector 拖引用去拿。不要觉得用 GetComponent 就低人一等也不要一上来就嫌弃这种模式。它只是表达方式不同背后的依赖倒置原则是一样的。2. 坐标系革命从像素坐标思维到三维变换思维2.1 App 里的坐标 vs Unity 的坐标这个问题我做了差不多一周才彻底转变过来。App 开发里你可能天天和像素、dp、pt、锚点、安全区打交道坐标系的原点大多在左上角x 向右y 向下。这个坐标系在 Unity 里完全不成立。Unity 的坐标原点是世界空间的某个点默认在场景正中央x 向右、y 向上、z 向屏幕外。所有物体都在三维空间里有自己的坐标它们之间的位置关系通过 Transform 组件维护。即便你做的是 2D 游戏底层依然是三维坐标系只不过把 z 轴冻结在一定位置而已。更重要的是单位制。App 里 1 个像素或 1 个 dp 是没有物理意义的Unity 里 1 个单位默认等于 1 米物理系统就是按这个单位计算的。我见过有同学做 2D 物理游戏时想当然地写transform.position new Vector3(100, 200, 0)结果两个物体的距离是几百“米”重力加速度、碰撞检测全乱了套。建议新手无论如何先按 1 单位 1 米的物理直觉来设计尺寸再做视觉上的缩放适配。2.2 相机不是装饰品App 开发里没有“相机”这个概念你看到的页面就是屏幕上直接渲染出来的。Unity 里所有画面都通过相机才能显示。这个差别刚开始特别容易忽略因为你新建场景的时候 Unity 已经给你放好了一个相机你不修改它也能看到默认画面。但一旦你的游戏需要跟随角色移动、放大缩小、分屏或者做 UI 叠加你必须理解相机的原理。相机的核心是两种投影方式正交投影和透视投影。2D 游戏一般用正交3D 用透视。正交投影下物体的视觉大小不因距离而变化透视投影下近大远小。UI 层级的显示也要通过 Canvas 的渲染模式来指定Screen Space - Overlay 模式下 UI 永远在最上层并且不需要相机参与Screen Space - Camera 和 World Space 模式则依赖相机来决定 UI 的呈现位置和大小。我的建议是第一天就把相机的属性面板打开把 Clipping Planes、FOV、正交尺寸这几个参数全都亲手拖一遍观察观察场景里物体视觉变化。这个环节搞懂了后面 70% 的“看不见、显示错、位置不对”问题都能自己定位。2.3 一个典型 bug把屏幕坐标当世界坐标用分享一个我真实排过的过程吧。有一次做一个塔防 Demo需要在屏幕的某个像素位置摆放一个 UI 提示我按照 App 的习惯计算出像素坐标后直接赋值给物体的 Transform 位置结果提示图标飞到了场景之外。排查了半天才发现问题所在UI 元素的坐标和世界物体的坐标是两套系统。UI 用的 RectTransform 有 anchor、pivot 这些概念坐标参考的是 Canvas 坐标系而场景物体的 position 是相对于世界原点。这两者要转换通常需要 Camera.ScreenToWorldPoint 或 RectTransformUtility.ScreenPointToWorldPointInRectangle 这类 API。这个 bug 给我的启发是在 Unity 里不要默认某个坐标值可以到处用写代码前先弄清楚这个坐标是屏幕像素、Canvas 坐标、局部坐标还是世界坐标。坐标系的错位是新手最容易踩、又最难自查的坑。2.4 需要补的数学够用就行不用重学线代听到“三维向量”“矩阵变换”就害怕的同学可以放心日常做游戏用到的数学没有你想的那么难。我转型期间只复习了几个基础概念就基本够用了向量表示方向和位置点乘算夹角和投影叉乘判断左右和法线插值 Lerp 做平滑移动。举个例子你想让角色朝某个目标点移动不需要自己去算三角函数直接用Vector3.MoveTowards或者Vector3.Lerp内部帮你处理了。判断一个敌人是在玩家的左边还是右边用一次叉积的正负就能得到不用写条件枚举。把这些高频数学操作整理成一个“常用数学速查表”遇到不懂的翻译成大白话即可Dot 就是两个向量有多“同向”Cross 就是它们在三维空间构成了什么样的平面关系。0基础的线代不需要但建议知道这些函数存在。3. 场景、生命周期和主循环Unity 如何接管你的游戏逻辑3.1 MonoBehaviour 回调 vs 系统级生命周期App 开发里你会在整体应用级别监听 onBackground、进入前台、退出等事件在页面级别处理页面显示、隐藏。Unity 里也有对应的机制但粒度完全不同通过挂在 GameObject 上的组件脚本在组件被激活或对象被创建、销毁时自动触发一系列回调。一个最常见的误解是混淆Awake和Start。Awake 在对象生成时立刻调用无论脚本是否启用Start 在对象被启用且第一次进入主循环前调用。如果你在 Awake 里访问其他可能还没初始化的组件很容易拿到空引用。我的习惯是Awake 里只做自初始化比如获取自身组件引用、初始化私有变量跨对象依赖放到 Start 里做。这样能避免一大批早期空引用问题。再一个容易忽略的是OnEnable和OnDisable。对象反复启用禁用时它们会被反复调用而 Awake/Start 只调用一次。如果你的对象有频繁“启用/隐藏”的需求要把重新初始化的逻辑放在 OnEnable 而不是 Start 里否则会出现在第一次禁用后重新启用时状态没有恢复的诡异问题。3.2 FixedUpdate、Update、LateUpdate三个阶段各干各的这是 Unity 主循环里最容易让 App 开发者懵圈的三兄弟。简单说FixedUpdate 以固定的物理步长调用适合写物理相关的操作比如移动刚体、施加力Update 每帧调用一次适合处理输入、普通游戏逻辑、UI 状态LateUpdate 在 Update 之后执行适合做相机跟随等需要基于最终状态的逻辑。为什么要分三个因为物理引擎需要确定的步长做碰撞检测和刚体模拟如果像 Update 那样帧率忽高忽低物理结果就会变得不稳定。相机跟随放在 LateUpdate 里是为了确保所有角色都完成移动后相机再根据最终位置去做插值画面才不会抖动。我转型初期最常犯的错是在 Update 里直接修改刚体的 velocity 或者用 transform.position 强行挪动刚体导致物理表现很怪。后来强制自己遵守一个规则走物理引擎的都用 FixedUpdate读物理状态但只做视觉表现的都在 LateUpdate 读取。3.3 场景、Prefab 和引用关系类似依赖注入但要换思路App 开发里我们习惯用容器管理依赖Unity 则是通过场景和 Prefab 的引用关系来组织对象的生态。你可以把场景看作一个预设好的“运行地图”里面摆好了各种游戏对象对象之间通过 inspector 拖拽建立引用。这种方式比代码里手动 new 显然直观得多但也会带来维护上的隐患。最头痛的问题就是“场景大爆炸”所有对象都直接摆在场景里依赖关系遍布团队成员合并版本时处处冲突。我的转型体会是能做成 Prefab 的尽量做成 PrefabPrefab 本身作为可复用模板通过嵌套 Prefab 组织复杂结构场景里只放入口对象和全局管理器。这样即使有人改了某个 Prefab场景层面的冲突面会小很多。如果追求更高程度的解耦可以引入 ScriptableObject 做纯数据配置把玩法参数、角色属性、关卡配置全部独立成资产。这样调整数值不用改代码策划和运营同学也能直接编辑配置这一点其实比 App 开发的本地配置文件更顺手。3.4 一帧只有 16.67 毫秒为什么 Update 里不能写耗时逻辑移动端 60 帧是基本目标一帧只有约 16.67ms 的渲染和逻辑预算。如果 Update 里出现超过这个量的计算帧率就会下来。这个约束App 开发者在主线程里也会遇到但是平时触达的频率没有游戏里这么高。举几个我在代码里常见的问题每帧去FindGameObjectWithTag、每帧去GetComponent、每帧创建临时 List 或者大量字符串拼接、每帧加载资源。这些在 App 开发里可能只是性能不佳在游戏里直接就是掉帧。正确做法是能缓存引用就缓存引用能避免分配就避免分配能提前加载的资源绝不在 Update 里同步加载。这里有个非常实用的检查习惯用 Profiler 跑一次真机 Profile排在最前面的热点函数如果在 Update 里那它就是需要优化处理的对象。不要凭感觉优化要让数据说话。4. 让 AI 干活从提示词到可玩 Demo 的完整实践链路4.1 我的 AI 协作流程和提示词模板标题里说“结合 AI 开始实践”这部分可能也是大家最感兴趣的。我先说明我不建议把 AI 当成权威代码生成器问一句“给我一个游戏”就照单全收。更好的定位是把它当成一个“经验很丰富但经常走神的结对编程伙伴”给它明确约束它给你高质量初稿你再检查关键节点。下面给出我实际用的一段提示词模板基本能满足大多数小游戏脚本生成需求你是一名资深 Unity 开发者。我要实现一个小游戏玩家控制底部挡板接住从顶部掉落的圆球。每接住一个球加一分漏掉一个球减一条命三条命用完游戏结束。 技术约束 - 角色通过水平方向键或鼠标控制挡板移动 - 掉落物使用 Rigidbody 2D 和碰撞检测 - UI 用 uGUI显示分数和生命值放在 Screen Space - Overlay 的 Canvas 下 - 不要让物体穿过挡板碰撞后销毁球并增加分数 - 代码写在 MonoBehaviour 组件里禁止使用第三方插件 - 不要使用 Find 或 FindObjectOfType 获取引用通过 inspector 拖拽或私有字段序列化 - 请提供完整可运行的 C# 脚本这个模板的要点在于我明确规定了技术栈Rigidbody 2D、uGUI、禁止事项Find、插件、代码风格序列化字段、交付物完整脚本。AI 拿到这种输入后生成结果比那种一句话提问要可靠得多。4.2 生成之后必看的 6 个检查点AI 生成代码的速度确实快但我从实践中总结了一个约定无论 AI 写得多好以下六个检查点必须过一遍。第一是否在生命周期正确的位置执行逻辑。比如初始化放在了 Update 里或者把每帧执行的操作放在了 Start 里。第二是否频繁调用 GetComponent、Find 这类运行时查找。AI 最容易在 Update 里默认调用。第三引用和空判断是否安全。AI 生成的代码经常假设目标对象一定存在但你在场景里稍微调整结构就会出空引用。第四物理相关操作是否走物理系统。第五UI 坐标和世界坐标是否混淆。第六通信方式是否合理比如大量使用 SendMessage 或者全局静态变量来传数据。我一般会让 AI 先自查一遍并把它的自查结果放到一个 check 列表里然后我自己再做代码走查。双重检查后踩坑率能降低一大半。4.3 我真实踩过的坑AI 写了一版“只在变化时刷新”的代码分享一个真实教训。有一次我让 AI 写一个“角色血量变化时更新血条”的功能AI 生成的代码按照“当 HP 数值变化时再修改 UI 文本”的思路实现——在 Update 里比较当前值和上次值发现不同才更新。这个逻辑放在 App 里没问题甚至是很优秀的写法但在游戏里有一个隐藏问题血条如果是用于平滑动画它需要在每帧推进动画如果只在数值变化瞬间更新动画会生硬跳变。这是典型的 AI “综合了 App 开发经验”产生的输出它不理解游戏视觉呈现里的连续变化需求。我后来在给 AI 的需求约束里加了“所有视觉表现应当考虑帧率连续性不要在单一事件里直接跳变”这样的提示同时自己检查时也多了根弦拿到代码后会先判断这段逻辑的运行模式是事件驱动还是帧驱动两者是否匹配游戏的需求。4.4 提示词工程经验给 AI 输入约束而不是让它自由发挥提示词工程对于 Unity AI 协作尤其重要。我总结了几个原则第一明确告诉 AI 目标平台比如“移动端 Android”它生成的代码会更注意内存占用。第二明确 API 版本Unity 的 API 在不同版本间有差异AI 偶尔会输出已经不推荐使用的方法让它根据某个具体版本来做会更安全。第三让它给出简化实现的思路而不是过度设计。AI 有时候会把简单功能写得非常复杂内部类一堆不适合初学者抄作业。如果你一开始不知道该怎么约束可以先给 AI 一段你自己写的最小示例让它在此基础上扩展。这种“few-shot”方式效果普遍更好比你直接描述需求更可控。5. 从 Demo 到可发布工程资源和工程问题5.1 图片和资源加载从 URL/图片控件到 Sprite/图集/Addressables做 App 的加载网络图片很成熟一个图片控件加上 URL 就完事了。Unity 的资源载入情况要复杂很多美术资源需要导入到工程里、设置导入格式、生成 Sprite 或图集运行时还要考虑加载和释放的时机。资源加载方式选择上我建议小型项目可以直接用 Resources 文件夹简单省事。项目规模上来后强烈建议迁移到 Addressables它支持异步加载、依赖管理、资源远程更新整体更像 App 开发里的动态加载方案。Resource 文件夹有加载所有资源的限制同时不利于热更和包体瘦身不适合中大型项目。图片素材的处理也是一门学问单张图片直接挂在场景里没问题但大量 UI 图片合到一张图集里能显著降低 Draw Call。资源导入设置里的 Pixels Per Unit 决定了这个 Sprite 在场景里对应的世界单位大小和物理系统的尺寸直接相关这个参数也值得在新手期就搞清楚。5.2 Prefab 和场景的版本管理为什么 git 冲突比 App 难解做过 App 团队协作的朋友都知道代码合并最多就是改几个文件冲突解决在编辑器里很直观。Unity 工程的文本里混着大量“场景内对象”。你每次在场景里拖一个对象、调一个参数就是在改那个可能几千行的 YAML 文件两个人同时动一个场景时冲突几乎难以避免。我的处理经验是这样的第一场景文件尽量按模块拆开别把整张地图放一个场景里。第二公共的对象一定要抽成 Prefab场景里只放 Prefab 实例改 Prefab 比改场景安全得多。第三检查 Path 分隔符。Unity 的序列化配置会根据引擎和编辑器版本产生兼容性上的差异团队内最好约定统一版本否则历史改动很难追溯。如果你从第一天就按这个思路管理资源和场景后续协作会好受非常多。大多数 Unity 新手项目最后变成“一个人改不动”的状态一是因为没有这种拆分意识二是场景内对象引用太混乱、不敢重构。5.3 性能问题请提前看Draw Call、GC 和 ProfilerApp 性能优化的经验放在 Unity 里基本逻辑相通就是具体指标不同。Unity 的性能热点主要在三个方面Draw Call 数量、CPU 逻辑耗时、GC 引发的卡顿。Draw Call 是渲染层面的核心指标每帧 GPU 需要提交的绘制命令次数越多性能越差。这里就要用到图集、合批、静态批处理等技术。GC 问题则和代码有关比如每帧创建临时对象、拼接字符串、装箱操作都会引发垃圾回收回收时会出现瞬时卡顿。我的建议是做一个“性能检查清单”每做完一个功能模块真机跑一遍 Profiler重点看 Update 耗时、GC Alloc 和 Draw Call 三个指标。不要等到最后才统一优化那会无从下手。5.4 打包与真机调试IL2CPP、Gradle 版本这些问题App 开发者以为“我会打 Android 包就万事大吉”结果在 Unity 里遇到了新的一堆奇怪问题。Unity 默认的 Android 构建方式有两种Mono 和 IL2CPP。IL2CPP 是把 C# 代码转成 C 再编译包体更大、启动性能更稳上架基本都选它。但 IL2CPP 的编译时间很长调试时先用 Mono 模式能节省大量时间正式发布前再切 IL2CPP。构建过程中最常见的问题就是 Gradle 版本和依赖冲突。Unity 内置了一个 Gradle但你如果接入了第三方 SDK它们可能要求特定版本的构建工具这时候需要在 Project Settings 里配置自定义 Gradle。这个流程和 App 开发里折腾 Gradle 的经验完全一致只是入口不同。我的建议第一正式版本用 IL2CPP ARM64分包时关注包体积。第二遇到构建失败先看完整日志不要只盯着最上面报错红字。第三真机调试时 Unity 的日志系统和 App 的日志是联动的要会看 Android Logcat 和 Profiler 的 Remote 模式。6. 哪些 App 习惯可以直接保留哪些必须硬改我的经验清单6.1 直接保留的习惯数据协议、分层架构、日志监控、平台适配转型并不意味着一刀切丢弃过去的经验。我在实践里发现以下这些习惯在 Unity 里不仅有用而且用得好会让你比很多“只做游戏”的开发者更有工程优势。数据协议和网络层设计直接沿用了过来。游戏客户端也需要和服务端交互登录、拉取配置、上报数据、实时状态同步这些协议设计思路和 App 完全一致。UI 分层方面你在 App 里沉淀的 MVVM 思想到了 Unity 里可以换一套实现但思路保留数据驱动 UI 永远是对的。日志和监控体系也一样重要。App 里你会埋点、上报 crashUnity 里同样需要一套日志体系至少把 Debug.Log 统一封装一下方便线上开关和分级输出。平台适配层面Unity 天然跨平台但依然会有差异你过去处理 iOS/Android 平台差异的经验在这里换成处理 PC/移动端/WebGL 的差异方法论是相通的。6.2 必须硬改的习惯每帧执行、手动管理生命周期、字符串拼接、对象池有保留的就一定有必须改掉的否则会拖垮你的工程。第一个必须改的就是“只在变化时刷新”的思维前面已经反复强调了这里再给一个非常朴素的判断标准如果一段逻辑里的结果会影响画面表现默认它在每一帧都需要被执行或判断。第二个是生命周期管理。App 里框架帮你管理 view 的创建和销毁Unity 里对象是否销毁、何时销毁是要自己在代码里决定的。大量从 App 转过来的开发者习惯了不刻意做内存管理到了 Unity 里会让内存无限增长。要养成主动控制生成和销毁的习惯能复用的对象放对象池里不用频繁创建销毁。第三是字符串拼接这类小问题。在 App 里偶尔拼一下字符串没什么在游戏每帧几百次拼接就会产生大量 GC。习惯性地用 StringBuilder或者干脆把显示文本预先生成好都是好做法。6.3 个人体会至少两个月的“双坐标系”并存阶段坦率地说从 App 开发转到 Unity不是看几篇教程就能完成的切换。我个人的体会是转型期会经历一个“双坐标系并存”的阶段你的一部分直觉还停留在 App 世界里遇到问题第一反应是找 Activity、找 ViewController另一部分已经在学着用主循环、Transform 和组件去思考。这种分裂感刚开始会很难受代码也会时而像 App 架构时而像游戏脚本的混合体。这个阶段基本会持续一到两个月。突破的关键在于多做小游戏而不是啃大项目把每一块新知识点用到一个 10 分钟就能跑起来的 Demo 里多和 AI 配合出一些完整功能再亲手拆掉重构一遍。等哪一天你接到新需求时第一反应自然变成了“这个玩法该拆成哪些组件、哪些脚本挂在哪些对象上”并且不再觉得这才是“正确答案”——那时候就算真正转过来了。最后分享一个养成习惯。我每次遇到一个新概念会先问自己三个问题它主要解决什么问题如果不用会怎样怎么用最简单的方式验证它是对的对于 App 转 Unity 也适用每次多了解了相机、物理、主循环中的一项都亲手做一个小验证花不了多少时间但认知地图会越来越清晰。