游戏运营期间我的项目开发经验总结——纪律性和卡顿处理

“我不是什么伟大的程序员，我只是一个有着很多好习惯的程序员”—-Kent Beck

随着项目的上线，团队开始进入另外一种节奏，每次的提交不再是小打小闹的玩一玩，而是在一周之后直接面向玩家。

经历了早期的版本不稳定，然后进入了平稳期，crash率持续降低，中间夹杂着波动。对期间发生的问题做总结。

一、纪律性的重要性
 

纪律性这个说法，早先是在starcraft比赛中常常听到，典型的案例就是在开局没有做到充分侦查的时候，在家里关键位置上放上防空，就可以良好的防御各种阴招。

比赛中的优秀选手，在这方面都做得非常之好，星际1时代的最终兵器flash尤其如此，而在多年的项目经验以及游戏经验看来，能把这些纪律性的东西做好，真的很难。

换到项目里面其实就是针对一些简单的问题，通过流程，既定的做法，即可将绝大多数的简单问题击杀，避免导致严重的后果。

不做好纪律性太可惜

简单的问题和复杂的问题一样，都可以带来惊人的破坏力–比如让crash率翻倍。

如同2次罚球和暴扣一样，都是2分。

但是让人很遗憾的是：这个分不应该丢。

这些问题常常是，不需要高深的理论，牛逼算法，不需要资深的积累，是大部分人都可以做好的。

1000人同屏对战这些问题，搞不定也就罢了，但是在不该丢分的地方丢分，去浪费生命处理这种bug，what the fuck！

纪律性的难点1–它的简单

这个是自打学生时代起就常常遇到的情况，在一个简单的问题上栽跟头，我们耸耸肩，哦，这就是一个疏忽，无所谓的。。。

我们一般来说会对挑战智商的问题讨论个不停，xx架构，xx算法都很来劲的，但是对于这样一个小疏忽，谁在意呢？

但其实它就等同于高考中迅速准确地扫灭占比70%的简单题而不出错，在比赛中罚中所有的球，能很好的做到这一点，都是非常牛逼的事情。

以不犯错误甚至无懈可击的代码为目标，绝对够挑战。

纪律性的难点2–需要大量的积累

编程中，扫灭简单问题这一点的核心在我看来，就是积累大量的“危险模式识别”，在扫过一大片代码的时候，能嗅到危险的味道，比如：
 

1. short simpleArr[16];
2. ...
3. for(auto it=simpleVec.begin();it!=simpleVec.end();++it)
4. {
5.     if(it->ptr==NULL)
6.     {
7.         simpleVec.erase(it);
8.     }
9.     else
10.     {
11.         memcpy(it->ptr,simpleArr, sizeof(short)*16);
12.     }
13. }

复制代码

这其中的==判断，erase，memcpy应该在眼睛里自动高亮起来，识别出这些都是容易出现问题的地方。

这就是在长年累月的实践中，学习中，在每一个错误中去学习和积累。

sum：

简单问题的处理并不容易，用心的在意，用心的积累，保持纪律性，方能保持不被其所伤害。

二、卡顿处理--GPUView
 

开发期间的卡顿处理的方法比较多，可以打log等方法。

GPUView

在运营期间就是GPUView就是逆天的给力存在。

GPUView早先是一个微软实习生开发的东东（好逆天的实习生），以单独的方式来发布，后来集成到windows sdk中来，本blog上面这里有一些记录。

而且在后续GPUView依旧保持着发展，功能也越发好用了，连intel的gpa也在底层使用这个机制。

GPUView可以做的事情很多，其原理就是能够抓取一段时间的windows底层的消息（几乎所有你需要的消息），gpu driver，lock，context switch。。。应有尽有。这部分的抓取的applicaiton叫xperf.exe，看的时候是GPUView.exe，当然整个过程我们就简称GPUView了。

而且很棒的一点就是，windows自己会把这些消息缓存一段时间，然后在你抓取的时候，会把之前一段时间的信息拿过来，这对于抓取卡顿太妙了（其余的办法，你发现卡顿，但是这一帧已经过去了，你只能望卡兴叹）。

ps；我老婆认为这个软件太难看，我个人倒是挺喜欢这个hardcore的感觉，游戏账号买号和windbg一样，解决问题简洁犀利。

GPUView使用

实际命令行什么的还是有点麻烦，抓取时候可以使用写好的一些GUI工具，在win10上面是这里。

自己随便运行一个程序什么的，然后点击抓取，可以获得一个etl文件。

这里就举一个例子来说明过程：

1，有玩家反映在开封主城附件的豪宅区会有卡顿，于是qq上联系玩家，远程一下，收集到卡顿的etl文件。

2，然后使用GPUView.exe打开这个文件，遍历整个时间段里会发现有一个地方系统处于停滞：有近700ms都没有提交任何GPU命令

3，进一步zoom in，会看见主线程这里在忙，其他都在等，点击其中一个事件（这个是系统以一定间隔来采集执行的信息，点开可以看到进一步的callstack信息）
 

4，选择主线程，只选择Stack Walk，就可以看到这里的callstack了：
 

5，这个callstack，在自己有pdb的情况下就可以resolve出来，在gpuview的symbol path那里进行设置，就能看到具体的callstack了：
 

这时候就知道问题是出在什么地方了。


symbol解析问题处理

GPUView解析不出symbol的问题是经常出现的。

第一步可以做一些诊断

DBGHELP_DBGOUT = 1

DBGHELP_LOG = C:\dbghelp.log

通过这两个环境变量（就是系统环境变量的设置方法）可以把load symbol的过程log出来，实际windbg等一些系统工具都可以用这个办法诊断symbol不能resolve的问题。

通过log可以定位问题，比如我之前的问题就是改了symbol path，但是没有生效，还是到老的地方去找。

可能是gpuview在symbol path改变的生效方面的bug，于是就乱试好了，比如把这几个选项开开关关 。
 

然后就好了。