对ScriptableObject做一个评价

ScriptableObject下面简称SO

评价

1. 首先SO直接引用资源做配表是一个用起来很爽的方案，容易让人形成依赖；
2. 然后SO如果后面你觉得里面的成员命名不合理，想改名，会面临配表数据部分崩或者全崩的风险（特别是里面的配置列表，列表名改了数据全崩）。它不是一个适合放大量“鸡蛋”的“篮子”，或者说放大量鸡蛋的唯一的篮子。
3. 然后SO直接引用会导致加载SO时把它引用的资源全加载了，内存占用比记录路径大很多；
4. SO直接引用，打AB包的时候你会发现它牵连了一大堆资源，无法分包的时候分的比较细。顺势的，你要热更资源包，里面只有一小部分要更新，也要更新整个大包；
5. 检查器不能显示字典，但是取用配表最方便的肯定是以id为键的字典。那么用SO就要运行时构造字典。而json用NewtonSoft.json是能直接导出为字典，读取为字典的。
6. 它的缺陷总结起来就是直接引用的强耦合导致的内存占用更大、热更不灵活，还有检查器不能显示字典；
7. 由于以上缺陷，商业项目不会拿它做直接配表，而是做Excel导出的中间数据，或者直接不用，用Excel导出json。商业项目不倾向于用SO直接引用；

注意

1. SO也是按ctrl S才保存。虽然它不会给场景加上*，但从.asset文件的变换可以看出来。
2. 修改了SO成员名后之前数据会不显示，但其实.asset文件里还有，只是因为名称、类型不匹配显示不了。除非把字段名、类型改成和之前一样，否则这部分数据会保留在.asset文件里，因为显示不出来而无法修改、删除。.asset文件里数据都是YAML格式，很难读，汉字都是unicode编码，所以也不要试图手改YAML。这又导致打包时会带上之前它引用的资源，虽然检查器里看不到。