unity一键替换场景中的物体
去当unity游戏开发实习生应该具备哪些能力和知识？
去当unity游戏开发实习生应该具备哪些能力和知识？
0x01.项目前期规划时的问题
这里指的不是策划的需求或者游戏玩法的计划，而是作为一个Unity项目我们需要在一开始明确并制定好的规范和标准。作为一个Unity项目或软件项目，这部分是很重要的，因为项目早期的规划随着项目的开发时间越久，就越难以修改。
对支持的最低机型不明确
作为一个Unity项目，我们首先要明确我们所需要支持的最低设备标准。并且项目组要有这样的设备，以供开发和QA团队使用。
否则，对项目的优化将无从谈起。
资源标准不明确
开发过Unity项目的同学可能都有过类似的经历，即开发过程中的资源标准不明确。这常常也是早期在项目规划时没有重视资源标准导致的。
所以在项目的早期阶段，最好能够明确资源标准比如模型的vertex数量、纹理资源的尺寸格式等等。
也要对每帧开销中，脚本和渲染所花费的时间有一个目标和预期。
没有合理的Asset流水线
这里指的是资源应该按照一定的流程和标准从美术那里导入到Unity项目中。
很多项目最终出现性能问题，都是由于没有一个合理的Asset流水线。从而导致项目内的资源标准无法管理，很多冗余或不符合目标设备水平的资源构建进了最终的安装包里。
所以，作为项目组，大家一定要指定一套自动化的Asset流水线。为Asset的规格和标准制定明确的规范，在自动化脚本中进行设置。
例如texture是否开启read/write?texture的压缩格式？尺寸？非人形的model在导入时是否关闭了rigs？动画模型是否开启了Optimize Game Object选项？等等。
没有合理的构建和QA流程
也有很多项目的构建并非一番风顺，构建的版本也难以管理。策划或者QA常常是找负责某个功能的开发兵荒马乱的打一个包出来。
所以项目组可以思考一下下面的几个问题：
是否有专门的打包机？
一个新的功能是如何发布到最终的发布版本的？
是否有自动化的可持续集成设施（CI）？
QA要如何反馈Bug，Bug如何有效的管理？
正式项目直接在Demo原型上进行开发
这个也是一个常见的情况，有些项目组早期会有少数几个人开发一些玩法演示Demo，Demo被认可之后开始开发正式的项目。
此时会有一个问题，即在Demo的基础上直接开发正式项目。由于很多Demo只是为了演示玩法，所以代码中有很多为了尽快实现需求的特定Hack。
如果正式项目以此为基础，到后期维护会比较麻烦。
除了上面所提到的问题之外，还有一些别的需要重视的内容，例如制定统一的编码规范、确定采用的光照模式（RealTime？Mixed？Baked？） 等等。
0x02.项目开发过程中的问题
经过了项目早期的规划阶段，来到项目的开发阶段时项目组有可能会犯哪些错误呢？一些不好的实践有可能会拖慢项目的开发进度以及让项目组成员的焦躁感上升。
不重视版本管理
很多团队对版本管理不重视，或者团队内部对版本管理例如git的操作不熟练。
当然，关于git的最佳实践的资料有很多，建议项目组在内部进行培训和普及，让大家（程序美术策划etc）对版本管理的操作符合规范。
针对Unity项目，serialization 的格式建议设置为text serialization。
设置commit hook：
静态数据存储在Json或XML文件保存
不少团队喜欢或习惯于使用Json文件或XML文件来保存一些静态数据，在游戏运行的时候加载使用。但是使用Json或XML文件保存数据会有以下的问题：
加载速度慢。Parse的时候会产生内存开销。所以数据最好使用二进制来保存，在Unity内部也提供了ScriptableObject来帮助保存数据。
项目中包含了没有用到的资源、插件或冗余的库
这也是很多团队中常见的一个问题。一些废弃的资源没有及时处理，仍然留在项目中甚至被构建进入了最后的发布版本，从而造成不必要的开销。
另一个问题是冗余或多份同样功能的库，比如项目中使用的插件中有多款插件都使用到了Json解析库，那么就会造成冗余。
只在Editor中测试性能
这是一个很不好的开发习惯。因为在Editor中测试的是Editor的性能开销，而不是在真正的目标平台上的性能开销。所以在做Profile的时候，一定要在目标平台的设备上进行。否则只能得到让人误会的数据，例如在Editor中，GetComponent这个API会产生堆内存的分配，但是在真机上并不会产生堆内存的开销。
unity资源和meta不匹配怎么解决？
需要将两者的属性修改为统一属性，然后才能匹配成功