《球球大作戰》優化之路（上）

自從2015年《球球大作戰》釋出以來，現已擁有五億多的玩家。如此龐大的玩家群體，對遊戲的畫面，效能要求是非常高的。在Unite Shanghai 2019大會中，《球球大作戰》客戶端主程王國禕和資深技術徐宇峰帶來了關於《球球大作戰》優化之路。

本文將分享《球球大作戰》客戶端主程王國禕演講部分，他將分享《球球大作戰》升級到Unity 2017版本遇見升級問題和資源問題，以及如何去處理解決。


演講內容

大家好，感謝大家來聽我們的分享。我是《球球大作戰》客戶端主程王國禕，主要負責《球球大作戰》的客戶端開發。之前都是以聽眾角度參加Unite大會的，這次作為一個演講嘉賓過來參加，感覺體驗還是不太一樣，很有新鮮感。

簡單介紹一下《球球大作戰》，這是一款多人休閒競技遊戲，主要強調多人合作玩法，玩法簡單上手，但想要達到高的級別或段位，還是比較困難的。

《球球大作戰》釋出於2015年，當時很多遊戲的玩家現在都上了初中或高中。就像《超級馬里奧》或《魂鬥羅》可以成為我們這一代人的回憶一樣，我也希望《球球大作戰》能成為他們的長久陪伴，這也是我創作遊戲的初衷。


升級Unity 2017

《球球大作戰》早期使用Unity 4.7開發，所以整個表現效果都是Unity 4.7版本，後來我們也嘗試升級了Unity 5的版本，但發現問題還是比較多，所以我們去年做了Unity 2017版的升級，我們會在下面分享升級過程遇到的一些問題，後面還有優化的過程和新的方式。

先講第一部分，是我們升級Unity 2017遇到的一些問題。最開始我們也嘗試升級Unity 2018版本，我們試了Unity 2018.1和Unity 2018.2，在轉換過程中的問題還是可以接受的，但上線測試時發現了相容性問題，最後我們還是選擇使用比較穩定的版本，也就是Unity 2017.4.3。

小提示：Unity每個週期會有3個TECH技術前瞻版本和1個LTS長期穩定支援版本，Unity一直建議對已釋出的遊戲採用LTS版本，也就是Unity 2017.4或者Unity 2018.4，從而避免遇見上文提到的相容性問題。請閱讀：Unity全新的版本釋出計劃。

為什麼選擇Unity 2017呢？主要是因為它和Unity 4.7有一些不同的地方。


1、ASTC圖片壓縮格式

我們一開始嘗試在Android和iOS同時使用該格式，後來經過大量測試發現Android不支援這個格式機型佔比很高，最後在Android系統上還是使用原有的ETC和ETC2格式，只在iOS上使用ASTC格式。

iOS在iPhone 5S及以下機型硬體會走原解壓的過程，整個圖片的載入速度會比之前稍微慢一些，但我們覺得速度測試下來還是比較理想的，所以還是堅持在iOS系統使用ASTC格式。

2、Bundle LZ4的壓縮

在Unity 4.7版本時，我們基本是不做壓縮和解壓縮的，中間會用LZMA做傳輸過程的壓縮，這樣在壓縮和解壓方面不會佔用時間。

到了Unity 2017.4後，因為它本身就支援LZ4的壓縮，不管從解壓速度和記憶體大小來說，它都是很少的，所以我們最後決定用LZ4。

3、Bundle檔案的非同步載入和讀取

在使用Unity 4.7時，我們在載入非壓縮檔案時是走同步的方式，因為本身Unity也沒有做非同步載入Bundle的介面，但是Unity 5.x以上版本就支援這個介面了，所以我們這邊Bundle是使用了非同步載入的方式。

4、執行時設定解析度

我們有一些優化測試下來發現，該遊戲本身手機的解析度可以達到很好的提高幀率並降低消耗的效果。

Unity 2017.4和Unity 4.7在設定解析度有一個很大的不同是，之前在Unity 4.7降低解析度時，在Android系統會出現閃一次黑屏現象，這在Unity 2017.4上是沒有的，所以我們可以用這個特性來動態調整螢幕的解析度。

在特定場景中，例如：高渲染的場景中，可以動態調低解析度，使使用者可以在沒有感知的情況下提高幀率。

