技術(shù)中臺從2020年3月2日開始，到今天2021年9月26日已經(jīng)一年半左右的時間，整個過程有很多的調(diào)整猿涨，流程的梳理晃择，難題解決等冀值。分享一下

一：技術(shù)中臺規(guī)劃

首先建立技術(shù)中臺肯定是需要有一個規(guī)劃的，沒有規(guī)劃的事情是不可能做好的宫屠。前一到二周的主要時間就是在分析技術(shù)中臺可以做的事情列疗。

后來參考了莉莉絲的聊天系統(tǒng)，發(fā)現(xiàn)聊天系統(tǒng)是一個比較獨(dú)立而且又比較通用并且還做不好容易出問題的系統(tǒng)浪蹂，而也考慮到以后可能需要各種不同的引擎來接入抵栈。所以我們打算做原生ios和android開發(fā)的聊天系統(tǒng)，參考的對象是莉莉絲坤次。

二：內(nèi)容梳理

要做這個系統(tǒng)首先要參考他們的聊天系統(tǒng)的結(jié)構(gòu)古劲，比如設(shè)計以及他們的通用方式，包括拆包缰猴，實(shí)機(jī)上手操作感受产艾，把他梳理成了一個可以細(xì)化開發(fā)的文檔。

三：人員招聘

接下來要看的是滑绒，既然我們要長期做中臺的事情闷堡，以及有了一個目標(biāo)。我們就需要人員來做疑故，然后接下來就是規(guī)劃需要的人員缚窿，比如ios開發(fā)，android開發(fā)焰扳，unity開發(fā)，服務(wù)器開發(fā)误续，策劃兼pm吨悍，測試。

這一套人員也是后面不斷的遇到問題解決問題而建立出比較穩(wěn)定輸出內(nèi)容的團(tuán)隊(duì)蹋嵌。

3.1

其中像程序相關(guān)的人員前期肯定是只有一個的育瓜，甚至前期我們只有ios開發(fā)和服務(wù)器開發(fā)來驗(yàn)證這個系統(tǒng)究竟能不能做好，有沒什么坑栽烂。然后確定沒問題了我們也招來了android一起開發(fā)躏仇。

3.2

前期驗(yàn)證系統(tǒng)的時候基本就這三個具體的開發(fā)在，但系統(tǒng)開發(fā)完成準(zhǔn)備對接游戲時腺办，我們發(fā)現(xiàn)如果沒有pm兼策劃焰手，我們的系統(tǒng)問題以及項(xiàng)目工期都很難去梳理，因?yàn)榍捌谑俏以谑崂砘澈恚捎诜植恳龅膬?nèi)容不是只有這個书妻，所以就需要一個pm兼策劃來對系統(tǒng)的需求挖掘以及項(xiàng)目工期的把控。

3.3

接著我們系統(tǒng)對接項(xiàng)目后躬拢，如果我們還是各只有一個開發(fā)人員躲履，項(xiàng)目趕一下是能做完见间，但是不夠牢固，因?yàn)槲覀円伎际欠裼锌赡苡袉T工離職的那天以及我們的梯隊(duì)建設(shè)工猜。那么自然我們需要各招一個開發(fā)米诉，讓ios和android以及服務(wù)器都有一個梯隊(duì)以及人員流失風(fēng)險降低。

3.4

然后我們發(fā)現(xiàn)如果沒有unity開發(fā)人員來整合系統(tǒng)篷帅，那么對其他unity的項(xiàng)目接入是需要一些成本的史侣，為了降低成本以及為了更好的整合sdk，我們選擇了一位unity開發(fā)兼做這一個整合的工作犹褒。這里順帶說一下抵窒，ios和android的系統(tǒng)開發(fā)還是有一定的差異的，所以接口上如果不溝通可能ios和android的交互方式會天差地別叠骑，所以前期一定一定一定要和ios及android確定對外的接口李皇。這種統(tǒng)一對項(xiàng)目也好，對sdk的維護(hù)也好都是極有好處的宙枷。

3.5

我們上線了一個版本到游戲后掉房，其實(shí)有發(fā)現(xiàn)我們的質(zhì)量有時還是不太有保障，策劃在這塊并不能起到測試的作用慰丛。然后我們招入了一個測試形成了一個開發(fā)的閉環(huán)卓囚。當(dāng)然測試除了做功能測試外，還需要做自動構(gòu)建工具方便（ios诅病，android哪亿，unity）出包。以及性能測試等贤笆。

3.6

然后我們?yōu)榱藴p少項(xiàng)目組的問題蝇棉，也梳理出了一套比較能控制質(zhì)量的流程：

以及我們還需要梳理開發(fā)測試流程，也就是我們在測試階段的解bug以及測試bug的節(jié)奏：

當(dāng)然還有很多細(xì)節(jié)芥永，比如多語言篡殷，適配，系統(tǒng)的縱向版本和橫向版本的區(qū)別等等埋涧。

