过早优化是万恶之源”——Donald Knuth
不少开发者在前期开发过程中对算法等类似的开销都甚少关心，而是更倾向于尽可能简单的解决某个问题，后面必要时再进行优化。这能极大加速开发进度，并保证代码简洁。但开发后期通常会出现的瓶颈就是图形资源，而优化图形渲染这一块比较有难度。
本文将分享作者Lamebait在使用Unity5制作沙盘游戏过程中优化SkinnedMeshRenderers的相关步骤提供给大家参考。
第一次迭代——使用不带动画的网格
每个城市街区约有15个网格，首先最显著的问题就是不断被加载到游戏中Mesh数量。当街区数量增长到数百之后，DrawCall数量也飙升到大多硬件所不能承受之高。Unity支持网格批处理，能减少一部分DrawCall。但所有网格都是有动画的，所以这些网格用的是SkinnedMeshRenderer组件而非MeshRenderer，Unity不支持对SkinnedMeshRenderer进行批处理。
第二次迭代——SkinnedMeshRenderer.BakeMesh()
所有的建筑和树木都只在它们出现和消失的时候有渐入和渐出的动画，一旦稳定下来之后就是完全静止的了，那可否在此期间将它们变为MeshRenderer呢？
如果使用带有MeshRenderer的无动画网格，通过开关选择使用MeshRenderer还是SkinnedMeshRenderer，结果可能会发现有几个网格与其SkinnedMeshRenderer的最终状态不太匹配，所以这条路不通。
下图展示了SkinnedMeshRenderer的最终状态与静态网格本身的差别。
SkinnedMeshRenderer中有个BakeMesh()函数，功能是按照网格当前的动画状态创建网格数据快照，并输出这个网格数据用于其它地方。这样就可以将输出的新网格传给MeshRenderer然后享受自动批处理的功能。但事情并非如此简单。
下面创建包含各种网格类型的字典，以便多个MeshRenderer可以共享同一个网格，然后让Unity进行批处理。不论何时增加了新的网格，它都会被烘焙出来并加到字典中。但这样会爱导致进行网格类型切换后网格的高度略微有点拉伸。这是因为建筑的缩放值不是0，以致SkinnedMeshRenderer输出的网格本身被缩放了一次，而这个网格在应用到GameObject上的时候由于GameObject本身的缩放值又被缩放了一次。解决这种矛盾的办法就是先将建筑的缩放值设为1，烘焙后再设回原始值。
到此整个切换看起来完全无缝。但这是有代价的，因为Unity也不支持对使用了阴影的MeshRenderer进行批处理。而关闭阴影又会对游戏效果大打折扣，所以必须想想其它办法。
第三次迭代——网格合并
还可以手动批处理，因为网格是可以合并成一张大网格的。当然也有些限制，如网格材质必须相同，单个网格的三角形数量有限等。还好这个游戏的建筑和树木总共才用到了三种不同的材质，所以可以将整个街区合并成最多三张大网格。
基本上，创建CombineInstance后将BakeMesh()输出的网格传给它并加上Transform。最重要的是确保Transform的变换矩阵中GameObject本身的缩放值都是无效的，否则网格会像上文提到那样错误变形。合并后网格的最终结果会应用到网格之前所在的GameObject，然后在街区状态变为静止后移除。
整个过程比较棘手。游戏中很多因素都会导致奇怪的效果，对于每个因素及每个可能的组合都要单独测试。但结果证明这是值得的，现在游戏在有阴影的情况下帧率也非常可观！
合并的红色网格如下图：
第四次迭代——更高一级
这游戏设计的特色之一就是每个阵营最终的街区都会在生成之后被保留，所以如果街区从未改变过，可以将它们合并到一起。一个个合并会遭遇前面提过的网格大小限制。而将城市分为几个格子可以将几个街区的网格合并为单个，从而进一步降低DrawCall。效果如下图：
总结
本文最重要的三点：
- 不要过早优化，可以适当晚一点。
- 善于发现漏洞！如果某个东西不适用于X，那能否暂时将它变为Y呢？
- 用创造性的技巧换取性能。