5、Camera RT縮放解析度可提高幀率

在Unity 4.7上我們嘗試過在Camera縮放解析度，但是沒有效果。在Unity 2017之後，我們嘗試這個方式發現效果比較明顯，發現平均幀率可以提高15幀左右。但是帶來的問題是，可能顯示上有稍許的差別，沒有原始的不改解析度的情況好。

6、Android支援IL2CPP

Android支援IL2CPP主要是為了Google之後發版本的。

7、支援GPU Instance

我們在年初的時候製作一個3D的玩法，如果是Unity 4.7的話，這個玩法在我們的機子上就爆表了，因為同場景渲染的動作非常多。

在升級到Unity 2017時，使用GPU Instance幫了很大的忙。尤其在動作處理這塊，可以動態合批，然後它合成的效果非常好。

8、動畫系統可以對指定區域縮放

最後一點也是美術吐槽非常多的，那就是Unity 4.7動畫調整的時候，不能對指定區域進行縮放，它只能一幀一幀地調，這是升級後緩解最大的一點。

Q1：遊戲幀率降低

下面簡單說下升級2017後遇到的一些問題，這些問題是我們沒想到會發生的。因為我們想：升級引擎只是對一些資源，效果會有一些提升，甚至效率會提升。但升級完之後，測試發現在同等手機，同等內容的情況下，幀率反而會減低。


我們對問題查了很久，做了很多版本的比對，甚至對不同版本，不同客戶端進行差異的比對。測試下來的效果是：Unity 2017在同等情況下比Unity 4.7要低10幀左右。這主要發生在中端偏低端的機型，正常的中端以上機型沒有這個問題，甚至表現效果會更好。

我們測試問題的時候，還做了獨立的只有核心玩法的版本，這個版本拋離了遊戲以外的系統，只有核心玩法。這樣是想更好地測試過程，並儘快地排除問題，

因為這些問題比較難發現，所以這個版本一直是我們測試的核心版本，而且這個版本也做了動畫錄製的功能，把每一局的表現的協議和指令碼都錄製下來，每一局都是自動播放，這樣迴圈地檢視問題，檢視每個幀率的表現，最後找到這些問題。


有幾個選項上的切換，一個是Android上的Blit Type。

Blit Type選項在Unity 2017版本上是2.0之後開放的，也就是說2.0之前是沒有這個選項的。我們測試時發現，把這個選項關掉後，幀率確實提升了很多，提升了5-6幀左右，我們發現它對中低端硬體的渲染影響還是比較大的。

我們與Unity官方技術支援交流，他們說針對不同的遊戲，這個選項可能選擇自動的會比較好。但是測試下來發現，可能因為我們的遊戲對3D和渲染光照方面使用的不是很多，所以去掉該選項，使用Never可能效果會更好。


因為我們的遊戲表現上看起來是一款2D遊戲，所以對鏡頭上的HDR和抗鋸齒MSAA不是很實用，所以我們會在Camera元件中，去掉勾選Allow HDR和Allow MSAA這二個選項。

還有光照這塊，因為遊戲沒有使用實時光，所以我們在Lighting設定去掉Realtime Lighting和Mixed Lighting選項。調整了這些選項後，幀率持平了原來的遊戲表現。


Q2：資源問題

下面是轉換上的資源問題。球球到現在為止的皮膚總量已經超過4千多個，也就是意味著我們在轉換過程中要排查每一個資源，和舊的資源去比對，會不會有顯示上的問題。這是非常巨大的工作量。


這邊一個問題就是，我們有一些美術同學可能前期從一些舊的資源裡，使用Mesh匯出的檔案包含中文的命名，這是為以後埋了一個坑。

雖然在Unity 4.7裡沒有問題，會顯示一個橫槓，不會顯示中文名，顯示上不會有問題。但同樣的資源轉到Unity 2017後，顯示上會出現一些引用丟失的情況。

我們分析過後，發現Meta檔案中的Unicode碼丟失了，所以需要手動地把這些複製過去，所以這是當時解決問題比較棘手的地方，因為當時都是手動複製的，幸好這些中文的資源不是特別多。


