心得
看了這篇才知道可以用CEF來開發Desktop Client,Java Script統一所有前端的浪潮還在持續呀。最後講到了”datacenter in a desktop.”也蠻有趣的,Plugin架構雖然不是什麼新觀念,但卻可以很好的解決他們遇到的問題,以後遇到可以參考一下。話說回來,要寫個windows client要同時寫C++與Java Script,好像有點OOXX,不過這是因為他們不想連遠端Server的實作都改的折衷方案,畢竟Client整修失敗,就把舊的拿出去用就好,Server整修失敗,就….
筆記
- 主要就是談:the League client update,進遊戲之前的Client Application
- 原本使用Adobe AIR,使用它的RTMP協定,動畫呈現,而且還是跨「桌機」平台。遊戲推出的當下,可說是很好的解決方案,不過接下來就開始不合時代潮流,因此要做新架構
- 新架構要解決的:
- 用HTML5+JavaScript的解決方案,不管是在client端呈現,或是與Server溝通,還有工作流程與開發環境都比原本更有擴充性且易用。
- 不管是遊戲內遊戲外,玩家都可以保持連線:原本Adobe AIR的方案對PC資源使用率過大,也不支援手機。
- 工程師們想要有個更簡單一致的開發架構。
- 一開始想要改少一點,想說直接重用Adobe AIR的code來搞,但發覺現在已經有更多更好的方案。
- 後來選擇了 Chromium Embedded Framework (CEF) ,寫Desktop Client就像是寫網頁。對HTML 5有很好的支援,而且界面修改自訂可以更靈活。
- 決定重寫(!),重寫很危險,但好處比壞處多就上。
Step A
- 所以Client界面主要就是Java Script
- 為了要讓Java Script與原本的Server溝通,原本Server是支援RTMP,所以他們為Java Script Client開發了一個C++原生Library,負責用RTMP與Server溝通,以及提供非同步的處理。
- 為什麼Server還是用RTMP?因為不想同時Client與Server。
- 選擇ember.js當Java Script Client框架,ember-orbit當作資料層
- 看起來架構還不賴?問題馬上出現了。
- Java Script Client變得非常複雜,裡面的元件各自處理非同步的部份,使用者的狀態也保留在Java Script Client這一層(!),所以記憶體變得很大。
- 這個方案解決1.但是2.與3.都沒有處理好,而且Developer抱怨連連。
Step B
- 開始思考一般Web Application是怎麼做的,反正都用Java Script了,來向一般Web Application取經
- 發現少了中間層!
- 所以弄了個C++寫的micro service層,但是在本地端!
- micro service層就像是http server,按照REST的規則來提供資源存取,讓Java Script Client不要處理非同步(複雜度的主因)。
- micro service層與Java Script Client層用Web Socket溝通,micro service層與遠端Server還是用原來的RTMP溝通
- micro service層取名叫Foundation
- 弄成這個架構之後,精簡掉所有不必要的Java Script VMs,只留下Foundation,Java Script Client都只用GET
- Foundation大概佔用20MB記憶體,玩家不需要把Java Script Client砍掉才進LOL裡面!
- Foundation可以用system tray來呈現,不管玩家有沒有打開LOL都可以接觸到遊戲資訊。
Step C
- 換成新架構後,寫功能就是要寫micro service與遠端server,micro service與Java Script Client。
- 大家都改同樣的地方,互相影響。
- 需要架構上的解決方案來讓團隊協作更有效率。
- 作者自己研究了許久,決定採用Plug-in架構
- 每個Plug-in必須有自己的Semantic Versioning,還有它依賴哪個Plug-in與這個Plug-in的Semantic Versioning。
- 把架構呈現成Graph的形式,Plug-in的相依性一目了然
- 所以有front-end (FE) plugin,用Java Script,實作UI。有back-end (BE) plugin,用C++,實作資料處理與遠端Server溝通。
- 取名叫Front-end與Backend是代表這個架構模仿所謂的Client-Server架構
- 用Plug-in可以簡單開關使用者可用的功能,通常是不同區域的使用者。
- 由於之前用ember-orbit,Front-end還是可以直接操作很多資料,又增加複雜到,所以讓ember-orbit退休,資料都透過REST從back-end plugin拿,front-end plugin可以快取資料,但其他複雜資料的處理就不要在Front-end了。
Step D
- 已經有了更有生產力的架構,大家可以各自做自己的Plugin不會互相影響。
- 有些人不喜歡Ember.js,想直接用HTML 5的東西。
- 有些人在別的地方已經有了現成的Web Client,想說直接搬到這個Java Script Client,這樣就不用重作一次Client,反正都是Java Script。
- 本來很堅持來這邊開發就一定要用Ember.js,後來發現,就算每個Plug-in都用Ember.js,要保持每個Plug-in的Ember.js的版本相同,也很困難,公司太多Developer了。
- 最後改成每個Plugin都可以用自己的Java Script Framwork
結論
- 最後的架構,可以讓多個團隊獨立的開發the League client update,HTML5 Front-end與C++ back-end的配合夠靈活效能也夠好。Plug-in架構不只對開發有幫助,對實際產品呈現也有幫助。
- 大部分人都很滿意!
- 回頭來看,這就是一種”datacenter in a desktop.”的架構,Atom就是如此。
- 還有HTML視覺效果,功能可以獨立更新發布還沒講。