说到图片,我平常要用Billfish辅助查看寻找游戏资源,billfish能按颜色,标签搜图,能自己按各种条件排序…cocos能内嵌一些的话肯定会大幅提高效率.
至少,设计上,同等开发量的情况,参考一些高效的方法也能提高很多效率
还有 unity在image上可以直接点开图片资源库,直接替换,在做ui的时候这个功能不错的
还是那句话，实践出真知。
我不参与争论谁好谁坏，
两个方向没有绝对对错。
如果谁进到大公司，贯彻B方案 自己从零到一做到一款稳定上线运营 并有一定量级的产品，
技术细节敢在司内接受所有技术的pk，
并且工作流和人员技术管理都依赖B方案有一套公司认可的方法论，
那他也一定是对的。我没法不认同。
说到这些 在项目上2种方案都已经使用过
上份工作使用的是A方案，项目定位是重度卡牌，目前工作使用的是B方案，定位也是重度卡牌
在使用A方案时，每个脚本中所new出的对象都需要在该脚本的关闭生命周期里释放掉
在使用B方案时没有在该脚本关闭生命周期函数里释放（我们当前项目没有做这一步）
比如:
this.items = []
this.items.push(instantiate(Node))
那么在A方案中则会：
destroy(){
for(let i = 0;i < this.items.length; i++) {
this.items[i].destroy()
}
}
在B方案中则不存在这步操作
是因为挂载的脚本的原因吗
没有去研究过为什么要这么做
也没有去研究过不这么做会怎么样
但是一直存在这个疑问
主要看你怎么做吧，毕竟方案b是脚本去绑定节点，节点销毁了控制的脚本还在，所以就算销毁也是自己处理不可能走生命周期函数了，如果这个脚本一直重复使用，new出来的对象管理的得当一直在重复使用的当然不会销毁了。
a是脚本跟着节点走了，节点都销毁了脚本当然也要跟着走了，那你new出来的对象又谈何复用呢，所以肯定要销毁掉。
反过来说如果a的节点不是销毁的而是隐藏等手段保存起来管理的那也可以不销毁，b如果脚本对象也会触发销毁逻辑那你还是得写好对象的管理、销毁逻辑。
但说实在的，能写destroy的逻辑尽量写，就算明知道当前这个情况不存在脚本销毁，但你也无法预料未来发生的事情，万一未来分包把这块逻辑分出去变成不是必须的功能也要销毁了呢，还有各种原因
2026年了,重新看这个问题, 只要装个mcp, AI基本就能读懂A流派, 而且有了AI加持下, 应该更加拥抱A流派, 留给你维护的代码不多了, 只有A流派可视化才能高效的与AI协作. B流派就是纯属的许愿机了.
不对哦，应该把更多的逻辑关系放在代码文本里面，AI无需什么MCP就可以知道，而不是编辑器拖过来绑定，这种AI才不能一次性读取解析。
我是标准的B方式, 远古引擎都只有API没有编辑器的,习惯这种风格了,而且喜欢一目了然的代码关系,各种挂在组件上的代码复杂的多人项目看着太累了,我用creator就一个root节点,其他都手戳,只要不是复杂的预制体,我可能也用手搓了,用creator就为了一个,打包发布方便…
4年半了啊。你们还在挖我这老帖子啊。
不是吧，我感觉都不用手动挂脚本了，我自己创好预制体，其他脚本都让AI动态挂了，就是场景里我会挂一个启动脚本。
现在谁还用手动在prefab上挂脚本拖拽节点啊，太慢了。我们都是需要使用的节点做好命名规范（也能方便AI），节点数据统一脚本导出，运行时动态绑定，使用时代码里this.节点名 直接使用就行了。prefab改路径换皮 脚本重新统一导出一下，代码都不用改
我一直用的都是B，后来公司垮掉了，去了两个小公司，发现都是A写法，一个类都是上万行代码，而且没有注释，头都大。后来基于以前积累的多个项目经验，积累的框架经验，改写了一套B这样子的框架。我自己就用B这种，架构搭好，后续调整也方便。其他同事用A，我自己用B，两套可以混用
我也是，十多年用的B方式，而且中间直接架了一层引擎适配的中间层，因为只是2D项目，中间这一层全部把这些组件重新实现一遍 
，相当于适配了一层UI的架构。所有的节点直接用一个对象包装起来，直接用这个对象点出来，因为是ts，所以再做一个预制体生成接口的插件就可以了。因为也是不习惯绑定脚本，然后所有的生命周期，都是这个框架里面管理。就差把预制体重新解析成自己定义的二进制文件格式了、外加一个加载解析逻辑（加载目前也是中间加一层的）。。。。后来想着算了，直接序列化、和反序列化cocos组件属性
现在已经躺平了, 不管是A还是B, 都是claude大哥给我看.
2赞
流派可不只是A和B，流派很多，我用的就既不是A也不是B，没有单纯的哪一种，具体问题具体分析，编辑器本身的可视化编辑以及组件系统本身就具有设计上的优势，我会基于组件系统搭建项目结构和框架，分层实现最终需求目的。UI交互层充分利用编辑器和组件脚本的优点做通用交互逻辑，自动做最基础的UI绑定和交互。功能逻辑就是完全脱离编辑器甚至引擎的模块设计代码，每个模块都是独立的，不依赖引擎。逻辑层没有UI也能跑，换个引擎也能用。
1赞
都四年半了，这个帖子还被挖出来，我真是受宠若惊啊。不过时代变了。现在只有一个流派了。 codex帮我实现一下这个。
多人开发就选B，提交冲突会简单很多，如果确定主场景和里面的显示器只有一个人维护，不会有提交冲突那倒还好。公司的话肯定都建议B
简直离谱，改起来不得爽死了
也还行，架构前期支持麻烦、复杂，后续稳定了就问题不大。反正也只是做2D的多，而且中间层可以随时增加、或优化功能，就算cocos引擎升级修改、或增加了什么大批接口，也就架构适配层跟着改，上层完全不需要处理。这样子就算UI哪个组件有问题，完全不需要等Cocos版本升级更新。可以自己本地先修复。