還有就是轉換之後粒子縮放的問題。因為球球的皮膚之間是互相疊加的，疊加之後為了做相互的疊加效果，會有Z軸的壓縮。所以轉換之後，粒子的縮放模式變成了Hierarchy模式，根據主節點一起縮放。

這個問題導致的效果是，Z軸上的粒子表現縮放會有縮放的顯示問題，會有穿插，最後表現的效果是和大小縮放後的效果不是很一致。

我們向Unity反饋過這個問題，Unity也在跟蹤處理這個問題。我們現在改成了Local模式，因為我們自定義了一個縮放的指令碼來控制球體和粒子放大縮小後的效果。


Q3：打包問題

接下來分享我們碰到的一些打包上的問題。


我們的美術資源現在有6G多，在舊版本中打包耗時非常長，耗時通常要半個小時左右。在資源量非常大、冗餘之後，工程啟動也非常慢。

升級Unity 2017之後，資源在打包速度和工程開啟速度上都有些提升，但還是沒達到理想的情況。

我們採取的方式是把老舊資源拆解到另外一個工程裡面，保證二個工程的引用是統一的，Guid也是統一的。這樣在老工程中的資源是不進行打包處理的，只打包新的資源，這樣提高了很多打包速度，Unity開啟美術工程資源的速度也會非常快。


我們在Unity 4.7匯出的是一個Eclipse的專案，所以在打包時哪怕檔案很多也不會有打包失敗的情況。但是使用Android Studio的時候，如果使用預設設定的話，會出現打包失敗。

這個失敗問題比較奇葩，它不會給你提示錯誤，只是打包時間非常非常漫長，甚至在最後沒有結束的時間。

我們也查了很多資料瞭解這個問題，最後發現是要調整快取，在打包Android Studio時，如果本身包含的檔案非常多，要記得把快取改大一些，要不然打包時會有問題。


在匯出iOS工程時，我們會匯出XCode工程，發現每次匯出時Framework Search Paths的目錄，就是庫引用的目錄每次都會被清空。

我們有很多第三方的庫是需要被引用的，而且打包是自動的，iOS這邊匯出後會自動設定好，所以後面改了方法，是在匯出時使用PBXProject.SetBuildProperty方法，把需要引用的庫再動態地新增上去，來解決這個問題。


客戶端版本

這是我們測試的一種方式。我們遊戲對玩家手感操作的敏感度可能非常高，也就是說，如果一個版本釋出後，和之前的手感有所差別，對我們是比較災難性的結果。

所以我們測試使用二個版本，一個叫預覽版，一個叫正式的線上版。玩家正常玩的都是線上版，然後我們會推送給玩家預覽版，預覽版的賬號和伺服器是通用的，只有客戶端不同，一個是普通的是Unity 4.7版本，另一個是升級之後的Unity 2017的版本。

我們讓玩家體驗這二個版本，並且給反饋，因為玩家會在同一個手機上體驗二個版本，所以給出的反饋都是比較真實的，都是比較及時有效的。我們覺得這個方法是最有效的測出問題的方法。


版本相容，渠道更新

我們線上其實一直存在二個版本，因為我們早期嘗試使用過5.x版本去升級。當時做完後發現效果並不好，而當時盲目樂觀地直接用5.x版本進行開發，導致新制作的資源都回退掉了。

我們進行Unity 2017版本升級的時候，直接拆成了二個版本，也就是說正式開發過程還在Unity 4.7上，無論是美術還是程式，都在老版本開發。

線上還會同時存在老版本和新版本，開發的內容和功能在Unity 4.7版本更新好後會合併到Unity 2017的版本，並同步更新出去。二個版本一般會有三個月的相容期，儘量讓玩家把測試期縮短，讓玩家在裡面反饋問題。

我們會在部分渠道先上傳一些版本，然後小範圍地進行更新，目的是不影響玩家的情況下進行更新，擔心新版本的相容性會存在問題。


球球優化

下面講一下球球的優化，前面我們講了球球的升級，其實升級的目的是想通過升級的一些手段去做新一輪的優化。

以前我們會從技術角度去做問題的排查和優化，例如：玩家網路有問題，反映延遲很高。我們覺得把TCP換成UDP，並且調到比較好的主幹網路或機房網路，會解決這些問題。其實並不然。

