Unity探究预制体浮点数对Unity资源大小的影响
以下内容是根据Unity 2020.1.0f1版本进行编写的
一直以来，我都有一个疑问，对于浮点数，特别是很长的浮点数，例如在Unity的预制中偶尔会出现的很接近0的小数，或者xxx.999或xxx.001（如图），这些接近整数的小数，在较少情况下是有用的，但实际上很多时候都是没用的。如果这些浮点数过多，会不会影响打包后的包体大小？
现在就来试验一下，先新建一个工程，准备一堆有上述问题的预制，并把打包脚本写好（只需要打包成AssetBundle就行，这里不赘述）
先手动搞一个包含小数点的空节点，接着准备一些预制，每个预制复制此空节点，以复制数量命名，例如_1就是只有一个浮点数空节点，_50就是有50个浮点数空节点。
接着将预制打包一遍，得到AssetBundle，这里我分别用两种不同的打包策略来打包，一种是每个预制打一个包，一种是全部预制打一个包，用以后续作对比。
上图就是两种方式打包后的AssetBundle
接下来将浮点数去掉，再打一次包
发现没什么变化，看了一下是一开始打AB包时用了ChunkBasedCompression压缩，然后将其改为UncompressedAssetBundle又试了一次（上面的截图都是未压缩的），发现还是一样没变，怀疑是Unity打包时，就是不压缩也有做优化。
于是问了一下百度最新AI：
这里考虑是因为存在连续相同的浮点数，毕竟浮点数的空节点都是复制的。因此加个脚本，把所有预制的position都改成随机小数。
发现还是没变，估计是有可能打包去掉了部分精度，因此变化不大。
最后说下结论，后续我又在公司项目中试了一下，经过试验，预制是小了，但是小了几个字节意义不大，而且系统存储文件和簇的大小有关，几十个字节的变化不会改变文件的占用空间。并且打出来的AssetBundle包，有可能小一点，还有可能变大，变大也是在几十个字节内变化，意义不大。因此，我觉得预制体上的浮点数不会影响打出来的包体大小，除非有特殊规范，否则不用管。