前言
两周前我开始用 Unity 开发一个叫 SkyBlocks 的 Android 游戏。游戏已经在 Google Play 上架了，假如你有时间可以下载来玩一玩儿。
开发的过程中遇到的最大的问题就是性能问题。我开始慢慢尝试分析到底是什么导致的性能问题以及我该怎么解决它。
Sky Blocks 游戏机制
这个游戏（SkyBlocks）有点像倒过来的俄罗斯方块和太空入侵者的合体。游戏的玩法就是把方块摆成一行，这是这行方块就会移到游戏面板的最上方。但是这行方块不会像俄罗斯方块那样完全消失。你有60秒的时候来摆出行数尽可能多的方块。UFO 会入侵“地面”（游戏面板的下方），还会极力破坏你建好的一切东西。一旦它们穿过你的防御，就开始破坏地球，当地球血量到 0 的时候，游戏就结束了。
听起来简单，做出来难，但是非常有意思，有趣极了！
不要忘记做设计
重要的事情是永远不要忘记先做设计。当我开始开发 SkyBlocks 是我也不知道我想要做什么，我更不知道这个游戏应该是个什么样子， 但是我从没想过该怎么去处理这个问题。幸好我以前用 JavaScript 和 HTML5 做过俄罗斯方块，我仅仅通过复制粘贴，并且修改了一些小 BUG，像旋转时的碰撞检测的方式把这些写过的代码移植到 C# 而没有考虑从 2D 到 3D 的区别。
自从在每次更新的时候，我不再一次性的绘制整个游戏面板，我就不得不创建每一行到一个 GameObject 中，并且用创建的简单的立方体渲染在网格中已经被锁定的块。网格每次更新的时候我都得销毁所有的块，并且又从新创建这些块。对于我来说，我觉得这已经够好了，游戏在电脑上运行的还挺好的。
然而，我没考虑到的是，游戏面板(网格)有 10 行 20 列，这有可能要有 200 个立方体不停地渲染，销毁，重建。这还不是最坏的，假如有必要的话行数会变得更多。并且每个立方体也有它自己的引用资源这使得每个立方体都会调用一次绘图。 想象一下，铺满一个游戏面板大约需要 150 到 200 个块被渲染。这就需要大约调用 200 次绘图。
假如在我移植代码之前做了设计，我就知道这个游戏不能长时间的运行。假如在开始动手之前有这就有想法，我就不会浪费那么多时间了。
解决问题
解决问题的最好的办法是先勾勒出你的想法，然后再逐步深入。怎样让各个部分结合起来像一个整体一样的工作？这些不同的部分都做些什么？在 Sky Blocks 项目里，部分指的是游戏面板，防御线和 UFO。
游戏面板仅仅是为了控制游戏的，在游戏面板上有移动的块和已经被锁定的静止的块。而防御线仅仅是那10个立方体的静止的线。UFO 是一个可以移动到防御线上方的组合的网格。而抓住这些部分我就接近胜利了。
减少绘图调用次数
我在前面已经提到过，在这个游戏里我调用了太多次的绘图，我在我的 Android 机器上（a samsung galaxy s4）上测试我的游戏，随着功能的完善，我发现我的游戏运行的越来越慢，跟蜗牛一样。
为了让游戏运行的更好，减少绘图调用是一项重要的任务。我不得不在网上找答案。绘图调用消耗多少性能？是什么引起了绘图调用？怎样才能减少调用？
在性能的提升上，我设计不出一个好的实验方案，但是我找到了一个可以在 CPU 和 GPU 上都能运行的方案。虽然一些实验中性能上没有明显的区别，但是在我将游戏绑定到 FPS 上的大部分的实验会让游戏运行的缓慢一些
主要的原因是很容易发现的，是由于所有的立方体被分开使用素材渲染。
为了在游戏面板上减少绘图调用，我决定减少对象的数量和不同种素材的数量。
因此我试着实现了一个功能，这个功能在游戏面板上替换了以前可能分开的绘制200个立方体，而现在只需绘制一整块网格。然后我选择用顶点颜色替换了单色纹理。并且将素材着色器改变成我在网上找的无光源顶点颜色。现在我把游戏面板上多次的绘图调用变成仅仅一次。
对于防御线，我做了类似的事情，我把所有的素材修改成相同的无光源顶点颜色，但是我没有让它们作为一个网格来渲染，我沿用以前的每 10 个立方体一个防御线的策略，这是因为我已经把素材变成共享的了，这就可以把之前多次防御线的绘图调用变成一次调用。
不幸的是，由于我没对调整之前的游戏截屏，但是我又实在不想调整成以前的解决方案，因此不能向各位展示调整前后的区别。
下面这张图片是优化后的截屏，但它也只能是张图，你可以通过这张图片了解我的游戏。
活动块调用了一次绘图指令，参考（Batches: 20 或者 SetPass calls）。就像我前面所说的，以前每个块包包含 4-5 个独立的立方体并且每个都含有素材引用。因此正如你看到的每个块本身都要通过至少四次才能创建出来。
而现在在顶端的两个被锁定的块，我们仅仅使用了一次额外的绘图调用。而这些块还是活动块时， 都是由原始的立方体组成并且每个立方体至少要经过一次处理才能创建出来。
防御线使用相同的模式，但是这里只有 10 个原始的使用顶点颜色和共享素材的四方体。实际上，在这里我们不需要在一个网格里绘制完整的防御线，Unity 帮我们自动的将完整的防御线添加到“通过批处理保存”。
UFO 比较灵活些。每个 UFO 被分成 3 个独立的网格： 上，中，下。
由于我想随机的出现 UFO，并且随机的让 UFO 一部分活动 。 因此每个 UFO 的每个部分有3-4个素材。一个 UFO 大概有 12-17 次的绘图调用，然而我却发现每个 UFO 实际上有 17-30 次的绘图调用。而我大概会有 2-3 个 UFO 几乎同时出现在屏幕上，因此就有大概 50-100 次的绘图调用。好疼啊！
而在此刻，我非常非常渴望我能减少任何我能减少的绘图调用。因此我在网上找到了一个可以将所有网格合并成一个的脚本。但是这个这个脚本不能真正的适当的处理素材，所以我只能使用一种颜色的 UFO。我只能放弃多彩的漂亮的 UFO，而选用单调的讨厌的单一颜色的 UFO。通过对这个脚本的调整，我可以使用至少 2 种不同的颜色和一个纹理。 值得吗？当然了。30 次绘图调用听起来很多，也确实是。但是它表现的更好些，尽管我任然不能确信是否比之前好了很多。但是我将 UFO 绘图调用的次数减少到了仅仅 10 次左右。
是否所有的绘图调用的减少都能让我们的游戏运行的跟快呢？不一定。 假如你能减少绘图调用，这很棒！但是对于那些更灵活，微妙的部分，假如你愿意牺牲一些灵活而去减少绘图调用，也不是不行。
目前我已经把游戏运行期间的平均 150-200 次的绘图调用减少到了仅仅 75-90 次。这已经减少了很多次了！
最后一部分，UFO 射出的激光，我在深入的研究后也解决了绘图调用的问题。所有的激光也都有素材引用，这些UFO的射击间隔很短“哒-哒”。在全力射击下每个激光会有30-40次的绘图调用。还好，这比创建初始方块要容易多了，使用相同的无光源顶点颜色着色器，再分配一些顶点颜色到网格就好了。现在所有的激光只需要一次绘图调用，就算是UFO“哒-哒-哒”不停地射击也没问题。 
现在我已经将整个游戏的绘图调用降低到 30-45 次了，怎么样？还行吧！
其他的绘图调用是 UI 引起的，我本来打算减少 UI 对象的数量来提高速度，但是我现在的效果我觉得挺好的了。游戏运行的比以前更流畅了。
UFO 也使用了很少的绘图调用。但是想想大约 10 次和 30 次比较，还是有很大的区别的。
减少绘图调用的最重要的规则是使用尽可能少的素材。假如可以的话尽量使用共享素材而不是引用的素材，这些一定会帮助你减少你的绘图调用。
确保你只加载了一次资源
在我的代码中我使用了一下资源加载，但是 Unity 没有缓存加载结果，因此导致了多次的加载了相同的资源。这个功能消耗了大量的性能。 我以前也是多次的加载了相同的素材到我的激光武器上，像往常一样游戏在电脑上运行的十分好，但是在 Android 上，就不行了。
最终我避免了重复加载资源，并且删掉了项目中资源加载的地方。但是在这之前，我创建了一个静态的字典，字符串作为 Key（资源的名称），资源作为 Value，然后，我使用的时候都会检查字典里是否已经存在 Key，假如没有就加载资源，否则从字典缓存里获取资源。
我建议你可以试着用这个方法加载舞台。
尽可能避免实例化
我从来没有考虑过对象的实例化会消耗多少性能，我几乎在所有地方都实例化了。我只是觉得它跟创建一个新的类的引用消耗的性能类似。但是我错了，事实上，程序花费了一些时间在 CPU 上实例化一个对象，又花费相同时间去销毁这个对象。问题在于我发现每次 UFO 攻击的时候，他妈的都会让我创建大量的激光。每个激光的实例化和销毁间隔很短很短的时间。我算了一下，大约 20-40 对象的实例化和销毁耗时 1.5 秒。减少了绘图调用是很好，但是我从未意识到 UFO 出现后实际上是实例化消耗了大量的性能。
能解决这个问题的唯一的办法是创建有序的对象池。我在场景里面创建了一个新的空的对象并调用ProjectilePool。在代码里创建了一些新的 Projectiles ，我废弃了以前在 Projectiles list 里去查找Projectile，而是在 ProjectilePool 里线查找有没有可用的 Projectile，假如有，就取得这个 Projectile 并且从新设置它的位置和状态。这样就能从新使用这个就旧的 Projectile 了。
假如我没有在 List 中找到 Projectile，我就像以前一样创建一个。但是这时 Projectile 通常会被销毁掉，而我把 Projectile 添加到 ProjectilePool 并且使它不活动。因此我现在可以将 UFO 攻击期间的CPU 的使用率降低到几乎 25%-30%。现在我的游戏运行的超级好。
总结
绘图调用等于怪兽。假如你想尽可能的减少。最好的方式是面对他们，减少你的对象使用的素材的数量。使用较少不同的纹理，试着并且调整尽量多的纹理到地图集中。假如你正在实现 2D 并且不要使用太多的光源或者像我一样，只使用只有一种颜色的纹理。然后使用使用无光源顶点颜色，没有任何参数可以被用到所有的类。这很可能减少很多次绘图调用。假如你愿意牺牲一漂亮的视觉效果，你也可以合并网格或许这还是有用的。
实例化很慢，非常慢。试着尽可能的避免实例化。试着在初始化的时候加载尽肯能多的对象，然后当你想使用的时候在引用它们。另一个很好的方式用一个对象池循环的使用旧的对象来减少实例化的数量。
当然绘图调用和实例化不仅仅是唯一的恶棍。你得记着绘图调用使用了 CPU 和 GPU，而实例化使用了 CPU。
假如在你的游戏中你有大的复杂的模块或者太多的处理要运行。仅仅减少绘图调用是不能帮助你提供速度，当然这也会使你的游戏运行的快些但不总是这样。CPU 有时是你最大的敌人。先看看你的代码，然后试着找出运行的糟糕的地方然后让它运行的更好些。
在我的游戏中，实例化，销毁和 Web 请求时最大问题。
该文的结束只是下一篇开始
Sky Blocks 在 Google Play 上的下载地址
https://play.google.com/store/apps/details id=com.Shinobytes.SkyBlocks
我使用的无光源顶点着色器
http://pastebin.com/RMm5a4Zv
减少绘图调用到底有多重要？
“虽然绘图调用可以成为一个瓶颈，但是记住帧频才是王道。假如你的帧频是够好，那就没必要担心绘图调用。绘图调用被请求的数量是否严重的影响了性能，很大程度上取决于硬件的状况和每一帧所做的所有的事情”
— Daniel Brauer, Unity Technologies
实例化素材 VS 共享素材
实例化素材的主要的特点是一个可以让任何属性改变的素材。一个实例化素材仅仅为了一个特殊的类被实例化一次。每次的实例化都有可能会触发一次绘图调用。但是实例化之后改变他的属性是不会创建新的实例的，而仅仅是修改了当前的实例。然而共享的素材是使用了相同的着色器和其他相同的属性的素材。Unity 是可以对素材分组并且批处理所有对象来使用这个素材。自从我用了无光源着色器就没有在代码中修改过任何属性，素材也从来没有被实例化过而所有的素材都是一起被批处理的。
注意了，我将要发布一篇较详细信息的文章来介绍对于不同的对象，我是如何提高性能的，包括更多的代码实例。
但是现在，祝大家永远开心，快乐。