在4月12日的Unite 2016大会上，暴风魔镜高级产品经理吴涛分享他用Unity3D开发VR游戏的经验，以下为分享实录：
我自己是从2010年开始使用U3D开发，之前是做大型端游，也用过虚幻引擎。2010-2011年，中国移动游戏开始爆发，就转到U3D做一些U3D手游开发，去年加入暴风魔镜从事应用开发。
首先给大家分享一下我做Unity开发的积累的经验吧，最早在去年的时候呢，我从手游的开发转到了VR开发。当时，我们的产品迭代周期是比较快的，而且还在使用Unity4.X某个版本，刚刚接手VR开发的时候很多问题开始暴露，比如我们的资源制作成本增加，资源量增多，性能指标提高很多，网络环境要求更加苛刻，基于这些东西，我们也做了一些基于U3D自己的优化。
基本上大家从事VR开发的时候，还是需要一些基础团队的，建议大家都有工程师。大规模的话，还需要一些U3D工程师。目前我们团队有4个安卓，还有6个U3D工程师。安卓做接口界面，还有C++开发。
首先，第一要介绍一下我们的版本管理。我们当时最早我在做这一块的时候，当时还是用了三点几的版本，我们服务器要进行OTA更新，当时设计了一个版本管理的配置文件，大家可以看到基本上我们的制作方式是在右面，有每个资源的命名，还有一些标志是否被压缩，比如说最后具体的路径。
我们当时发现加载有点缓慢，所以之后把加到了VersionList上面，然后就进行二次拼接，这样保证本地版本和服务器版本的一致性。
为了去做刚才的版本管理的表，我将我所有的资源进行了一个大概的分类，对每一个分类都增加另外一套配置，可以看到那面，包括我们自己自定义的所有文件的合成，同样会带来一些路径，带来一些资源的ID，带来一些平台，当然也有类型压缩很多种方式，是否跟焦点绑定。
资源大概生成的过程的话基本上就是这样子，我们会自己写一个类似于生成的工具，然后我们资源制作完之后会放到自己的资源夹子，是跟美术资源分离，但会存在一个预制体和资源捆绑关系，将预制体进行build生成Assetbundle，我将原有的进行更新，再重新写我的VersionList，保证自己的新生资源和老资源是一致的。
大家都知道一般现在老的Unity版本经常资源会有一些泄露，比如说我们的美术资源经常被别人反编辑出来拿到图片拿到模型，所以说当我生成这个之后，在那里做一次资源的加密，当时制作是比较简单，现在会加更复杂的算法，比如一些越界对称非对称之类的，加这个之后呢我们遇到另外一个问题就是，因为VR，很多模型不像之前做手游可以删除一些，贴图可以小一些，他很大，这里的话资源加密之后又做了自定义压缩，当时我们找了很多相关的库，最后是通过我自己的源码，自己重新改过了一个自定义压缩库，他基本上我们在做完这步之后比以前的降了30%左右。
最后是资源管理和内存管理，我当时做的时候也是有一点困难，但是我当时就很庆幸的时候认识一个U3D工程师，首先是如果有相关连的时候会有三个游戏对象，当我释放一个的时候只将其中一个对象把他Release掉，另外两个不会，同样第二个释放掉也会把第二个Release掉，第三个全部Release掉的时候我彩绘全部UnLoad，有效降低内存使用，不会产生任何内存泄露。
同样基于刚才的算法，增加一个索引表，增加一个索引计数，做一些++和--的操作，直到Index为零的时候才释放Bundle。
另外这是网络更新，大家做网络更新很多人还用U3D提供的3W接口下载，很早的时候一直采用那个接口，大概4年前到5年前做过一款3D的ARPU，当时我要满足我的脚本跨平台，要保证足够的效率，解决一些崩溃性的问题，那个时候自己基于HTV接口实现3G缓冲下载，下载中会在内存中存放小的断点内存数据，之间的去写数据，然后当这个小的断点数据拿到内存值写到硬盘，之后下载到本地，下载完成跟本地文件进行拼接，在中间的小内存处理过程中会定期的去清理我的缓存，我知道大家有很多其他的接口可以完成缓存，但内存开销比较大。
我会开一个多线程去下载，这个下载效率我经过以前在CDA测试，可能不是太权威的测试，性能可以提升大概30%到50%，另外就是Json数据优化，那时候网络很差，都是3G和2G，那时候属于短连接的状态，发现最大的问题就是数据量很大，每次大家要等很久的时候，后面我做序列化压缩，压缩算法很简单，我每一次遇到List相关的我只保留第一个值，多余的相同的全部隐藏，这样当数据量比较大的时候，我们平均大概能优化70%的量。
另外就是一些渲染性能，我们如果大家最近在用U3D5.4Beta版本可以发现里面增加很多接口，比如说GPU，当时在我们使用的版本中是没有的，当时遇到了很多渲染性能的问题，因为当时的项目要求就是效果要好，画面要极致，但要流畅，所以当时做了很多扩展。
有过开发经验的人比较清楚我们的做法，基本上是进他们进行各种类型的合并。包括UV包括Texture。因为当时合并贴图性能非常差，我们当时是在网格合并索引合并顶点颜色的操作都是很快速完成，但贴图的合并当时是非常非常的延迟，那个时候我没有办法，就开始做一些C++扩展，在这里我们建了一个共享线程，用GPU实现贴图拼接，然后他是一个异步进行的，渲染过程中可能会有很多模型，但是可能在一开始进行的时候会有点慢，但你加载过程之后可能大概几秒之后会把他合成一个周扣，就瞬间性能提升下来，如果5.4大家可以去看U3D的接口，应该跟这个类似的算法。
有针对性的去使用着色器，在去年和前年的时候我在北京很多游戏公司的工程师还有老板去找过我，就说我们的游戏就性能很差，就是很多的机器跑不起来，或者很多的跑的不流畅，突然到某个角落的时候就开始卡了一下，我一般去到他们公司第一件事情看他们的文件夹，就说你的着色器到底有多少，美术使用多少，因为在中国来说很多美术的经验比较少的，可能对技术对渲染了解并不是太多，比如像一些可以用多少网格，多少三角形，有多少顶点，多少张贴图，场景可以做多大，我要占多少内存，其实这种有数据指标的东西比较好掌握合理解，但是涉及渲染的时候，他们用起来开始产生困惑，比如经常看到一些公司里面的一些游戏，他很简单的一个游戏的模型，他要表达一个效果，然后他可能会使用很多的寄存器和很多的贴图，但美术在使用着色器上只会用几个参数和几张贴图，那个时候当时也分析了他们的一些诉求，所以基于他们的渲染需求，我自己写了很多的着色器方便他们做各种各样效果，当他们效果匹配的时候，基本上让他们的着色器达到最优化，分析ALU，让他每次的每个使用是最优化的，不会有多余浪费和冗余。
我也是参考了一些插件中，一大部分是我自己写的，另外就是地形系统，最早我们就发现网格数比较大，比较浪费，虽然地刷很好用，那个时候就包括LED都很好用，但唯一一个就是最早的时候网格非常多，当时开使用一些自己创建的一些地形，地形模型去在场景摆放，摆放过程中发现他没有贴图混合功能，然后我当时就是有分析U3D的系统，自己去开发了一个BlendShader还有地表混合着色器，我们的植被是可以刷的，树干地表石头都可以采取Blend绘制，然后整个模型只有一个，网格数也是非常稀少的。
我以前去做一些游戏逻辑和人工智能，大家现在都知道大家都在写脚本，但基本上我当时也做过开发，比如一些内存加密等等，但是依然解决不了就开发的时候很多漏洞和调试问题，尤其是人工智能这一块，我想实现一个流程在引擎中，那个时候Animator出来了，利用这个状态图实现有线状态机，这些状态机的脚本都在本地里面存着，我只需要更新服务器上的小怪的AI，也是可以的。
另外是代码安全的问题，就是现在因为大家都知道很多的我们开发一些游戏发布出去，经常会有反BA的工具把我们反BA掉，当时也是发了很多文档，最后找到Mono虚拟机的原码，同样开发DLL也进行了重新编译，基本上可以进行加密，最后发布到Application中。
目前现在开始用另外的方法来做，这是比较老的一个方法，另外兼容和适配，最早做游戏的时候还是，为了覆盖大部分的安卓机型，需要做一个很复杂的兼容适配，发现比任何代码和算法都解决不了多机型适配问题，那个时候开使用大数据，将所有的机型配置分级别，对他们所用的配置，数据的话会直接存到服务器端，第一次登陆打开游戏的时候，会把机型发送到服务器上，服务器根据我本地的配置在服务器寻找相关的配置资源，游戏打开的时候自动的帮玩家适配好，根据机型最优化的表现方式。
希望大家在目前的话VR还是一个起步阶段，我们还是非常缺内容的平台，希望更多的开发者加入VR开发，我们也希望能帮助开发者一起去创造一个中国VR互联网的环境。谢谢大家。
