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会发生堆内存的分配，然则在真机上并不会发生堆内存的开销。
如何更好的通过SEM数据分析做SEO优化？
