一、功能不复杂，整体结构简单，类也不多，基础框架也是自研的；
二、图片资源不多，两个plist图集，合计1000K左右，包括分包后的音频文件，都采用首屏进度条预加载的方式，小项目，这么干肯定也没啥问题，主要是方便，后期编码想要显示啥，随便用，不用担心资源加载的问题；
三、界面UI我很少使用预制体，多了个布局描述文件，每个预制体还得加载布局描述文件，个人感觉是影响显示效率和性能的，经过自身验证也的确如此，所以绝大部分界面UI我都是手鲁硬编码的，这个习惯也可能是受flash（非Flex）、LibGDX、Egret的影响，坏处嘛，很明显，开发效率低下，好处嘛，也很明显，程序执行效率高，编码灵活，Node层级嵌套可控；
四、界面UI更新，我习惯在帧频函数update中处理，类似如下图片写法：
这是最简单的重绘机制，也就是说，不管内容需求如何变化，重绘刷新也只会在帧频函数中处理一次，这种机制其实也是各种语言底层图形绘制的核心理念。
五、我观看过一些第三方的开源cocos creator框架，特别是UI层面，看到很多UI组件基类各种show、hide的，也就是说把UI界面的显示和关闭写在UI本身，我个人认为这样显得杂乱无章，我的做法是通过事件总线派发显示和关闭相关事件统一处理，如图所示：
至于在哪里统一处理，就如下图：
Main类，是一个常驻节点组件，其update中同时也处理着各种队列化异步事件（Message）；
六、看客们可能也注意到这种写法
{ path: “ab:audios”, dir: true, desc: “正在加载音频文件” },
{ path: “images”, dir: true, desc: “正在加载游戏必要资源” }
这是自定义资源加载方式，主要实现就是AssetLoader这个类，ab:前缀是加载分包资源，其它则是resources资源，这么实现是为了实现加载进度的统一显示。
再回头介绍下上面一中提到的基础框架，还得益于我的js、flash、libGDX、Egret、Unity（懂点皮毛）、java后端相关经验，有一些显著特点：
1、完善的全局事件总线，魔改pureMVC而来，所有事件派发需要sendMessage(new Message(…))，参数是个Message对象是因为可以灵活适配对象池，也能方便扩展获取事件执行结果回调。
2、提供“完美”的手动解析数值表能力，可解析各种复杂的数值表字段，已实现各种数值表之间的关联解析，比如A表引用了B表内容，在解析A表时再去解析B表，并能把B表内容映射到A表中；任何数值表是按需解析的，暂未用到的数值表不被解析，并压缩缓存待解析内容，解析完成后丢弃对应的缓存，能显著减少内存开销。
好了，暂时就说这么多，请大家后续多多关注我的个人小项目《生命保卫战》！感谢大家的观看！
