嗯.那没必要. ID化只针对量多的时候才便捷. 量少反而显得繁琐. 你的没问题.
目前来说
只有首场景会通过硬编码来配置一些加载项，不过也不多，大概有个10行左右
剩下的基本都是解析配置表，然后根据配置数据来组装需要加载的资源
比如进战斗时，根据当前关卡的配置数据，把用到的地图、怪物、使用的技能等信息组装成需要的格式
加载读条完成后进战斗
当退出战斗后，再一键卸载掉
1赞
嗯很清晰的流程。
我比较烦恼的是动态加载一些资源的时候，需要自己管理引用计数，加载后，用的时候要+1，节点销毁的时候要找到资源然后对其-1，计数归零了再去释放，一旦漏了-1，就会有资源卸载不掉造成资源泄漏。一旦重复-1又会错误释放资源。
可以，这个东西不错。我收藏了。下次项目我要用
工作找的怎么样了 
所以规划时，按模块分
这样加载整合模块的内容，之后就直接用，等不用的时候，就全卸载掉
应该可以省点事
我们两个都在一个微信群里，你直接私我不就好了。 
即时聊天和传统的论坛聊感觉是不一样滴
应该问，后续的剧情准备什么时候写
哈哈哈哈哈哈哈
看着应该是有问题的。如果使用到了交叉资源
我自用不会出现交叉资源
想交叉的话，改下引用计数
然后再改下所在的批次
自己做的，肯定自己会注意，人一多，自然就容易乱了。对此，2个字，头疼。
还好吧，一个项目组也就几个人
嘿嘿 我们的小组都比较小
特别棒！现在它是我的了
大佬，交叉资源会引发什么问题？举个例子讲解呗
在主界面P1用到了资源R1，主界面打开了商城P2用到了资源R1，关闭商城P2，直接释放了所有商城P2里的资源，P1还在使用，出现问题，所以一般推荐用引用计数。
但Cocos中还有个问题
a资源加引用计数 1 -> 正在加载a资源时，修改引用计数为0(释放) -> 加载成功（回调里）的资源是被释放的资源
1赞
感谢
这几天想了一下，觉得unity那个addressable是真不错，直接bundle无感化。
参考一下，做一个文件名和bundle的映射，提出一个公共层级或者直接用系统内置的resource做通用包，其他模块包可以引用这个通用包。
因为cocos的bundle只是info，所以也无需卸载，只关注资源的加载和卸载就好了。
现在的问题就是，需要手动去生成这个json，编辑器拓展太难搞了。