C# Unity游戏开发——Excel中的数据是如何到游戏中的 （四）2018.4.3更新
本帖是延续的：C# Unity游戏开发——Excel中的数据是如何到游戏中的 （三）
前言
最近项目不算太忙，终于有时间更新博客了。关于数据处理这个主题前面的（一）（二）（三）基本上算是一个完整的静态数据处理方案了。
不过前几篇发布的时候是2015年，比较早了，随着这几年技术不断积累和进步，其实已经有更好的方案来处理数据了，不过对于前端存储的那几个M的数据，多点少点其实影响也不大。
但是也不能就这样算了，毕竟技术的变化日新月异，还是要保持持续学习的心态。
虽然简单但却不易忽视
对于游戏中静态数据的处理，单纯的对于整个程序项目来说其实只是很小的一部分。写个读写工具，打个包，压个缩，加个密其实对于很
多程序来说也不是难事。但是，我又要说但是了。但是，根据博主的个人经验来说，数据对于游戏的业务逻辑是非常底层的“逻辑”，对于
后期的开发起到了一个基础的作用。主要体现在两个方面:
1.业务逻辑角度的数据结构化。
这点很关键，策划想要把自己大脑里的游戏玩法用数据表示出来，而这个表示过程其实是需要程序配合的，因为不可能每个策划
都那么牛逼，然而现实情况也确实如此。因此，这部分要做的事就是，用数据抽象的思维把策划描述的游戏世界表示出来，最终
体现就是“表格”。这些数据，其实就是游戏业务逻辑的“骨架”，后续的开发都是围绕着数据来做的，或者说被数据“支配”的。
2.程序结构的设计。
第一条说过了，“后续的开发都是围绕着数据来做的”，那么这些数据的使用频率必然会很高。那么，问题来了，如何设计这部分的程序结构会使开发效率和运行效率最优？单纯的创建一个类，把所有数据查询的方法都放里面？还是根据第一条抽象出来的“实体类”来组织数据，然后对数据做一些预处理，例如游戏运行先进行分类然后放到内存中等待使用？
显然，后者更加高效，这也“静态数据处理虽然简单，但是也不容忽视”的理由。
最新的方案
前面也说了，技术是不断在变化的，我们也需要快速适应。之前的方案确实用了很长时间，也没什么问题。但是自己撸的代码总有几个疑问？这是最好的方案吗？和最好的方案差距有多大？
带着这几个问题，在最近2年所做的项目中也对这方面做了一些工作：1，在最近的项目中使用了ScriptableObject的方式。2,开始了一个protobuf方式处理数据的开源项目。
说起来惭愧，其实结果影响并不算很大，下面把这部分总结一下。
方案一 : 使用Unity的ScriptableObject。
做法就是每个表格生成的数据类都直接或者间接的继承自ScriptableObject类，打包的时候直接把所有表数据都生成一个对应类型的.asset文件。然后建一个总的Map类来存放所有asset的引用，当然这个Map类也必须继承自ScriptableObject，也生成对应的.asset文件。最终打包的时候，只打这个Map类的.asset文件，Unity会自动识别里面的依赖关系，将所有数据打包进bundle。
实体类Hero
using UnityEngine; public class Hero : ScriptableObject { public string name; public string level; }
Map类
using UnityEngine; using System.Collections.Generic; public class Map : ScriptableObject { public List<Hero> heroList = new List<Hero>(); }
最终在使用的时候也很方便：
AssetBundle bundle = AssetBundle.LoadFromFile(Application.streamingAssetsPath + "/constance"); Map m_Constance = bundle.LoadAsset("constance") as Map;
这种方式对Unity3D非常友好，使用起来也非常方便，但是缺点也是有的，下面来总结一下：
优点：
可以和预制产生依赖，prefab如果依赖了asset打包的时候也会打进去，减少了查找操作。
可以直接用Unity API操作asset。省去了一部分序列化反序列化代码。
可以直接用AssetBundle.LoadAsset() as Map;加载，省去了之前的反序列化代码。
在Unty中选中asset可以直接在Inpector中看到数据。
缺点：
生成asset的时候会有大量的文件操作，速度慢。
还有两个指标就是运行速度和存储空间。由于影响不大，没有做进一步测试。
存储空间的话，我这里有个参考：6个Excel文件占用的pc上的磁盘空间是112k，最终打成AssetBundle是31k。
方案二 : 使用protobuf
这种做法主要是通过google提供的protobuf来序列化和反序列化数据，并且使用protoc生成目标语言的代码。工作流程如下图所示。
把做法分成几部分来说：
操作1，读取excel数据描述信息，通过excel数据描述信息生成.proto文件。
操作2，使用protoc命令行生成本地代码，也就是你制作工具使用的语言代码。
操作3，创建本地代码的类的实例。
操作4，读取excel数据，并且将内容赋值给“操作3”创建的实例，最终使用protobuf API序列化。
操作5，生成目标平台的代码。
最终生成的二进制文件（.bytes）和目标代码会和程序一同发布，使用生成的目标代码解析生成的二进制数据。
具体代码就不贴出了，下面是本人对方案二开启的一个开源项目，用的是java+netbean8.2,目前已经完成大部分内容。
有兴趣的同学可以看一下。我会一直更新。
https://github.com/superbig/proto-packer
最后
如果你在游戏开发的静态数据处理方面还在犹豫，建议是：如果项目小可是试试ScriptableObject方式，应使用起来确实要方便一些。当然你也需要忍受数据导出时候的频繁的IO操作（当然其实你也可以开发一个增量导出的工具）。
如果项目大，数据很多还是老老实实用protobuf，空间占用少，速度快。或者自己写。
版权声明：本文为博主原创文章，未经博主允许不得转载。 http://www.cnblogs.com/fly-100/p/8707749.html