Unity服務器下發配置的方法是什么

這篇“Unity服務器下發配置的方法是什么”文章的知識點大部分人都不太理解，所以小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“Unity服務器下發配置的方法是什么”文章吧。

1 Sproto協議

在之前的客戶端技術選型的文章里我們就介紹過，服務器使用的是SkyNet。

Sproto 是谷歌Proto的一個變種，是云風基于SkyNet實現的一種優化格式。之所以選擇這個格式是因為SkyNet對Proto的支持只到2.x，并且已經不再維護了。而Sproto更符合目前服務器在Lua端的性能表現。為了配合服務器的通信協議格式，客戶端也選擇使用Sproto。

詳細的內容以及擴展閱讀可以參照技術選型文章里的Sproto部分。

2 Sproto 表格

客戶端關注兩個部分的數據，一部分來自運行時服務器的下發，一部分來自靜態的策劃配置。既然和服務器通信采用的是Sproto格式，那就沒理由再整一套額外的數據格式來處理策劃數據。

但，策劃大部分時候都是用Excel編輯數據，所以我們需要制作一個導表工具，用來將表格數據轉化為以Sproto格式序列化的Byte文件，就像Proto一樣。

這里的轉換過程有點復雜，一言難盡，有空我們講導表工具的時候再進行詳細闡述?？偠灾?，就是客戶端將服務器的通信協議和策劃的表格配置統一成了Sproto格式讀取和處理。這帶來了很多好處，比如要聯調服務器數據的時候，我們完全可以使用表格偽造數據進行聯調，或者將服務器下發的數據持久化存儲，變為靜態數據的一部分。同時這樣也可以讓策劃把一部分敏感數據配置在服務器，登陸之后再由服務器下發存儲到安全的地方，防止反編譯。

當然這些特性其實我們都沒有做，只是用到了服務器數據格式和策劃數據格式一致的特性，進行了部分表格的增改。當然這里就包括對多語言的更改。

3 增改結構

客戶端對于不同的數據源也是分開存儲的，策劃數據匯總于DataManager，而服務器數據匯總于NetDataManager。二者之間基本不會有交互，只有一種情況下除外。服務器在下發了登陸成功協議之后，緊跟著會下發策劃數據表的熱更新Bytes。

這里需要和傳統的客戶端資源熱更新形成區別?？蛻舳说臒岣率庆o態的，走的是CDN，它是一種常規的管線功能，更新的資源體量大，種類多。但是只會在游戲登陸之前（一般是剛啟動）。而我們這種功能實現是為了應急或者修補BUG而應用的備份策略。服務器的流量本來就很貴，不應該用來下發大量的靜態/表格數據。同時作為應急功能，它不能被過渡使用從而導致過多過于復雜的邏輯。

我們會在一個專門的導表目錄里放置需要熱更的表格數據，導出之后，服務器會識別到該目錄下的所有文件，根據文件名建立名字-數據索引，然后存儲在內存中，客戶端連接上之后，以專門的協議下發，客戶端收到之后，和緩存中的數據進行比較，沒有的增補，已有的覆蓋。

這個功能對于服務器來說是熱重載的，對于那些已經在線的客戶端，也可以通過運營工具進行廣播，從而完成服務器不停機，客戶端不重啟，便對數據或者BUG進行修復。

4 屏蔽詞實現

屏蔽詞有些麻煩。為了兼顧查找和替換效率，我們是使用了 trie Tree的方式進行的。如果有不清楚的，可以返回看這篇文章。

因為屏蔽詞的條目非常之多（我們過審的版本有52萬條，文本文件就接近10M），所以必須提前將屏蔽詞進行離線處理，然后運行時進行加載（不然每次登陸你可能要等10幾秒）。但這也帶來了額外的問題，因為它不像其他表格數據一樣是離散的，所以不能使用上述方法進行增量下發。

而由于屏蔽詞的樹是提前遍歷所有詞組，然后離線生成的，它也不具備動態插入功能（重新生成整棵樹代價很大）。所以針對屏蔽詞我們使用了另一套規則。既然不能合在一起，干脆就完全獨立為兩棵樹。數據格式是一樣的，只是數據源不一樣，那么我們就創建兩個版本，Server版本和Client版本。Client版本多且大，離線生成。服務器版本小且動態生成。當需要查詢屏蔽詞的時候，優先查詢服務器版本，沒有再查Client。

而這個時候，數據下發依然可以通過上述的框架結構進行數據增補，每次服務器有屏蔽詞下發，就重建一次服務器屏蔽詞樹，因為服務器增補的條目數一般都很少，幾乎不會造成性能問題（即使有也是一瞬間）。

我們在版署過審中，使用該方案減少了多次打回出包的問題。

5 復合配置熱修復

所謂復合配置就是有些問題單張數據表無法修復的。比如系統郵件，如果本身郵件的數據表就缺少數據模板，這個時候我們不僅僅要下發語言相關的內容，還需要下發郵件的增補數據。同理如果郵件還涉及到新的獎勵物品，也可以通過下發Item表進行增補。當然這些使用到的都是基于上述的增補框架。

6 運營介入

這部分涉及到的是運營的各種公告和通知。比如緊急停機，突發狀況等等，這些都是無法預料的，自然也無法事先將語言或者數據配置在表格中。而上述我們所處理的都是游戲功能，屬于策劃層面的BUG修復。但是到運營這個層面就不同了，首選運營編輯公告或者處理不同地區服務器的時候不應該都經過策劃或者開發組。事實上游戲運營者可能和開發者完全是不同的公司。如果是在不同的國家的當地發行，甚至語言都不通。

這個時候就需要一套完整的工具鏈來幫助運營直接使用該功能。前面我們聊了這么多也知道，服務器和客戶端之間進行數據增補是完全沒有問題的，現在需要在這條鏈路里增加一個控制方。確切的說應該是變更一個控制方。因為現有的鏈路服務器和客戶端交互是在某個特殊的目錄下，存有特殊的byte文件。而這個文件是策劃導表生成的。服務器讀取文件，轉化為二進制，通過協議下發。

而我們稍微轉變一下思路，即提供一個運營工具，讓他們可以將需要的配置通過工具生成一個指定的文件或者二進制緩存，傳遞到服務器，然后就可以按照正常流程進行數據增補了。

以上就是關于“Unity服務器下發配置的方法是什么”這篇文章的內容，相信大家都有了一定的了解，希望小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注億速云行業資訊頻道。