|
|
GameRes游资网授权发布 文 / 安柏霖
“我不是什么伟大的程序员，我只是一个有着很多好习惯的程序员”—-Kent Beck
随着项目的上线，团队开始进入另外一种节奏，每次的提交不再是小打小闹的玩一玩，而是在一周之后直接面向玩家。
经历了早期的版本不稳定，然后进入了平稳期，crash率持续降低，中间夹杂着波动。对期间发生的问题做总结。
一、纪律性的重要性
纪律性这个说法，早先是在starcraft比赛中常常听到，典型的案例就是在开局没有做到充分侦查的时候，在家里关键位置上放上防空，就可以良好的防御各种阴招。
比赛中的优秀选手，在这方面都做得非常之好，星际1时代的最终兵器flash尤其如此，而在多年的项目经验以及游戏经验看来，能把这些纪律性的东西做好，真的很难。
换到项目里面其实就是针对一些简单的问题，通过流程，既定的做法，即可将绝大多数的简单问题击杀，避免导致严重的后果。
不做好纪律性太可惜
简单的问题和复杂的问题一样，都可以带来惊人的破坏力–比如让crash率翻倍。
如同2次罚球和暴扣一样，都是2分。
但是让人很遗憾的是：这个分不应该丢。
这些问题常常是，不需要高深的理论，牛逼算法，不需要资深的积累，是大部分人都可以做好的。
1000人同屏对战这些问题，搞不定也就罢了，但是在不该丢分的地方丢分，去浪费生命处理这种bug，what the fuck！
纪律性的难点1–它的简单
这个是自打学生时代起就常常遇到的情况，在一个简单的问题上栽跟头，我们耸耸肩，哦，这就是一个疏忽，无所谓的。。。
我们一般来说会对挑战智商的问题讨论个不停，xx架构，xx算法都很来劲的，但是对于这样一个小疏忽，谁在意呢？
但其实它就等同于高考中迅速准确地扫灭占比70%的简单题而不出错，在比赛中罚中所有的球，能很好的做到这一点，都是非常牛逼的事情。
以不犯错误甚至无懈可击的代码为目标，绝对够挑战。
纪律性的难点2–需要大量的积累
编程中，扫灭简单问题这一点的核心在我看来，就是积累大量的“危险模式识别”，在扫过一大片代码的时候，能嗅到危险的味道，比如：
- short simpleArr[16];
- ...
- for(auto it=simpleVec.begin();it!=simpleVec.end();++it)
- {
- if(it->ptr==NULL)
- {
- simpleVec.erase(it);
- }
- else
- {
- memcpy(it->ptr,simpleArr, sizeof(short)*16);
- }
- }
这其中的==判断，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，于是就乱试好了，比如把这几个选项开开关关 。
然后就好了。
相关阅读：我的手游项目总结
|
|
发表于 2016-4-27 15:54:55
