人物介紹：2003年開始接觸遊戲編程，2006年進入遊戲行業，2010年加入騰訊，先後參與多款UE3次世代PC端網絡遊戲的開發和預研，2013年初開始移動端3D網遊的研發,見證了天天飛車從萌芽到誕生及成長的整個過程，現為客戶端研發負責人。
序言：轉型手遊，問題比想象要複雜。一些問題是研發階段就能預見的，但是有些問題上線後才發現遠超出我們的想象。
從端遊轉型做手遊變化遠沒有想象簡單
可能和公司內很多手遊研發團隊一樣，我們也是從傳統PC端遊轉型做手遊的。 我們一度認為手遊研發會比較輕松，技術上跟端遊比起來相對容易， 人力上也不需要太多投入。但真正開始做之後才發現無論技術還是產品各方面遠沒有我們想象的簡單，好在我們的核心成員都有多年的端遊開發經曆，不光有相應的技術和經驗積累，還養成了一些好的工作習慣及方法，在遇到問題時能夠及時調整和靈活應對，我想這也是我們項目研發從總體上看還比較順利的重要原因之一吧。
我加入騰迅後最早是在琳琅的J-Star項目組做UE3引擎的底層維護和客戶端性能優化工作，就是現在《槍神紀》的前身，後來項目轉型為TPS，我又負責了客戶端的技術預研和將近一年的客戶端開發和管理工作。2012年還做了一年的次世代寫實賽車預研。
移動大潮襲來，產業環境變化迅速，我們也有幸得到了研發賽車手遊的機會。項目剛啟動那會兒我們團隊總共只有五個人，客戶端就我和winco兩個，winco作為項目負責人要邊想玩法邊寫代碼，而我除了負責搭建程序框架和實現基礎模塊外還要負責部份玩法邏輯，有時候真的感覺有點忙不過來，還好我們的TA江江比較全能，不光能寫Shader，還能幫我們分擔一些客戶端表現邏輯的編寫，新加入的策劃erik更能親自操刀修改相機跟隨和得分統計的邏輯，讓我們省心不少。
最開始遇到的問題主要還是技術上的，我們沒有Unity3D引擎的實際項目經驗，心裏面沒底，不知道研發過程中會遇到哪些坑，對於iOS/Android平台編程更是一竅不通，項目進度又緊，不可能有充裕的時間自己去學習和摸索，萬幸得到兄弟工作室團隊的無私支持，從上海手遊團隊借調來了cloud， chadwi兩位有著豐富手遊客戶端開發經驗的同事，讓團隊少走了很多彎路，我也從他們身上學到很多移動端遊戲開發的一線實戰經驗。
我們的研發團隊規模一直都比較小， 直到項目上線也只有十來個人，不少美術同學還是兼職的。 正式運營後才深刻認識到我們的人力規模完全沒法適應玩家對於遊戲內容的消耗速度。在工作室和產品中心的支持下，隊伍得到不小的擴充，目前是30人出頭的規模，也算是一個中等規模的團隊了吧，然而團隊規模擴大了又會凸顯出很多新的問題，比方說工作任務間的偶合，多線開發的版本管理等。
對於小團隊來說，解決問題可以很直接，只要有可行的方案，可能一句話就搞定了，尤其是我們有幾個人是從J-Star開始就一直在一起做事，做天天飛車之前就已經磨合兩三年了，配合起來非常默契。但團隊規模大了之後，可能就會涉及到一些團隊管理問題了，如何讓大家擰成一股繩去做事情，並不是簡簡單單把問題指出來就可以了， 這時候制度和流程就顯得尤為重要了。
早作規范早驗證避免返工尋找表現與性能的平衡點很重要
我們的一個習慣就是一開始一定要把遊戲最核心的東西、最可能遇到的技術難點，不管是玩法方面的還是表現方面的，徹底捋順想清楚了做出Demo來驗證，然後才是制定標准和量產，這能提高開發效率降低走彎路的機率。
天天飛車的Demo做的非常快大概兩三周就基本完成了，包括了無限賽道的動態拼接， 碰撞檢測，車輛的碰撞響應，車輛和道具動態生成等等這些最基礎的功能， 而且也已經具備了最基本的玩法邏輯比如說驚險超車。雖然以現在的眼光看起來它很原始也有很多問題，但如果撇開畫面表現和細節手感之類的不談，天天飛車最最核心的東西其實就是這些。
對於客戶端來說可能最首要的問題就是設備適配問題，Unity3D有很好的封裝性，系統和設備的特殊性大多被隱藏起來了，所以兼容適配基本不用操心，就算後期測試時發現一些兼容問題針對性的處理下也就好了。分辨率適配也沒有太大問題，業內廣泛采用的NGUI界面中間件提供了一套基於錨點和等比縮放的很成熟的方案，我們只需要按照它的規范去做就行了。所以，最需要投入精力的還是性能適配問題。
按照以往做端遊的經驗，如果有成熟的引擎和技術方案作為基礎，性能適配問題的核心其實就是訂立合適的資源規范並嚴格執行。資源規范主要分為兩類，一是數量上的，包括單幀渲染的面數及頂點數，DrawCall數，同時載入的貼圖和音頻容量等等。另一類是技術規格上的，如光照模式，貼圖格式，音頻格式等。在制定規范前，我們首先依據微信和手Q的用戶設備統計數據確定了遊戲的最低配置要求，因為我們的用戶就是他們中的一部份，而且很顯然，遊戲的配置要求越低，將來的用戶量也就可能越大。另外因為沒有經驗不能一上來就埋頭自己幹，所以我們還參考了怪物大作戰的一些規范，他們可以說是公司Unity3D手遊的先驅，向他們致敬。
當然了，光有資源規范是不夠的，程序上的基礎性能優化工作還是必須得做好做足的，對於Unity3D手遊來說主要有托管堆內存的合理使用，對象池，資源加載卸載管理等。
作為一款3D遊戲，我們也一直在尋找遊戲表現和性能的最佳平衡點。一個基本的取舍原則可能就是性價比，看性能的損耗帶來的效果提升到底大不大，是不是用戶比較關注的。另外在這點上程序和美術之間也經常會出現一些意見分歧，這很正常。對於程序同學來說希望客戶端特別省，輕巧而快速。對於美術同學來說希望畫面足夠精細，能夠最大程度的保留設計初衷可能是非常重要的。這個問題目前看來我們處理的還是比較好的，站在客戶端程序的角度，一方面有些原則我們必須要堅持，比方說不能使用複雜的實時動態光影，後處理效果等確實與當前大多數移動設備硬件性能不相匹配的技術，另一方面我們也應該和美術同學一起為遊戲的表現品質努力，比方說我們實現了一個效果自適應模塊，能夠根據用戶的設備性能選擇合適的效果等級，既能讓配置較差的設備以比較流暢的幀率運行遊戲，高端機型也能夠表現出更精細的紋理，更真實的光照，更多的場景細節，更華麗的特效等等，避免了畫面品質一刀切的情況，給了美術同學多一些的發揮空間。當然總的來講，我們的資源規范還是比較嚴苛的，不得不贊歎我們的美術oa，在如此多的限制下，依然讓我們的遊戲有很不錯的畫面品質。
車庫
高配畫面
低配畫面
安全問題早作預案源於端遊積累打擊外掛嘗試種種辦法
相比端遊而言手遊面臨的網絡環境更嚴峻，我們不可能做到實時通過服務器校驗玩家的每一步操作，從延遲，穩定性，流量上講都不允許。單局的玩法邏輯大都是在客戶端完成在結算時才統一上報服務器的，玩家就有可能修改一些關鍵數據，比方說分數，金幣，Buf持續時間等等，從而獲得非法收益，這就必然牽扯到令人頭疼的反外掛問題。
基於以前端遊的積累我們初期就預想到了這個情況，比較早地開始了對抗准備。我們的外掛對抗體系大體分為三層，第一層是客戶端的防禦，除了必不可少的協議加密之外，客戶端對內存中的關鍵數據也都是密文存儲的並且加上了校驗碼，這樣通過燒餅之類的通用內存修改工具就比較難定位數據的具體位置了，而且就算真的找到了內存地址，修改之後也會導致校驗失敗，這樣客戶端就能偵測到內存數據的非法篡改。第二層是我們自己服務器的即時對抗，客戶端在單局結算時上報的數據中不光有最終的結果還有一些和結果有關聯的中間數據，比方說實際生成了多少金幣，是否有出現某種特殊車等等，如果外掛只是修改了部份數據，服務器就可以根據校驗公式檢測出數據被非法篡改過了，服務端kenny以前在QQ飛車(微博)就做過類似的對抗，經驗非常豐富。最後一層是互娛安全組的後校驗，他們采用的檢測方法和我們服務器的類似，只是不會對作弊行為進行實時處罰。
還有一個要特別注意的是，在Android平台上，Unity的C#腳本是以JIT方式運行的，apk包裏的程序集dll文件很容易被Reflector等工具反編譯，一旦被別有用心的人知道了客戶端邏輯到底如何運作的，就可能做出一些比較逆天的外掛來。當時我們想了很多辦法，一開始是做混淆，但發現執行起來不是很方便，對開發存在一定的限制。後來我們想到一個方法，我們可以對程序集dll文件進行加密，這樣通用的反編譯工具就打不開了，但苦於我們沒有Unity及其修改過的mono組件的源代碼， 也不擅長逆向工程，我們把這個需求提給Unity的開發商，可能出於某些原因，他們也沒有太積極的反饋，後來還是安全組給了我們支持，他們通過逆向工程實現了對程序集文件的加解密，之後公司開發/代理的Unity手遊應該都有采用這個加密方案。
崩潰上報一度讓我們苦惱靈活處理是解決之道
針對移動應用，MIG研發了一套叫做RQD的崩潰上報系統，MSDK對它作了統一接入，所以凡是接入了MSDK組件的移動端遊戲在客戶端發生崩潰時都會自動捕捉上報異常的現場信息，對分析崩潰來說最有用的可能就莫過於調用棧了。
RQD雖然很強大，不光支持C/C++，ObjC這些原生語言的調用棧的還原，也支持Java的調用棧還原，但可惜的是Unity開發的遊戲大多的異常其實發生在C#層，iOS平台還好，C#是以AOT方式預先編譯成了原生代碼，調用棧會被當作C語言的對待，從函數名上也能基本定位到C#中具體發生崩潰的地方。但Android平台就沒這么幸運了，C#是被預先編譯為IL中間代碼，以JIT模式在mono虛擬機中運行的，所以一旦C#層出現異常，RQD報上來的調用棧反映的都是虛擬機自身發生了異常，無法定位異常發生的具體位置，然而Android崩潰率大大高於iOS，恰恰是需要更多關注的。
後來通過猜測和試驗，我們發現其實在C#層產生異常時，Unity可以通過回調的方式把異常類型和調用棧告知應用，這正是我們需要的，但如何把這些信息上報又成了問題，因為一旦RQD捕捉到異常就會立即kill掉應用，可能應用都沒有機會處理這些信息，我們把情況反饋給了RQD的研發組，但短時間內他們也很難有比較完善而系統的解決方案。後來通過和RQD開發同事不斷的探討終於找到了一種看起來簡陋但卻行之有效的方案：由他們提供一個發生異常時延遲kill掉進程的定制版本，在異常發生時我們把需要額外上報的異常信息以追加的方式寫入會上報的tomb文件。采用這種方法，我們所需的C#異常信息在Android平台也能有效地通過RQD上報了，而且能在後台頁面比較方便的查看。
安裝包容量縮減方案分享多種方法協力顯功效
天天飛車屬於最早那一兩批上線的微信/手Q遊戲，為了盡量降低玩家進入的門檻，當時對安裝包體積的要求還是蠻嚴格的，至少要控制到40M以下，而當時我們的安裝包體積已經突破50M了。
第一步，我們還是檢查梳理了一遍資源，看看有沒有資源沒按照規范來制作，有沒有資源是冗餘的，這應該是最基本的，這項工作的一部份可以通過自動化的工具來完成，利用Unity提供的編輯器擴展接口來實現還是很方便的。
我們分析過安裝包的具體構成，其實還是貼圖資源占比最大，所以很自然地應用了TinyPNG之類的減色工具來減少貼圖的信息量，實際結果表明這個優化對決大多數貼圖表現的影響都是可以接受的，僅有少量的UI貼圖需要區別對待一下。
渲染中文字符所使用的矢量字體文件ttf的體積對於手遊安裝包來說實在是有點大，一個最基本的優化手段就是使用精簡字庫，但精簡過渡又會導致很多字符無法正常渲染，所以最後依然會占用5M左右的空間，當時的一個想法就是可否直接把移動設備操作系統的字體文件拿來用，感謝iOS這個封閉的系統，字庫很統一，這個方案確實是可行的，遊戲首次運行時通過系統API直接從系統字庫提取出字形信息組裝成了ttf文件，但Android系統就不行了，各種系統版本字庫五花八門，只能還是老實地把精簡字體文件打進安裝包.
還有一個大頭是在音頻上，在PC端上遊戲音頻一般直接采用mp3/ogg等流行的壓縮格式就可以了，但終端設備尤其是Android設備很多不具備音頻的硬件解碼能力，CPU運算能力又相對較弱，在做性能分析的時候發現，一些中低端設備，甚至某些比較高端的設備，在音頻解壓這一塊都有相當大的性能消耗。為了流暢的幀率我們最初不得不采用非壓縮的wav格式。但問題很明顯，非壓縮格式的音頻文件體積太大了，因為信息量特別大，打進安裝包裏也縮減不了太多。後來我們采取了一個兩全其美的方案，安裝包裏依然存放壓縮格式的音頻，遊戲第一運行時，把音頻解壓成非壓縮格式來播放，這塊當時節省了8M多空間。
經過這些努力，我們的首發安裝包體積成功的控制在了30M的水平，但需要注意的是Apple會對可執行文件加密，這會導致AppStore中的版本會比提交審核的原始包大一些.
手遊與省電似乎天生存在矛盾小技巧暗藏客觀效果
與普通的App相比，手遊耗電確實要厲害得多，大家也都比較關注這一塊，影響手機耗電的因素很多，CPU的占用率，GPU的運算量，屏幕的亮度，網絡模式和通訊量等等，都會影響到電量消耗的快慢，然而手機網遊恰恰是這些硬件資源的消耗大戶，而且消耗的更多往往就能給用戶帶來更絢麗的表現，更流暢的操作體驗。
一方面，我們要做好遊戲的性能優化，這是最基礎的，因為這樣就能以更少的硬件資源消耗帶來基本相同的遊戲體驗，另一方面，我們也可以采取一些小策略，小技巧來達到相對省電的效果，比方說我們將遊戲刷新率最高限制在了30幀，因為這對於天天飛車這種類型的3D遊戲的流暢體驗來說基本足夠了，又比如在大廳裏面掛機或者暫停遊戲的時候， 其實不需要保持比較高的刷新率，這時候就完全可以把幀率降下來，自然而然就獲得了省電的效果。當然這只是兩個很小的例子，具體遊戲可以根據自身情況仔細挖掘，靈活利用，運用的好的話效果應該是相當可觀的。
引擎選擇必須要適合自身項目能否駕馭和掌控至關重要
對於新的手遊項目來說，從一開始立項就需要考慮好，選引擎就是要適合自己的，看你的遊戲類型，團隊規模，還有很重要的一點是看周圍環境是怎么樣的，如果你選擇了一款很少人用的引擎，當你需要交流、需要別人幫助的時候，你可能都找不到人。國人做事講究天時地利人和，我覺得有一個好的交流分享環境應該算是地利之一吧.
當時我們選擇Unity來開發也是有多方面考慮的。首先我們要開發的是一款中小型的，3D的，移動端遊戲，需要同時發布到iOS和Android兩個平台，我們的團隊規模很小，Unity的應用非常廣泛，有不少和我們同類型同規模的遊戲的成功案例，比如一起車車車，神廟逃亡等，公司也已經有了Unity開發的且已上線的移動端遊戲項目，其次Unity本身也是一款開發效率很高的引擎，它的集成開發環境非常好用，資源整合很方便，遊戲邏輯主要用C#等托管語言編寫，和引擎本身的實現是完全隔離開的，開發，編譯效率都非常的高，改完代碼，幾秒鍾就能看到實際跑起來的效果，手遊這種特別需要快速迭代的項目再適合不過了。再次，對於3D遊戲開發開說，Unity提供的功能也是相當完備的，擴展起來也很方便，可以用C/C++，ObjC，Java編寫運算密集型的或者需要直接訪問系統底層接口的組件以插件的形式供遊戲邏輯層訪問，編輯器功能也很容易擴展，此外Unity的AssetStore提供了一個很好的組件交流平台，需要什么額外功能的時候去看看，也許能避免重複發明輪子.
2D遊戲我們目前不推薦Unity來開發，畢竟這個引擎原本是面向3D遊戲的，功能也主要是圍繞這一塊來做的，如果你只是做一個2D遊戲，它不可能把你不需要的功能全部都幹淨的拿掉，肯定會有很多額外的開銷。雖然Unity最近的新版本也逐漸在增強對2D遊戲的支持，但可能還不太完善，項目案例應該也少，2D的話我們還是推薦使用公司的自研引擎或者是應用廣泛的cocos2D。
對於已上線的產品來說，在遊戲玩法不斷擴展，新資源不斷增加的運營過程中，是否能夠把消耗的增加也控制在可接受范圍之內，這是很關鍵的。比方說，Unity引擎比較大的一個問題就是內存控制不是那么的好，不太注意的話很可能讓你的內存占用超標。
一方面你自己的程序框架要合理，另一方面就取決於你對引擎的掌握程度了，如果你都不太清楚究竟是什么地方吃掉了CPU時間，什么地方占掉了內存，那可能遇到問題時你就束手無策了，這其實是一個失控的狀態，對於一個已上線產品來說是很可怕的。我們不怕問題有多大，最怕的是雖然知道遇到了問題，卻搞不清楚問題的具體緣由，更談不上徹底去解決它了。Unity是一個比較封閉的引擎，少有機會去研究和修改它的源代碼，所以對它的掌控，我們目前做的也並不算特別好，現在我們也是在不斷的加強，看怎么去徹底的駕馭它。
更多閱讀
原文出處
