这是我在《Unity游戏优化 (第2版)》看的，记录一下~
艺术是一个非常主观的领域，由个人的意见和偏好所支配
支持游戏艺术性的艺术资产背后的技术也是非常主观的
Unity中有多种不同的资源类型
首先探索一下音频文件
啥玩意是音频文件？
少数音效或者单一背景音乐，或者数百万行对话、音乐和环境音效等等
有啥问题呢？
运行时的音频处理会造成CPU和内存的消耗
为啥有这问题呢？
过度压缩、或者过多的音频操作、过多的活动音频组件、低效的内存存储方法和访问速度等等
将音频文件导入Unity中
1.加载音频文件
怎么加载音频文件呢？
a.音频文件就是一个二进制数据（打包之后）
b.加载音频需要将其从硬盘拉入主内存（RAM）
c.然后由音频解码器进行处理
d.最后将数据转换为音频信号，送到耳机或扬声器
在unity中通过以下几种设置可以指定音频文件的加载方式：
1.Preload Audio Data
决定音频数据是否在场景初始化期间自动加载，还是在以后加载
一般音频文件的用法都是：
放在AudioSource组件中的audioClip属性，将音频文件包装在AudioClip对象中，然后可以通过AudioSource的Play或者PlayOneShot方法触发播放
这样做会使得每个音频文件都将在场景初始化期间加载到内存中，因为场景包含对这些文件的即时引用，在需要这些文件之前必须先解析这些饮用（启用了preload audioData）
如果禁用了preload audioData，就会导致unity在初始化场景期间跳过音频资源的加载
会将加载活动推迟到需要使用的音频文件时，也就是当调用Play的时候
禁用后会加快场景的初始化，但第一次播放文件的时候，必须将阻塞主线程直至完成
如果资源文件过大，会导致时间过长，卡顿非常明显，这是接受不了的
（也可以调用AudioClip.LoadAudioData()可以实现音频加载）
2.Load In Background
决定是否在完成之前阻塞主线程，还是异步加载
如果禁用了preload audiData后，使用load in background选项
会将音频加载改为异步加载，加载不会阻塞主线程
AudioCLip.LoadAudioData的调用会立即完成，可以通过loadState属性查看当前的加载状态
如果开启了 load inbackGround 而且在加载数据的情况下调用 AudioSource.Play()
unity仍然会在播放之间将文件加载到内存中，会导致Play和音频文件实际开始播放之间会有延迟
3.LoadType
定义了将什么类型的数据拉入内存，以及一次拉多少内存
有3种选择
a.Decompress On Load
设置压缩磁盘上的文件节省空间，在首次加载的时候将其解压到内存中
是大部分情况使用的标准方法
缺点就是解压文件需要一定时间，导致加载过程中的额外开销
b.Compress In Memory
加载音频时只是将其直接从磁盘复制到内存中
只有播放音频文件时，才会在运行期间对其进行解压缩
会导致播放音频文件时消耗更多的CPU，但是提高了加载速度，减少了运行时内存消耗
（适合频繁使用的大型音频文件）
c.Streaming
将在运行时加载、解码和播放文件
逐步将文件推过一个小缓冲区，在缓冲区中一次只存在整个文件的一小部分数据
会导致运行时CPU开销最大，但是内存使用最少
每个文件的回放实例都需要生成自己的缓冲区，如果多次引用音频文件
会导致内存中同一音频文件的多个副本必须单独处理，不能胡乱使用
使用定期播放的单实例音频剪辑，不需要与自身的其他实例甚至于其他的流式音频剪辑重叠
（最好与背景音乐和背景音效因其使用，这些音效需要在场景里的大多数时间里播放）
