静态引用
即在脚本中创建public变量或Serializable特性修饰的变量，然后在Inspector窗口中通过拖拽挂载到物体上；
优点
简单粗暴快捷，刚学Unity的时候就喜欢用这玩意orz
缺点
- 只能是预先确定好的资源，不能运行时动态加载；
- 不利于做内存与资源管理，静态引用的资源会在持有其引用的物体生成时一并加载到内存中，即便该资源没有被实例化；
动态加载
Resources
即将资源放在Resources文件夹下，加载时通过Resources.Load() 进行动态加载；
优点
- 可以动态加载，也可以运行时动态卸载；
缺点
- Resources文件夹下所有的资源在打包构建时都会被打入包中，即便该资源没有在任何地方被使用（Unity不知道是否有代码加载了该资源），导致包体变大，并且增加打包构建的时间；
- 所有Resouces文件夹下的资源都会被打入一个单独的资源文件中，如果资源有变更就要重新构建打包，无法增量更新；
网上很多观点认为Resources会减慢游戏的启动时间，原因是”在游戏启动时，Unity引擎会为Resources文件夹下的资源建立一个查找树来存放与其对应的索引，便于后续资源的加载。一般来说，Resouces文件夹下资源数量越多，其构建时间越长，应用的启动也就越慢。“实际上这是老版本Unity中才有的问题，根据实际测试（以及一些愿意动手而不是直接得出结论的网友测试），新版本Unity并没有这个问题（也许不对，希望有更严谨全面的测试文章）。一些关于内存的观点也是在编辑器环境下测试得到的，并不严谨，甚至有人认为Unity会在启动时一股脑将Resources的东西全部加载到内存中（汗）。无论如何，商业项目不使用Resources更多的还是因为不符合项目利益，大项目必然要热更，而且一次打包这么多资源会浪费很多时间成本。
AssetBundle
即给资源分AB包，在运行时通过加载AB包的形式加载资源；
优点
- 资源加载和内存管理方便，可以按需加载；
- 可以增量更新；
- 可以做首包拆分，玩家只需要下载较小的包体就可以进入游戏，后续内容在游玩时再下载；
缺点
- 管理复杂，需要考虑AB包的加载卸载以及依赖问题；
Addressable
Unity官方提供的AB包管理策略，实则就是Unity对AssetBundle的一层封装，个人以及小体量团队没有能力自定义AssetBundle管理方案下的神；
优点
- 好用！兼顾了AssetBundle的特性，又免去了繁杂的管理问题，只需要配置好AB包的内容直接加载就行，不过要注意每个资源有Load就有Release，因为Addressable是通过引用计数去判断卸载bundle的；
缺点
- 性能上也许不如一些成熟或高度定制化的AB包解决方案（那我也做不出来啊）
- 也许还不够稳定？