不复杂啊 其实就是整合数据不用全部放view里面
是我层次低了。。。或许理解是什么场景情况了。我感觉这种的东西一般小公司没什么用的，多用于大公司跨项目合作统一代码规范的样子。不知道大佬是不是这种想法
-
说得挺好旳，我也曾经是小白。我也崇尚简单至上。拿来就用。
-
但人不可能永远是小白啊。人总会长大的，会更深入了解。然后变成大白，尝试创作创造。
-
我在尝试的时候，我也是出于需求，以及提高效率，提高能力的。但在H5游戏圈这类文章很少，Unity的更多。所以我就想将自己的经验和成果分享出来，给大家参考，交流。
-
变成大白的小白们创作创造的东西，封装好了，给下一代小白。
-
而我的框架，就是作为小白的我成长的成果，也可以给大家一个参考。
-
大家都可以用我的框架简单封装一下或者参考我的思路自己造个轮子。
个人技术积累，个人技术中台。
公司技术积累，公司技术中台搭建。
这是我的设想。
小公司，也可以做积累，积累多了，不就成长了吗？
神仙打架……，那像我这种毕业到现在两年多都是自己写的，没接触过任何公司用的所谓的“框架”的，请问还有救吗？？？？
道理是这个道理，但是小公司敢于搭建维护自己的框架的还是少，老板家里肯定有矿的那种。以前进过一个小公司，自己花三个月搭了个框架，后续也没人维护，都只拿来用。因为框架这玩意必然掌握在公司核心人物手上，而小公司，这种核心人物几乎没有。除非老板就是技术自己来搭来维护还差不多。
所以来一起交流学习啊，等积累到一定程度，有底气了。就可以拿出来用
同是菜鸟请多关照
2.4以后都已经支持AB包了，写好了AssetsManager，一样解决问题，跟框架没啥关系。我觉得通用框架设计本身就是个悖论，最适合的还是工具集，脚手架，颗粒度足够细，足够灵活。
1赞
我回复错人了 哈哈哈
关于ABundle不能使用主包单例那个，是我说错了。抱歉哈
用工具集好还是用框架好，是个人的喜好和需求。
工具集更加确定，拿来就用，可定制性弱些。
而通用框架，使用前需要做些定制，但可定制性高，适应更多不确定情况，不同项目。
其实工具集也是框架，只不过是更确定的框架，带着约定和规范
好吧，希望你这个能做的更好吧，不要像之前的几个框架，都无疾而终了
一样一样，啥时候请大佬多多指教
这个框架会一直维护吗？
-
我游戏开发生涯结束，或者我挂掉可能就不维护了
-
如果有看我的前几篇文章，可能就会知道，这个框架的起源，以及它的定位。
-
个人的技术成长是永不停息的
- 而这个框架是我个人技术成长的成果，随着我的技术成长而成长
-
大部分库是写得差不多了，就差尽可能多的测试和整理
- 这也是对我这一年的自我梳理
- 整好了就发，可以关注一下，期待一下
-
为什么写通用呢？
- 工作中能用（做laya项目）
- 私底下在Cocos也能用
- 而且能够保持一致的编码体验，不至于分裂
- 我还有头发但同时维护多个库就已经够多了，还要维护两套，那就受不了了
-
还有一个很重要的
- 非常感谢各位能够提出自己的观点以及指教
- 让我受益匪浅
- 这种氛围非常好，也是我维护的动力之一
-
请大家多多支持
，多多指教
赞！！
！
赞同，见过很多框架一大堆定义和依赖，结果每次加个小功能，还得改框架，对于业务实现层非常不友好，本来我只想知道是调用哪个模块下的哪个方法就行了，结果给我整一大堆结构，让我在好几个文件里面补充定义，我还得问，对方还得一脸不屑的给我说明，最后框架不支持，还觉得是我坑他
我不知道真正的框架是什么样的，我就按着自己这两年来的习惯，封装了这么几个东西：
1· 一个管理音效播放的
2·然后一个管理广告的
3·一个管理弹窗类资源的
4·一个管理一下小item的
5·一个消息管理的
6·一个管理数据的
7·一些常用的工具类函数
然后就是看项目需要整一些动态资源的管理的等等
这样我就觉得很爽了，我自己做项目的时候，就基本可以做到单纯面向业务需求开发了，当然我是做小游戏。
每次看到论坛里，各位大佬在讨论“框架”这个话题的时候都非常关注，希望自己能学到好东西。
看来还得以后有机会接触大一点的项目的时候才好深入学习这一知识！
1赞
其实框架也不是什么高大上的。
你所做的其实也是一个框架。
第一篇文章，也说了：框架是封装部分通用能力供业务层使用，起到支撑业务开发的作用。
互相学习~
mark!
我比较赞同你的观点