但凡做过的项目复杂一些,或者需要多人合作,肯定是用方法2
我正在用quickframework，感觉这个框架的描述很好。推荐B方案，能做小，能做大。A只能做小。
-
Q : 为什么使用单场景？
- 保证视图在切换场景时正常弹出
- 如下情况，如多场景情况下，A场景->B场景，A场景上请求网络数据希望在B场景上弹出，当收到网络返回时 还需要检查当前是否在B场景中，如果不在则压入到显示队列中，等进入B场景，检查当前是否有显示视图队列 如果有显示的视图，依次弹出，但如果采用单场景化，无须关心在哪一个场景，收到网络回复直接弹出。
- 保护界面状态
- 还是在多场景下，在切换场景时，必定会先把场景上所有视图关闭，清除数据，但若有需要在A场景下显示的 界面也希望在B场景下显示，此时场景的过渡，会先关闭界面，进入B场景时显示，但如果场景上有ListView类 似的控件，也希望在切换场景时，显示之前玩家操作显示的位置，那么必定会花费额外的工作去保存玩家在A场景 上操作界面的相关信息，再进入B场景时，恢复玩家对界面操作的所有状态，但如果只是单场景，可以模拟一个 场景的切换动作，直接隐藏掉界面，进入B场景，直接显示，无须保存界面的状态。
-
Q : 项目为什么不推荐使用在预置体中直接挂载脚本？
- 方便重构
- 如下情况，当你发现目录结构不合理，或者文件名取名有误时，但此时已经在预置上挂载了过多的组件，还有 些项目的子游戏是在不同的svn版本管理下，在开发时，并不会放入全量的代码进入开发，如果如果此时改名或 移动目录，可能会造成文件的uuid发生变化，Creator上只会显示该脚本为Misson状态，并不会显示之前挂载 的是哪一个脚本，若项目足够大，一个脚本的uuid变化，可能会造成大量预置体重新设置挂载脚本，提高了 维护的成本
-
Q : 为什么项目都采用预置体+UIView组件绑定方式？
- 1，统一化管理，工厂式创建，方便实现统一的动画效果，一个公司的界面显示动画，可能大多数情况下是统一风格，如果我们要实现统一定制化 动画，只需要在UIView中统一处理，直接显示通过UIManager.open()方式调用
- 2，把内存及资源的管理交到管理器处理，减少开发者对何时释放资源，何时加载资源的烦恼，只关注自己的 业务逻辑处理，无须关注资源的加载与释放
- 3，接口统一，方便后期对界面的打开次数统计，以提供数据给运营人员，查看该模块的受欢迎程度
-
Q : 项目主要核心模块为什么都在管理器Manager上？
- 提高可读性，新手上手快，拿到代码只能从Manager上直接了解整个项目的结构模块，尽量避免全局变量满天飞的情况 后面框架的使用者也可直接把全局的通过数据直接挂载到Manager中使用，减少全局变量的污染。
-
Q : 项目为什么推荐万事尽量保留类型？ *
- 个人观点，项目采用VSCode + Creator + typescript 方式进行开发，而typescript VSCode 都是Microsoft 公司 的产品，Microsoft公司在JavaScript 基础上加上了type,就是为了解决弱语言类型无类型化，可读性差，
- 1，您可以清楚你的实际来自哪一个类型，跟继承的关系
- 2，编辑友好加上VSCode的智能代码提示跟静态语法检查，让你在开发时，减少错误
- 3，代码更严谨，可在传入参数中限制传入的类型，类型的检查交给VSCode处理
- 4，方便重构，如果当你发现某个文件放置位置不对，可直接在VSCode中拖动到你想要的位置，VSCode会自动的更正你托动 代码所有引用的位置，或者对API 类名等修改操作，VSCode也会自动更改所有引用此类型的地方，降低重构的成本
- 5，最后说一句，没有人比VSCode 更懂TypeScript ,TypeScript的重点在Type,无论什么情况，尽量保留类型。
1赞
这个问题，在我刚刚接触unity的时候，也想了好久，头都想痛了。归根到底是编辑器内置的那套组织结构和脑子里面原有的编程范式不一致的原因。
后来我想通了，不依赖编辑器了。这样任何架构根据情况都可以使用。就算是做和编辑器一样的Entity-Component模式，Entity也是自己的类，并且也会用一个ViewObjectComponent去保存编辑器的node。
编辑器里面挂组件，可以看成资源里面带逻辑，面板上填属性拖引用，可以看成变相的依赖注入。预制体挂组件的性质，其实和动画状态机里面带事件逻辑一样，都是资源过度带逻辑。
而我的设计原则是，资源里面尽量少带逻辑，真的要带也只能带资源的规范性质的逻辑（例如节点路径这种类似规范性质的是可以带的），以免逻辑依赖到资源上。也尽量减少不可代码追溯的依赖注入，以免找不到初始化的逻辑。
所以一般来说我是选择代码式的。
而且 场景 的描述文本 咱还看不懂！
个人觉得 A B都太极端了，我是中间流
一个场景 一个脚本，其他都是 ui组件
这似乎不太够，也给预制体也要配一个脚本
目前我的项目没涉及到多人开发， 所以自己感觉还可以
场景描述文件 不用比对，直接覆盖，只需要比对脚本即可！
但我依然搞不清 多人协作时 场景描述文件 怎么处理? 难道是靠个人约束?
我也选B。
A
优势：开发小功能快。（但是在有成熟框架的时候，这个优势基本可以忽略）
缺点：
1.引擎一个bug，可以让你绑的代码丢失重新搞。
2.代码不好审查，因为你阅读代码的时候很难找到代码挂在了哪些地方。尽管有各种反查工具，但是这个查找效率低，大大影响工作效率。
3.多人开发绝对的噩梦。你根本不知道这个代码用在哪，用来干什么的，改了之后不知道多少预制体受影响。
4.引擎升级基本不敢想，整个项目基本都要大动干戈。
B
优势：
1.代码审查方便，ide一搜就可以搜到。
2.引擎bug只影响预制体的美术编辑，对代码几乎没有影响，顶多就重新拉一次主入口代码挂载节点。
3.引擎升级基本只需要调整更新的部分api，不需要重新给预制体拉代码。
4.多人开发方便，减少提交代码时的冲突。
缺点：
1.需要手动挂载组件。
2.需要手动获取预制体上的某一节点。（这个用自动生成工具就可以了，像下面的这种）
总结：
1.小游戏不考虑维护，不考虑做大，仅一人开发，功能简单的就用A
2.大游戏需要长期维护，需要不断增加功能，多人开发，功能复杂就用B
生成代码的引用这个回复，对于 uuid 丢失的问题，我在 2.x 经常遇到，3.x 一次都没遇到
我之前也做过这种插件，但是缺点和楼上说的一致，只有运行时才会知道节点树路径错误
https://forum.cocos.org/t/topic/130305/11?u=1226085293
事实上 A 的缺点是可以解决的，我上面已经说过了，只需把引用资源和直接加载预制体的方式改成调用组件脚本内的静态 open/close 函数即可，但是目前只看到我一个人这样做 
3.x我也经常遇到uuid丢失问题，当然不仅这个问题，变量名修改也要重新绑定。
节点数路径不一致的问题其实只要做个监听预制体修改的插件就行，只要预制体更改，就自动生成，这样就不会对不上节点树了。A方式绝对不适合多人开发，不要说多人了，只要项目大一点，过时间久了，完全不知道这个代码被哪些预制体引用。只要是项目需要长期运行维护的，B的优势会更大。
B 方式通过查找引用代码
A 方式也是有查找引用，所以有什么不同呢？反而 B 方式要多写一堆代码
另外只有工具脚本才会被多个预制体引用
说说复现方式？
你挂预制体的代码引用查找很慢的，并且你挂预制体上的代码，你怎么审核？对面提交代码你难道读他uuid一个一个找他挂了什么代码？如果用B方式，我对比差异一眼就看到他挂了什么代码上去了，这个预制体他引用了什么代码一眼明了
偶发的，一般就是预制体里引用其他预制体然后有时候就会触发，触发几率不大，但是只要触发，知道的人可能知道可以把child为null的清掉恢复，不知道的人只能还原重新做
工具代码一般都是初次才会审查，之后的审查有什么意义吗？难道不是审查业务逻辑而是审查挂了什么工具脚本？
可以看看这个，报错基本一致，现在知道解决方法就是把为null的child删了可以恢复，以前不知道，这么一下你整个预制体都没了
https://forum.cocos.org/t/topic/141509
从2.x用到3.x，天天用，只遇到升级出现问题，而升级出现问题的是节点属性而不是组件属性
就是审查业务代码呀 ，你审查业务逻辑难道不要看他改了这个代码，会不会对原有挂有这个代码的预制体有什么影响吗？那这个时候你怎么确认呢？
这个问题是不管挂不挂脚本都可能会出现的问题
是的，审查业务代码，那么 A，B 两种方式有什么差异？同样都可以跳转代码，只是B的工具代码看不到挂载的部分
而A的工具代码挂载都是固定的，那么有什么特别好的地方？
你这里说的缺点是 不知道这个代码被哪些预制体引用，但是事实上这个缺点是只有工具组件才会存在的。但是也可以通过查找引用的方式找到
那么 A 方式
-
审查代码可以直接跳转（排除工具组件，你上面说过）
-
查找预制体有字符串路径，也可以编辑器查找引用
-
查找工具组件可以通过编辑器查找引用
而预制体出现问题的是升级和撤销，无论你是用 A/B 两种方式都会出现
请说下A还有哪些问题？
如果限制一个预制件只挂载一个ui脚本，或者按一定的规范挂载，并且节点的绑定在代码里面find,不是通过编辑器拖动，确实A也没啥问题；
我见过有的项目，一个预制件里面挂了很多业务的脚本，节点都是编辑器拖上去的，真的很难维护