文/jacksonqian

节拍巨匠是一款国民级的音乐游戏，写这篇文章的时候刚好是节拍巨匠三周年生日，2012年5月25日节拍巨匠初次公布，就吸引了浩繁 浩大的玩家，时隔一年多，节拍巨匠作为第三个登岸微信平台的腾讯自研游戏，刚上线就积存了非常多的用户。随着用户数的不休剧增，再加上当初手机游戏开发缺乏成熟，一些标题问题隐患也在上线后慢慢的流露出来了。

节拍巨匠是款国民级的音乐游戏，所以最早在客户端这一侧对它性能基线就设置的非常低，也就是要让游戏能够运行在各种设备上，不管是高端的还是低端的，需要担保在低端机上玩也不会呈现过量的解体现象。

别的客户端这一侧还得担保游戏的核心体验（也就是打歌）必需流利，最关键的节拍巨匠的核心玩法是尽对不克不及呈现有帧频不不乱的现象，也就是所谓的“忽然卡一下”，因为只有一卡，对玩家的这种极致体验会带来非常不爽的感觉。颠末一些测试，假如游戏帧速到了50以下，就会影响到核心体验，它不像其他类型的游戏，比如SLG这品种型的，旁边卡一下不会有什么大碍。

当初上线一段时间后，节拍巨匠呈现了一个最严峻的标题问题，就是内存，游戏启动以后常驻内存非常高，内存有标题问题，会带来各种隐患，比如会增加 增加crash率，会影响到CPU的运行效率等等。颠末开发的一系列排查，定位到一块地方，就是UI贴图资源占用过量。

节拍巨匠的UI贴图资源主要用在以下几个地方：

• UI显示，也就是平常看到的按钮、面板等图片资源；

• 打歌时候的Note资源，特效资源等；

按照测试，发明内存占用情况如下表：

这样看，还可能看不出什么标题问题，继续跟踪，发明在启动游戏后，进进主界面，发明内存就有100M安排，然后不停的切换界面，内存几乎坚持不变，然后开始打歌游戏，内存会略有上涨，然后再退出打歌，发明内存却没有什么改变。

节拍巨匠的UI是环形布局的，也就是每一个UI都是独占的，当从这个UI切换到别的一个UI，之前阿谁界面其实便可以从内存中销毁的，而从上面的测试成效来看，貌似是没有销毁这一回事，一上来内存就偏大，界面切换内存也不会有啥变化。别的我们也寻到了今朝UI图集的组织关系，如下图所示：

从上面可以看出，每一个UI引用了多张贴图，也就是UI跟贴图之间没有任何的对应关系，乱糟糟的没有规划可言。所以这个也印证了上面的内存现象。

今朝这种UI组织架构会带来很严峻标题问题：

• 后续开发会有隐患，内存得不到操作，增加 增加crash率，节拍巨匠是用户数非常多的项目，低端机有风险，对产品本身损害很大

• 引擎不成熟，没考虑图集开释，UI关闭的时候没有开释贴图的逻辑；

• 东西端操作繁琐UI；

• UI引用关系太复杂了，已操作不下往了，之前都是美术随便照一张大图把小图放进往，手工切割sprite也非常不精确，有误差。

针对上面的标题问题，主要从以下几个方面来解决：

• 从新整理 收拾所有的Atlas图集，每一个UI只有单一的图集与之对应；

• 整理 收拾出公共的Atlas图集；

• 编削所有的UI文件，将里面的sprite重定向到最新的sprite；

具体的步调如下：

1. 切割原始的大贴图，将它们拆分成每张小图，其实这些小图就是美术当时做出来的；

2. 扫描原始的UI文件，将每一个UI用到的sprite，也就是小图，都搜集到对应的文件夹下，也就是比如背包UI上用到的各张小图都回类到背包UI的文件夹下，这样就生成了多个名目，每一个名目是对应的UI，名目下面都是下图；

3. 扫描用到的公共sprite小图，将被UI用到了N（这个数字要反复测试调整）次的小图搜集起来，把他们定义成公共Atlas图集；

4. 将上面的各个UI名目，和公共图集名目，从新打包成大图，生成最新的Atlas配置文件；

5. 将原始的UI文件（这里的UI文件指的是UI的配置文件）里使用到的sprite配置重定向到最新的Atlas配置下的sprite。

通过上面步调，就把原先的贴图资源从新拆分合并，原先的UI配置从新统一编削，最终到达了这样的效果：

也就是首先每一个Atlas配置只会对应一张贴图，每一个UI只会使用本身的Atlas贴图和公共贴图，所以理论上，在某个界面下，内存里的UI贴图资源最多只有两张1024*1024的图片，这样来看相对之前，进进一个UI，要加载10来张贴图，这个打算是必需的也是必定的。

这上面都是用东西措置惩处的，在项目代码里，也需要做一些措置惩处，这里就不开展说了。通过上面的编削，主要达成了几个目的：

• 优化了美术同学的工作流程，美术同学只要要给程序这里出好每一个小图便可以，不需要再往待遇的拼大图和人工划分sprite，对，你没看错，之前的大图不是用东西来打包的，是本身拼的，sprite信息也是本身手工切割的，下图所示：

里面的小矩形区域，是待遇画的！！！！

规范了程序开发的调用规范，每一个UI的加载开释都通过断言往约束，确保 发作一些不消要的毛病 过错；

确保主玩法之外的独立场景，只有1-2张贴图资源，主玩法有6-7张贴图资源；

最后看下优化后的成效：

也许许多人看到这里会觉得这种打算应该今朝在每一个项目都是这么用的，今朝长短常普及的做法，贴图资源用东西打包啊，每一个UI由固定的独立的贴图往对应啊，但是因为节拍巨匠项目起步非常早，在手游范畴这块摸索了很久，并且当初因为东西引擎端的不成熟，然后再加上待遇的一些不严谨，以致了到最后标题问题被放大，差点无法操作。这个优化工作前后做了三个礼拜安排，涉及到所有的UI文件、UI贴图，工作量还长短常大的，最后贴几张当时优化中的一些成果：

这是当初用东西扫描老UI的情况，是每一个UI涉及到的贴图情况，还是相当吓人的。

这是当初写的东西，看起来有点乱。