游戏加载优化
由于微信及H5版本的加载压力，以及游戏自身品质性能的提高，对游戏进行加载优化，优化方向为：合并api请求，合并json文件，整理资源组，合图组。删除废弃的加载项。
https请求：
1.部分功能在独带版已经废弃，或者暂不开启。可将这部分请求删除。
2.部分请求可以一次游戏仅请求一次，或者一段间隔后再次请求，原来支持这种设定，现在与6666合并冲突，调整下重新支持。
3.部分请求合并后，由于多个请求之间参数可能相同，所以将携带参数的请求没有合并到6666中，与服务端协调，合并到请求包中。
静态表及JSON：
1.部分功能在独带版已经废弃，或者暂不开启。可将这部分请求删除。比如敏感字校验
2.合并部分json进入config中，注意静态表本身有缓存机制，不要将频繁修改的静态表合到config中。避免单文件过大，也可以合并几个文件为一个configX,注意不要造成单场景加载量过大。config中现有的静态表也排查一遍，去掉无用和频繁修改的表。
3.删除静态表的废弃字段，及废弃数据。比如签到数据可以仅保留近2个月的数据，每次大更新修改一次。
4.场景移除时，释放该场景使用的静态表，下次使用时重新从缓存中获取（风险较高，暂不处理）。
图片，皮肤文件：
1.所有图片进行压缩，尤其是技术导出的位图文本，MC，合图文件。一定要压缩。
2.皮肤中不要有文本赋值，不要给组件属性赋默认值，非特殊情况不要指定字体。避免无意义的Group。（此项针对小游戏皮肤压缩，详细规则可参照小游戏皮肤优化建议）。
3.去掉图片同一次场景打开时，不会使用的资源赋值，如后宫背景的白天夜晚资源（代码动态指定），选秀的两人|三人模式（多状态控制）。这种情况在皮肤中不要给source赋值，在代码中动态指定即可。
4.将常用的样式封装成组件，多处复用。（有利于小游戏皮肤压缩，代码压缩）。
5.避免通用组件复杂化，应合理均衡多样化和拆分。（较为复杂，统一处理）。
6.纯色背景的九宫拉伸，减少合图体积。（需要美工少许协助）。
7.背景通用化，将背景固定为几个格式，技术和美工使用统一命名。避免资源重复，显示效果不统一。（需要美工大量协助）
8.数字位图文本通用化，预设多个数字文本，统一命名，指定使用，（由于异步加载，不建议合图，且需美工协助，实际意义不大，可延后处理）。
9.同一个图片，如果仅存在尺寸差异，可考虑使用一张大图进行放缩，但不建议放缩比例过大会影响效果和单场景的内存占用，常用的货币图标不建议进行放缩。
10.可明显划分区域的复杂背景，建议使用九宫拉伸，或者文件拆分。（需要美工协助，工作量大，延后处理）
11.SSbtton优化，分为底层背景+上层位图文本+右上角红点提示。点击可同步缩放。背景和位图文本均分样式进行预设，美工技术采用统一命名进行指定。（需要美工及大协助，工作量巨大，延后处理）
12.样式背景，可进行适当拆分，例如任务条目的背景。（需要美工的大量协助，且需要考虑美术效果，延后处理）
13.会同时使用的MC可以合并多个为同一个文件，减少请求数量。
资源组，合图组：
1.资源一定要配置预加载，便于使用和释放。
2.发布时一定要合图，合图后一定要压缩。MC，位图文本，龙骨资源不要进行合图。
3.public\preload中资源不要放置在任何资源组与合图组中，因此对public中的资源要严格校验是否通用。
4.alert中为次常用资源，请配置到需要的资源组中，以便于内存释放，但不要放入任何合图组中，以免造成过量加载。
5.通常一个目录下的所有资源应在同一个预加载资源组中，同一个合图组中。如不在同一个资源组中，请使用划分物理目录的形式进行区分。
6.由于合图应小于10241024，一个资源组 = m 合图组 + n 组内零散资源 + k alert资源。
7.由于合图是按照2次幂进行尺寸匹配，应避免合图后出现大量空白。
8.零散使用的资源不建议进行合图，避免占用过多内存，这样的资源应放置在base包中。
9.将稳定的零散资源，稳定的界面放置在base包中，利用缓存机制，减少加载数，和更新后由于回源造成的加载延时。
动态加载：
目前技术支持动态配置静态表，动态配置网络请求，动态配置资源组。开发根据情况在preloadtool和systemproxy中进行配置。
优化：
1.将动态配置方法均转移至systemproxy中，使加载逻辑与动态配置逻辑相分离。
2.暂不支持同一个场景的预加载中，相互依赖的网络请求进行动态配置。如活动数据。
如何识别是否需要优化：
0.可通过浏览器查看加载下来的文件的源目录，api请求的参数和返回数据。
1.检查加载下来的图片是否有重复，仅存在尺寸差异。
2.检查加载下来的资源是否都有使用。
3.检查是都加载了多个合图，通常一个场景仅有一个合图，多余的合图是否大部分资源都不在本场景中使用。
4.检查打开界面后，是否有图片延迟显示。
5.检查加载下来的静态表是否需要。（需要对项目和代码有一定的了解）。
6.检查反复进入一个场景请求的api是否有变化。部分请求是不需要每次进入游戏都进行发送的。（需要对项目和代码有一定的了解）。
7.检查反复打开一个界面，是否有内存占用的显著增长。（需要对内存监管有了解）