四：開發(fā)閉環(huán)

然后閉環(huán)就產(chǎn)生了板辽。

五：閉環(huán)調(diào)整

5.1、

這里其實(shí)要提醒一個服務(wù)器開發(fā)這塊棘催，理想的對接當(dāng)然是一個方向的對接劲弦，也就是一個出入口，比如游戲就調(diào)用客戶端sdk的接口來確定所有事情醇坝。但是這個只是理想狀態(tài)瓶您，因?yàn)橛螒蛑杏泻芏鄶?shù)據(jù)是不希望暴露給外面的，而且如果是通過客戶端直接做，每次可能都要初始化非常多的數(shù)據(jù)（比如角色信息等）

所以我們服務(wù)器也做成了一個sdk呀袱，供給游戲服務(wù)器對接贸毕，這樣可以通過服務(wù)器同步數(shù)據(jù)給到我們中臺的服務(wù)器，那么我們中臺的客戶端只需要跟我們中臺服務(wù)器對接就可以了夜赵，也減少了很多接口明棍。這里主要要做的是同步問題，也就是信息需要同步給中臺寇僧。

5.2摊腋、

可能關(guān)注到游戲和中臺還有一條線寫著“需求落地”，這里的意思是如果我們只靠自己的想法來做嘁傀，其實(shí)不一定好落地兴蒸，因?yàn)橛螒虻木唧w想法跟我們的想法結(jié)合才是一個真實(shí)的需求，這種結(jié)合才是落地比較容易的方案细办。所以這里需要有一塊的流程橙凳。

六：登陸支付相關(guān)sdk

后來我們需要把公司以前的海外及國內(nèi)的登陸支付相關(guān)sdk也接過來做，一開始我們拿過來發(fā)現(xiàn)ios和android的對接接口完全不一樣笑撞，unity在ios和android上要做兩套不一樣的流程來支持岛啸，整體非常繁瑣，不利于維護(hù)茴肥。

我們選擇了重構(gòu)，重構(gòu)有兩個方向瓤狐，一個是讓登陸支付相關(guān)的所有sdk都可以單獨(dú)打包和整體打包兩種選擇，二是核對所有接口础锐，改成ios和android都統(tǒng)一的接口赴捞，三是unity做一層封裝郁稍，做成unitypackage胜宇，其他項(xiàng)目只需要對接unity相關(guān)接口即可（不是unity引擎的暫時需要自己對接，其實(shí)工作量也不大）桐愉。

接下里也是為了能迭代版本以及不會對老項(xiàng)目的sdk的影響，我們也梳理了版本管理方式从诲。

七：文檔整理以及中臺網(wǎng)站：

7.1、

我們有了sdk，但是不能讓各個項(xiàng)目都通過詢問接口或者詢問有什么功能來支撐略步，不然項(xiàng)目多了，我們就根本忙不過來了定页，所以我們需要梳理出接入文檔以及介紹，讓需要的人直接來查看文檔即可典徊。

7.2杭煎、

光有文檔其實(shí)還不足夠，因?yàn)檫@樣我們很難讓項(xiàng)目知道我們中臺有什么能力以及有什么更新了卒落，所以我們做了一個中臺網(wǎng)站羡铲，用來整合我們的能力展示以及api文檔。還有就是技術(shù)分享相關(guān)儡毕。

八：復(fù)盤：

我們復(fù)盤包括個人復(fù)盤也切，團(tuán)隊(duì)復(fù)盤以及項(xiàng)目復(fù)盤。

8.1妥曲、

個人復(fù)盤更多還是出現(xiàn)問題下立即跟相關(guān)人員討論問題贾费，讓他們知道問題的危害，及時改正檐盟。

8.2褂萧、

團(tuán)隊(duì)復(fù)盤就是我們會在每個迭代結(jié)束后就要開一次團(tuán)隊(duì)復(fù)盤會，把我們出現(xiàn)的問題都列出來一條一條解決葵萎，其實(shí)上面說了很多問題都是通過復(fù)盤形成一個更穩(wěn)固的流程來做到的导犹。

8.3、

項(xiàng)目復(fù)盤羡忘，這個更多是跟項(xiàng)目組一起討論的谎痢，如果是有更好的做法或者遇到問題我們都及時開會討論這個問題的解決思路。

九：新系統(tǒng)：

我們在做系統(tǒng)的維護(hù)以及開發(fā)的時候策劃就需要去挖新系統(tǒng)了卷雕，這些新系統(tǒng)是需要比較獨(dú)立而且經(jīng)常出現(xiàn)以及比較容易出問題的节猿。這些系統(tǒng)才是真的做中臺sdk的意義，如果簡單的或者不常用的或者不獨(dú)立的漫雕，項(xiàng)目組其實(shí)會選擇自己做滨嘱。

