由于游戏中普通界面ui的逻辑和玩法的逻辑差异太大了，单独用某一种框架来适配全部内容我觉得是不合适的。
角色信息，背包，排行榜等大部分界面，一次请求数据，后续变化不大，mvvm没有发挥空间。
具体玩法中，血量，buff，特效等不停变化的内容mvvm能优化更新的逻辑，但也谈不上多大优势。
但是从造轮子难度，多人协作，逻辑通畅度，等方面又怎样呢？反正我还没开始造，大伙怎么看呢？
如果一个游戏用两套框架，那又是重复造轮子了 
根据项目选择吧，没有谁好谁坏，只有更合适
不好用，mvp就挺好的
1赞
局外ui部分mvvm可用
战斗内频繁变化的，可以主动更新，或者用事件监听的方式
我用得最多订阅-观察者模式
具体一点就是用一个 System 处理所有逻辑数据后进行广播（状态变更）
Cocos的组件作为一个观察者在 onEnable 和 onDisable 订阅/取消订阅 组件自己感兴趣的广播
2赞
不要把 mvvm 视为框架，而是视为工具，mvvm 本质就是监听数据变更更新视图
- 非 mvvm：手动写setXXX接口并且只使用这个接口，接口内派发事件，其他地方再监听事件更新视图
- mvvm：直接监听数据修改，然后更新视图
想用数据监听的话可以提取这里代码使用：数据监听器
+1 感觉很万金油, 能处理大部分逻辑
我甚至在其他引擎里也都封装了 on once off emit
巨好用
不好用，最好用是mve，e就是event，推几个显示层要刷新的event就完事了
2赞
我实际项目中用的最多的就是这种，自己封装基类来统一订阅/取消订阅，那种塔防、肉鸽或对战的可以考虑局部用一用mvvm
MVC 我都嫌弃C多余,MV+events 真实又解耦写起来逻辑又清晰.
3赞
看来大伙都是很实际的，什么效率高用什么
我用的最多都是一把梭，多人我也觉得MV合适
mv + 消息通知(事件/广播/随便叫什么啦) 万能
看见大家都这么说我就放心了
确实，，，
+10086