有一次我參加《球球大作戰》的見面會，一個玩家吐槽他連線自家WiFi時非常卡，延遲非常高。他上網查問題，搜了一些帖子，發現有人回覆說把防火牆關掉，他嘗試後發現真的好很多。出現這個問題我想的是可能他的網路把UDP常用埠遮蔽掉了，然後只能走不是UDP常用的埠。

通過這個問題，我們發現玩家往往發現的問題不是我們要優化的點。我們從技術角度想的一般是網路上換一個網路底層，把DrawCall降低，以為這樣就解決了問題。其實並不是，我們要從玩家的角度去查詢到這些問題。

制定美術資源標準

我們之前的美術標準都是一刀切，例如：最高不可以是多少Drawcall、面數、骨骼數。

但美術在製作資源的時候，如果低於這個標準，例如很簡單的資源，美術會覺得反正低於這個標準，那麼就多加一些特效。如果超過這個標準，但是又是重點的付費道具，短時間無法優化好。

我們總結髮現，美術資源標準要差異化。

下圖是我們新制定的美術標準。


對於美術或遊戲來說，我們的道具分普通的道具和炫酷的道具，我們要把檔位精細化，有界定的指標確定一般的檔位是多少，然後是比較炫酷道具的指標，再定最大指標。

這樣美術操作時會覺得比之前靈活很多，會知道自己製作的資源屬於什麼檔位，然後按檔位去做優化。

LOD優化

還有就是針對遊戲的LOD優化，因為《球球大作戰》看上去更像是一個2D遊戲，和3D遊戲的LOD優化不太一樣。

我們使用的方法是皮膚畫素佔螢幕畫素的比例差，進行高低品質資源的切換，在球體非常小的時候，我們會提供低配的提前渲染好的圖片。

因為我們試過簡化特效粒子，發現不管是工作量還是效果都不是很理想，後來我們發現玩家主要注意的視野都是大球，而不會很關注小球。所以我們採取的方法是，提前渲染好圖片，替換到比較小的資源上，在玩家球體很小時，使用圖片渲染。


手機效能分類

對於手機機型劃分，很多優化方式對玩家或多或少有影響，所以我們想針對不同機型對遊戲做優化。最開始其實沒有按機型分，因為我們覺得機型太多無法劃分。

我們的方法比較投機取巧，那就是使用CPU型號去做手機型號分檔。網上可以找到CPU梯度圖，不同CPU在不同檔位，只要獲取玩家的CPU資訊就可以對應到不同的檔位裡面。

但測試後發現這個方法不太樂觀，因為我們遇到一個現象：有的手機CPU處於中檔，但是螢幕解析度卻非常高，這時會出現整體效能表現降低的現象，所以我這種方式不太靠譜。


我們最後選擇的方法是：由於遊戲運營已久，有大量的玩家幀率卡頓日誌，所以我們通過玩家的幀率、每局遊戲得到幀率差值、最高最低值等，決定該局遊戲的幀率範圍。

然後過濾出來手機在執行時是處於高檔機型、低檔機型、還是中檔機型。這個分檔比較靠譜，雖然這樣涉及機型較多，但準確性比之前的方法高很多。

我們發現周邊的同事都在不停的換新款手機，所以我們會習慣認為玩家的手機也在不停更新換代。通過遊戲資料我們發現千元機佔了60%多的使用者，這也讓我們把優化重點放在這些手機型號上。

網路卡頓

下圖是我們每局結束都會上報的網路使用情況，我們還沒對資料做處理，而是對上報結果進行分析。

我們覺得玩家手機使用4G基站網路，或使用WiFi，過程是路由器到主幹網，主幹網到遊戲伺服器。這只是把主要網路情況監控下來，後期會做一些篩選和定製化的策略，例如一些提醒，這是我們後面要做的事。


小結

在《球球大作戰》優化之路的下篇中，我們將繼續分享本次演講巨人網路資深技術徐宇峰講述後期遊戲製作中的優化方式，敬請期待。

更多Unite大會精彩內容分享，盡在Unity Connect平臺(Connect.unity.com)。

下載Unity Connect APP，請點選此處。觀看部分Unity官方視訊，請關注B站帳戶：Unity官方。

作者：王國禕  
來源：Unity官方平臺