以及平時我們開發(fā)的時候要主動積累組件或者功能，比如尋路的浸间，物理的太雨，渲染的，這樣形成一些組件化的產(chǎn)品魁蒜，也能更快更好的賦能項(xiàng)目囊扳。

十：一些細(xì)節(jié)

之前遇到了一些問題以及解決方案吩翻，梳理一下。

1.開發(fā)客戶端和服務(wù)器锥咸，防止與項(xiàng)目耦合狭瞎，接口抽象化，寫對接文檔流程和sdk的api她君。

2.確定測試服務(wù)器和正式服務(wù)器脚作，并確定是集群還是單服，cdn相關(guān)的申請球涛，確定價格校镐。

3.確定線上bug的修復(fù)方式和流程。熱更方案从祝。

上線前準(zhǔn)備：

1.與項(xiàng)目組確定接入方式引谜，服務(wù)器sdk和客戶端sdk確定，并且確定api毒涧。

2.確定bug修復(fù)方式和流程贝室，確定熱更方式和流程。

3.服務(wù)器申請捡偏，服務(wù)器配置確定（幾臺服務(wù)器峡迷，什么配置，還需要加速線路彤避，加速是公司統(tǒng)一出錢）

4.翻譯文本確定（google翻譯需要跟公司確定成本看杭，如果超過字?jǐn)?shù)就限制不讓翻譯）

5.cdn申請并確定價格（盡量沿用項(xiàng)目組的方式）楼雹，費(fèi)用按流量計算，不夠了再加贮缅，以最低的標(biāo)準(zhǔn)先做。而且要記得做oss相關(guān)的資源清除的邏輯块茁，以免不斷撐大

6.如果是已經(jīng)上線的產(chǎn)品要數(shù)據(jù)遷移

7.瀏覽公司項(xiàng)目上線要求

8.版本管理方式数焊，比如定義0.0.1版本

9.圖片得上傳要審核或監(jiān)控崎场，不能有黃圖，要有舉報功能干厚，要有入口控制開關(guān)

10.外國網(wǎng)絡(luò)比較復(fù)雜螃宙，網(wǎng)絡(luò)可能會慢，所以客戶端需要輪詢?nèi)齻€地址挂捅，拿到速度最快的地址籍凝。

11.內(nèi)存占用問題苗缩，不能影響到游戲本身的內(nèi)存崩潰。

12.服務(wù)器和客戶端的接入說明以及更方便的接入方式

13.硬盤占用大小

14.接口不統(tǒng)一退盯，應(yīng)該再unitypackage這層控制統(tǒng)一接口

15.我們的決策和做法應(yīng)該要梳理流程泻肯，內(nèi)部討論完決策方案再找外部再討論來確定方案。

16.應(yīng)該我們這邊先要嘗試對接琉朽，看看有沒什么問題

17.要告訴原生開發(fā)meta相關(guān)要傳箱叁，unity的每個部分是什么東西，相當(dāng)于一個指導(dǎo)

18.清除緩存

19.bug應(yīng)該內(nèi)部先過一遍再給測試耕漱，并且我們要拿到測試用例。然后每次開發(fā)前都要和項(xiàng)目組確定做法灾梦，不然會有修改若河。

20.上線前需要保證代碼穩(wěn)定给郊，有大修改需要集體過一下

21.整體開發(fā)和測試流程需要確定下來

22.服務(wù)器弄開發(fā)環(huán)境，測試環(huán)境淆九，預(yù)發(fā)布環(huán)境，發(fā)布環(huán)境

23.要有網(wǎng)站讓其他項(xiàng)目知道我們有什么

24.oss要定義好容量

25.最后要確定所有都是正式環(huán)境下的內(nèi)容

26.需要嚴(yán)格自測后再給包給對方

27.需求要多方對齊饲窿，比如開發(fā)和策劃與第三方全方位對齊

28.測試流程要修改：先驗(yàn)收sdk功能模塊--->sdk功能模塊完成驗(yàn)收--->與其他系統(tǒng)交叉測試-->完成驗(yàn)收逾雄。測試用例要給到開發(fā)確定腻脏。

29.要做好熱更的計劃

30.還要考慮體驗(yàn)的問題，輸出的環(huán)節(jié)要加上體驗(yàn)環(huán)節(jié)

中臺兩個方向：

1.組件化各種能力做鹰，然后放網(wǎng)站上供公司參考

2.挖掘更多公司類似游戲的玩法鼎姐，參考各種公司的類似游戲炕桨，然后與項(xiàng)目組溝通確定落地方案。

十一：中臺的意義

中臺存在的意義是為了讓公司的項(xiàng)目能夠更專注開發(fā)核心功能钥平，加快開發(fā)進(jìn)度以及賦能技術(shù)姊途。如果我們做不到賦能項(xiàng)目反而是影響項(xiàng)目進(jìn)度奈惑，那么中臺的存在意義是不強(qiáng)的。