“我不是什么偉大的程序員，我只是一個有著很多好習慣的程序員”—-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，于是就亂試好了，比如把這幾個選項開開關關 。
?

然后就好了。

總結

以上是生活随笔為你收集整理的游戏运营期间我的项目开发经验总结——纪律性和卡顿处理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。