基于Egret的微信小游戏H5项目总结

 

• H5
  • puremvc框架

View 与 Mediator 组合模式

View 上Button Image scrollView的事件在Mediator中实现，View仅仅是皮肤、是界面。

修改界面布局，不需要改动Mediator。  Mediator之间是策略模式 比如商店，活动等。基础操作不变，都有购买，都有礼包列表，都有限购次数，都有活动持续事件。变化的是档位，变化的是货币单位，变化的是礼包内容。不同Mediator对应不同的策略。  

Module 与 Mediator 观察者模式 比如升级操作，充值操作，需要通知Mediator做界面上的刷新。  Module封装了协议操作比如升级，封装了业务逻辑，比如是否可升级，这进一步可封装为 升级材料是否足够，是否达到最大Level。这些条件的封装集中在Module可以被重用，比如一步操作需要检测是否可升级，红点逻辑检测也需要判断是否可升级。 

puremvc相较于传统mvc的优点： 对 M V C 的管理 MVC分别是一个单例，facade统一一套接口，内部是三个核心类接口的实现。

facade：分散在源码中的类/结构及方法重新组合，形成新的、统一的接口，供上层应用使用。 ​ ​

• 项目优化

启动页：

在引擎初始化，和游戏第一个场景加载出来之前会有黑屏，此时可以在project中使用原生js加载出第一页的资源，避免等待黑屏。

​ ​登陆界面布局代码实现：

​由于皮肤文件是打包在一个文件下的，要等到下载完再显示登陆界面等待时间太久，优化方案是手写登陆界面的代码布局。

  ​loading时动态加载所需资源：

根据角色身上的数据动态加载所需的序列帧、时装、装备、称号等资源，剩余的可进到主场景再后台静默加载。  ​ ​ ​

览器调试面板查看heap快照分析累积对象名称。 ​一般较多的是红点对象，特效，定时器。排查他们生命周期是否成对出现，避免内存泄漏。

​ 重载资源加载和移除函数，对资源进行引用计数。 ​

背景图片尽量复用且使用jpg格式。 ​ 两个图片在同一个图集中，但在两个图片中间插入了一个文本组件，这样合批就被打断。 分组摆放,批次渲染，降低DrawCall。 ​

• 制定美术龙骨文件规范，实现换装功能。

派活，下载demo演示，熟悉概念，理解换装关键逻辑。

根据demo换装逻辑制定规范，比如关键挂点命名，模型文件命名。 根据实际需要，和美术面对面讨论，解决特殊需求，比如拇指握剑的层级关系。比如双手武器的实现。比如帽子的前后层关系。 ​

后期维护期间发现每半个月都要导入一批外包给来的时装，有时候有些命名不规范，挂点缺失。等到项目中展示预览太慢了，于是写了个小脚本检查每种文件的命名规范。

换装逻辑以及资源检查代码在此 ：https://github.com/yhhwatl/avatar-dragon.git

• 热更新

审核版： 一次版本发布流程如下：center地址附带本次升级版本号：111，服务器后台设置正式服版本号110，111 > 110 111作为审核版本 连接到审核服。

版本对比，比本地版本号大则清除已有缓存，重新缓存指定文件夹；版本号一致不处理。 ​

缓存：

注册加载资源的处理器 RES.processor.map("image", processor);根据资源类型监听加载，在此拦截做一些写入读取缓存等IO操作， 给缓存的资源做标示，下次根据标示觉得是直接走http加载还是读取缓存。

一般缓存common文件夹的通用资源，缓存基础数据表，缓存常用背景音乐和音效。

​ 资源版本号：

​由于微信审核有时间周期，修复更新一些非代码资源时避免走审核流程可以给资源设置版本号，资源在CDN上按版本号存放。由服务器后台指定前端加载本次资源。

• 游戏红点管理

对于功能堆叠的养成游戏来说，多层目录的红点管理是有个不小的任务量，比如人物-神器-传承-升级/进阶 材料足够可以升级时 升级按钮的红点状态会向上传递给传承，同理传承按钮的红点传递给神器，一直到人物。

这四层四个按钮都需要显示红点。这种层层传递的逻辑单一固定，层次清晰，可以使用工具生成。需要补充的是最内层的升级操作。 另外和升级同层次的有进阶，有分解，有强化等，这几个只要有一个有红点外部传承需要红点，这种情况可以用||操作连接后赋值给传承。

基于这种思想指导，我写了一个脚本用来实现游戏内的红点传递框架。 https://github.com/yhhwatl/redPoint.git

 

写完发现之前总结过这个 https://blog.csdn.net/yhhwatl/article/details/100174329

• 战斗实现细节
  待补充