我的2018年工作回顾
发表于2019-01-26
这是第22篇，与游戏开发不是特别有关的文章。
因为这是一篇年度工作回顾(总结)。不知为何写的时候脑子里总浮现出自己泪眼婆娑的看着渐行渐远的2018年的背影，一遍跪着喊着“大爷别走啊...再玩会儿啊”的画面。
| 前言
运气很好。今年有幸完整参与了一个项目从开发、测试到正式上线；从版本不稳定、Bug频发、更新混乱到版本稳定、开发节奏稳健、版本更新按部就班变化的全部过程。
今年也是第一次承担主程工作，引导着团队不断的跳坑，又不断的从坑里爬出来奔下一个坑去...周而复始循环往复的一年，好在最后都爬出来了。
下面就挑这一年来主要参与的、较为重要的事情做个总结。
| 版本控制
我们使用svn来控制版本更新，以下三个分支是较常用且重要的分支。
1、主(开发)分支：大多数团队成员工作时使用的分支。
2、版本分支：项目进行大版本更新时从开发分支Copy出来的分支，也是下一个客户端热更新版本的母分支；本文提及的更新都是指在一个大版本号下的小版本更新。
3、线上版本备份分支：一个小版本更新发布后的备份分支，用于修复线上紧急问题。
| 规范版本更新流程
1、每个更新周期开始时，PM会将这个更新期上线的功能、优化及Bug修复需求列在更新计划中，并确定版本号。
2、程序、策划、美术及特效的工作分配后，相关人员会围绕这些目标推进工作进度，并将工作成果提交至主(开发)分支上。
3、当一个任务完成后，测试同学会在内网测试服进行测试。
4、测试通过后的任务将进入待Merge状态。测试同学会根据测试进度及测试压力挑选任务通知任务负责人将于该任务有关的提交Merge到版本分支上，准备进行外网环境测试。
5、通过外网测试后的任务将安静的躺在待发布区，等待最终一起发布到正式服。
6、到了计划更新时间节点时，PM会与程序、策划、美术的负责人进行最后一次更新内容的确认，确认通过后所有待发布区内的更新内容将被发布至正式服，与玩家见面。
7、一次正式服的发布结束后，版本的管理负责人会将当前版本分支的状态备份下来，用作下个更新周期内线上出现紧急状况的修复分支。
版本上更新上线流程图
| 版本更新的节奏
项目上线后团队主要维护两个地区的版本更新工作。由于地区内容差异不大，我们没有为两个地区单独创建分支，而是将两个地区分为一主要地区和一个次要地区，使用一个分支进行错时更新：次要地区的更新总是慢与主要地区一个版本。
双地区版本更新顺序
| 配置数据的更新
配置数据是游戏的灵魂。但在项目前期，我们遇到了配置更新易出错的问题，除了配置的编辑工具自身的问题外，前后端使用的配置不统一，也会导致问题的发生，而且还难以定位。
我们使用xlsx文件来编辑配置表，再通过vba分别生成前后端各自所需的配置文件。但在这个环节中，经常出现因为人为疏忽少导出或少提交了一端的配置，最终导致前后端联机时出现异常。
不仅如此，每次准备做外网更新时，配置的负责人还需要认真检查要被打到更新包中的配置，工作量繁重，易出错，代价大。
解决方法
1、为每套配置增加编号，并在客户端显示出服务器和客户端分别使用的配置编号，用作快速检验两端的配置是否搭配。
2、修改配置生成工具，每次将配置直接导出到带编号的文件夹中，每套配置采用不同编号，彼此独立。
3、重构打更新包的流程，将配置从热更资源中独立出来，每次更新前、后端都需要策划给定一个配置编号，打包工具根据这个编号挑选配置加入到热更资源中，避免了发生人为错误的机会。
配置更新流程
| 客户端的热更新
客户端打热更新包时，会将版本分支下的资源、脚本、协议，连同本次更新的配置编号所对应的配置文件，通过一个BuildPipline生成一批assetBundle文件，并且将这批assetBundle文件的信息（如文件路径、文件md5码、size）保存在一张fileList.txt上。
热更新文件的简要组成
| 客户端启动时更新的流程
1、客户端启动时，首先需要向服务器请求一个配置列表，这个列表包含了热更资源包的地址，各项游戏启动时的开关等。
2、客户端拿到这个配置列表后，会解析列表并将其按照key-val形式保存起来，方便游戏运行时随时访问。
3、根据配置列表中记录的热更资源包地址，客户端可以找到这个资源包的文件列表，并根据文件列表中的信息判断哪些资源需要被下载，哪些可以跳过。当然，配置列表也可以通过设置客户端的热更下载开关为关闭，而让客户端跳过热更环节直接启动。
4、当客户端下载完热更资源，并且通过了文件校验后，就可以开始后面的登录流程了。
客户端启动流程
| 资源管理
评价资源管理的效果可以从以下几个方面来看：
1、打入包体后的大小
避免重复资源的导入；不再使用的资源及时从工程中删除；导入后的资源选择合适的品质及压缩方式，是资源管理的第一步。
2、玩家热更时的下载量
选择尽量好的AssetBundle策略。如果一个图集是一个Bundle文件，一个功能对应一个图集，尽量保证添加一个功能，玩家热更时只需下载少量的更新文件。
3、玩家加载资源后对内存的占用
纹理、模型、音效等资源在导入时的设置不同会对CPU、GPU及内存带来不同程度的影响。但是这块内容较多，目前没有整理好，后面会抽出一篇博客的时间专门做这块内容的总结。
4、资源不再使用时的释放
不再使用的资源应该启动释放流程，但并非都要立即释放，可以为资源添加缓存策略：如立即释放、常驻内存、存入临时缓存池。之前一篇记录界面管理器的文章中提过这种方法，只是对游戏整体的资源管理会更加复杂，会放到资源管理器中统一处理，后面会抽出一篇博客的时间专门做资源管理器的总结。
| 项目优化
项目刚开始测试时，收到了一些关于游戏卡顿的反馈，后面经过一系列的调整，收到了一些成效。与资源管理相同，优化也是一个很大的主题，这里只对大致的思路做总结。
1、使用第三方性能测试工具（如WeTest），大致确定项目运行时的卡顿点，找到卡顿规律，尽量锁定到功能模块上。
2、根据卡顿点的严重程度，及功能模块的重要程度（玩家使用频次），排出优化的优先级。
3、使用编辑器或真机，配合Unity自带的Profiler，按照优先级高低，反复使用卡顿模块，观察CPU、渲染及内存使用的波形图，并在波形图的高点停留查看详细情况。
由于参与的项目是一个2D游戏，所以渲染方面出现的问题不多，大多数卡顿的原因是CPU的过于集中使用及内存没有及时释放。
前者可以通过CPU在模块打开或某操作被执行时瞬间拉起的波峰发现，后者通过反复进行相同操作后，内存没有被回收而定位。
Unity编辑器自带的Profiler
CPU使用的问题主要发生在复杂的界面被打开、带有复杂结构的滑动列表被加载等情况时发生。解决的基本原则是尽量简化Prefab结构，如果无法简化则考虑分帧加载。如将复杂的界面进行拆分，从打开时加载全部，变为只加载可见部分，不可见的部分不随主Prefab同时加载，改为点击加载或延迟加载。
MemoryProfiler插件
内存回收的问题可通过MemoryProfiler更直观的定位，由于我们的资源管理器使用了绑定资源请求者的使用方式，当一个资源没有请求者时会自动开启释放流程，因此由于资源问题导致的内存上升，可以通过资源管理器准确定位到的资源的请求者，找到没有及时释放的原因。
| Jenkins的使用
我们使用Jenkins来管理诸如刷新测试环境、打热更资源包、打安装包、上传服务器等工作。
起初我将工作流里的每个环节拆开，开发成为Jenkins上的一些小功能，在前期需要进行打包或更新时，要按照一定顺序执行一遍Jenkins上的功能。
比如更新线上，需要先使用打热更包的功能，然后上传到对应的服务器，最后再刷新CDN。
之所以选择这种复杂的方式，是因为自己迷信“如果出现了特殊状况，可以用这些独立的功能解决各种问题”。
起初由我个人使用时，虽然需要进行很多操作，但问题不大，一边使用一边在心里过一遍流程即可。但有一次本人事假，请同事代为更新线上，尽管做了交接，但他还是被过多的参数，复杂的使用方法和严格的执行顺序搞得晕头转向。不仅花了几个小时才完成了本来只需要10几分钟的更新，还弄出了线上错误……
事后，我们将功能简化，全部常用功能都做成了一键制，而且只使用很少的参数控制，方便易用，做到了八十老妪亦可操作...
至此，才深刻的明白大道至简的道理，原来工具的易用性才是最关键的。因为无论谁来使用，哪怕是开发者自己，也会有状态不好、精神不集中的情况，复杂的工具只会增加出错的机会，应该把精力用在更重要的事情上，而不是操作这些工具上。而一开始认为的所谓特殊状况，也基本没有出现过……
| 数据的收集、整理及分析
因为以前从事过数据分析的工作，所以本身是有数据情结的。
运营方面的数据，公司已经有成型的收集、整理及分析系统支持。而游戏数值方面的工具，需要项目组自己开发。
我一直认为给策划组提供一套易于操作的数值验算工具都是十分必要的。所以在今年的下半年，我们尝试性的为策划设计出一套战斗模拟分析工具。
为了快速让工具落地并投入使用，我们使用excel + vba的方式来创建战斗阵容的配置器，尽管界面很粗糙，但是支持快速配置并模拟战斗；战斗详情及战斗录像一键导出；战斗结果数据一键整理及透视...
工具可以快速模拟数百场战斗，并生成不同维度、细节程度的战斗数据，利用excel自带的数据透视功能，可以轻松、直观的看出技能、装备、天赋、阵容搭配等对于战斗结果的影响。这比使用编辑器或真机一遍一遍的进行战斗，实在是方便了太多...
尽管excel在处理千、万场战斗细节数据时很吃力；战斗数值平衡也仅是游戏数值的一小部分；影响战斗数值平衡的因素也不仅是一些简单维度的组合。但这次尝试可以被认为是成功的，因为它是一个成熟团队必备工具箱中的一员，而建设这种有反馈的闭环工具链是十分必要的。至于什么叫做“有反馈的闭环工具链”，我也不知道，随口一说，听起来有点档次就对了。
果然，数值策划在使用过这套工具后，称赞道：还不错啊！
然后他们就没有再使用了...
| 2018年的没有做完(好)的一些事
1、没有找到一套找到好的资源管理策略
对界面使用的图集缺乏管理，只是使用了SpritePacker的基础功能，没有在图集如何规划及分配上投入过多精力，导致开发到后期，一些图集尺寸失控，追加新图时更新成本很大。
2、对于资源的导入缺乏控制，欠缺规范以及检查工具
部分资源类型在导入项目时没有严格控制，缺乏定期检查资源健康状况的辅助工具，上线后发现这些问题时，补救成本很高。
...等等。
| 2019年计划要做的一些事
1、初步建立一套通用的资源管理工作流及对应的工具链
开始建立一套通用、可迭代的资源管理系统。目前来看，应包含从资源导入时对导入参数的统一设置；导入后的检查；运行时的监控；不定期对工程整体资源健康状况作出报告；以及生成资源入Bundle包、入Zip的分配方案等。
2、建立一套战斗数据的配置、模拟、收集、分析工具链
试着为自己的Demo工程建立一套数值管理工具，希望可以将以前从事数据分析工作时的工作经验以及思路带入到游戏开发里。
| 写在最后
很久以前在机关工作过两年，从那以后每年都要做一个年终总结。近两年转行做程序员，丢掉了很多好习惯，唯独做总结这事儿，始终坚持。
毕竟一年就一次么，要是频率太高，估计也放弃了。
不同的是，以前的总结只是为了给上级看、给领导瞧，暗示自己一年做了如何如何多的事情，有多么多么辛苦和不容易；如今年龄大了，成熟了，懂事了，做事情也更务实起来，做总结的目的和心态也不再那么幼稚了。
现在的总结是要做给所有人看的，只让领导看见怎么够呢？
不仅要带着昭告天下的心态做，做了还要发出来才行啊！
无论2018年自己是否及格，都已经成为过去。
2019年，仍会全力以赴，我必会做的更好
吧...
慢走，2018年。