一加 Ace 5系列將搭載全新游戲助手:大幅提升游戲體驗東芝全部業(yè)務(wù)實現(xiàn)盈利,退市裁員重組后終于賺錢真我14 Pro+開始提上日程:1.5K等深四微曲屏+潛望長焦穩(wěn)了消息稱本田和日產(chǎn)計劃明年6月前敲定合并協(xié)議 2026年8月成立控股公司凱迪拉克最新版OTA開啟推送,新增百度語音大模型和QQ音樂等應(yīng)用中國聯(lián)通11月5G套餐用戶凈增127.8萬戶5G確定性工業(yè)基站首商用,工業(yè)互聯(lián)網(wǎng)走上新高度李飛飛團隊前瞻性研究 多模態(tài)AI模型初顯空間智能AI終于邁過這道檻!Livekit 開源模型精準(zhǔn)識別“你是否說完”!DeepSeek開源大模型開發(fā)者之一羅福莉?qū)⒓用诵∶?/a>廣汽詳解旗下首款復(fù)合翼飛行汽車 GOVY AirJet:最高飛行速度可達(dá) 250km/h清華大學(xué)聯(lián)合騰訊出品!ColorFlow:自動給黑白漫畫上色,保持角色一致性Adobe推新AI音頻具Sketch2Sound ,只需哼唱和模仿聲音就能創(chuàng)建音效家庭能源智聯(lián)自由 海辰儲能發(fā)布首套免安裝家庭微網(wǎng)系統(tǒng)HeroESOpenAI發(fā)布o(jì)3:AI 推理能力的重大突破,得分高達(dá)87.5%亞馬遜云科技推出Amazon Q Developer新功能小象超市,摸著美團外賣出海E Ink元太科技連三年入選道瓊可持續(xù)雙指數(shù)撬動6000億GTV后,抖音計劃偷襲美團大本營AGI Open Network(AON):賦能每個人創(chuàng)建、部署和貨幣化AI Agent
  • 首頁 > 產(chǎn)經(jīng)新聞頻道 > 業(yè)界新聞

    環(huán)信IM Unity SDK 2.0正式發(fā)布,大大提升開發(fā)效率

    2021年08月25日 10:33:39   來源:中文科技資訊

      引言

      Untiy作為游戲引擎和內(nèi)容開發(fā)平臺,吸引了眾多游戲開發(fā)者,基于其開發(fā)的游戲更是不勝其數(shù)。具體請參見1。

    1.jpg

      環(huán)信作為領(lǐng)先的即時通訊云服務(wù)商,在游戲行業(yè)也進行了持續(xù)的探索和研發(fā)投入。在產(chǎn)品發(fā)布的早期(2015年)就推出了Unity SDK,幫助游戲開發(fā)者快速實現(xiàn)游戲場景下諸如世界頻道,游戲公會、組隊群聊,1對1私聊等功能,安全穩(wěn)定的服務(wù)也為游戲玩家?guī)砹藰O佳的實時溝通體驗。

      2021年第二季度,環(huán)信IM Unity SDK進行了重構(gòu)改版,環(huán)信IM Unity SDK 2.0正式發(fā)布,主要改進包括如下:

      1、迭代更新,更加實用的API接口

      2、IM+Push增強功能的補全

      3、C#語言層面引入了版本7.0 – 9.0之后的一些新語法改進

      4、特別的,增加了PC端Unity Editor環(huán)境下編譯調(diào)試支持,大大提升了開發(fā)效率

      在過去的一段時間里,筆者也參與了相應(yīng)的研發(fā)工作。在整個過程中,為了解決各種問題,不僅要到處翻閱資料,還要嘗試各種方法和參數(shù)組合。其間也經(jīng)歷了各種程序崩潰甚至系統(tǒng)崩潰,詭異的程序表現(xiàn)一次次讓開發(fā)人員束手無策,四處碰壁,當(dāng)真像深夜里行走在迷宮之中,手里還拿著一個待破解的魔方。“此路不通,請繞行!”,是在一次次的嘗試后無奈的慨嘆和難舍的放棄。而一旦問題最后得到圓滿解決,又宛如飛入云端,以上帝視角俯瞰一片片迷宮,一切又顯得那么理所當(dāng)然,繁復(fù)瑣細(xì)但又絲絲入扣,這樣的苦盡甘來也算是做程序員能享受到的巨大喜悅和滿足。

      不敢獨享,特記錄下一些心得供大家參考,也歡迎.NET平臺資深玩家批評指正。以下,Enjoy!

      開發(fā)概覽:非托管插件開發(fā)(Native/Unmanaged Plugin)

      Unity是基于Microsoft .Net Framework開發(fā)的游戲引擎2,它采用了開源的.NET Platform,并依賴此框架來實現(xiàn)跨硬件設(shè)備和運行時(操作系統(tǒng))的目標(biāo),也是所謂的”Write once, run anywhere”。在語言方面,Unity選擇C#作為主要的腳本編程語言,雖然.NET平臺本身支持的語言有很多種。

      進一步,Unity支持Mono和ILC2PP兩種腳本框架(Scripting Backends)。特別的,Unity Editor采用的是Mono腳本框架。

      一般的,游戲類庫開發(fā)者可以選擇直接用C#語言開發(fā),目標(biāo)類庫可以實現(xiàn)基于.NET Framework基礎(chǔ)功能之上的高級功能,這類插件稱之為Managed Plugin(托管插件)。由于環(huán)信IM核心SDK已經(jīng)基于C++開發(fā),因此我們選擇另一種Native Plugin(本地插件)的方式,正是它把我們引向了迷宮之旅。兩種類型的Plugin介紹,參見3。

      不幸的是,Unity網(wǎng)站上關(guān)于Native Plugin的相關(guān)介紹少只又少,想要了解它的具體細(xì)節(jié)還要去參考Microsoft MSDN文檔。作為中規(guī)中矩的文檔介紹,微軟的文檔是合格的,但是,當(dāng)你真正上手編程時就會發(fā)現(xiàn),這些遠(yuǎn)遠(yuǎn)不夠:下面記錄的一些坑點就很難在相應(yīng)的文檔中得到直接的提示;而要通過Google大法,結(jié)合其他程序員留下的蛛絲馬跡,再加上自己不斷的調(diào)試來最終確認(rèn)。

      在微軟文檔上下文中,Unity Native Plugin有個另外的名字:Unmanaged Plugin,即非托管插件。簡單來講,Managed Plugin生存在.NET Framework的運行時環(huán)境(類似于Java的JVM),而Unmanaged Plugin則生存在這個運行時環(huán)境之外,也即和運行時環(huán)境是兄弟的關(guān)系。如果你原本的類庫實現(xiàn)滿足微軟的COM(Component Object Model)規(guī)范,那自然最好是使用COM Interop4的互操作方式;而環(huán)信IM SDK本身是純C++實現(xiàn),因此采用了Platform Invoke5(簡稱P/Invoke)方式,本文剩下的內(nèi)容均是基于P/Invoke。

      下圖則概要描述了Managed和Unmanaged區(qū)域代碼之間互相操作的方式:

      更具體的,為了實現(xiàn)對于Unmanaged DLL function的調(diào)用,只需要簡單的4步6:

      1、確認(rèn)DLL類庫中需要被操作的函數(shù);

      2、創(chuàng)建一個C#類來關(guān)聯(lián)被操作的這些函數(shù)(給函數(shù)穿上一個馬甲,以便集中管理和反復(fù)調(diào)用);

      3、使用DllImport標(biāo)志在受管側(cè)(C#)定義函數(shù)原型;

      4、在受管側(cè)隨意調(diào)用相關(guān)非托管區(qū)域函數(shù)。

      上圖中,Standard marshalling service即負(fù)責(zé)將數(shù)據(jù)在兩個區(qū)域進行封裝/解封裝傳送(marshall/unmarshall),它主要定義了數(shù)據(jù)在兩個不同內(nèi)存區(qū)域進行拷貝(Copy)和引用(Reference)的規(guī)則7,而迷宮中的坑主要是和這些具體規(guī)則有關(guān)。

      坑王駕到之封送(Marshall/Unmarshall)中的那些坑

      坑一:sizeof(bool) = ?

      絕大多數(shù)的基本類型屬于Blittable Types8:如System.Byte, System.Single等。System.Boolean雖然不屬于Blittable types,但是Standard Marshalling Service默認(rèn)將其轉(zhuǎn)換為1,2,4字節(jié)的內(nèi)存存儲,當(dāng)其值為true時,其對應(yīng)的值為1。如果你想當(dāng)然的直接將System.Boolean映射到Unmanaged側(cè)的bool類型而不做特別處理的話,你并一定會理解碰到編譯或者運行時錯誤,但是如果你嚴(yán)格的測試每個字段是,會驚訝的發(fā)現(xiàn)這些bool值跟你想象的不盡相同:有時正確,有時錯誤。

      經(jīng)過調(diào)試跟蹤,動態(tài)打印sizeof(bool)來確認(rèn)Unmanaged側(cè)bool類型數(shù)據(jù)長度后,你會發(fā)現(xiàn)System.Boolean默認(rèn)會被保存為4個字節(jié)長度,而在macOS環(huán)境下(對于其它環(huán)境,需要自行認(rèn)證),C++定義的bool其實只有一個字節(jié)。因此當(dāng)你在Unmanaged側(cè)取bool值的時候,其實只讀取了System.Boolean的1/4個字節(jié)而已。而當(dāng)你聲明了多個連續(xù)的System.Boolean/bool值時,可能在Unmanaged側(cè)讀取的這幾個bool值僅僅是第一個System.Boolean值的不同偏移字節(jié)而已。

      知道了原因,解決方案自然就出來了,在Managed側(cè)強制聲明System.Boolean字段封送到Unmanaged側(cè)時僅使用一個字節(jié):

      [MarshallAs(UnmanagedType.U1)]public bool TrueOrFalse;

      坑二:字節(jié)對齊

      對于C++開發(fā)者來說,可能知道當(dāng)一個數(shù)據(jù)結(jié)構(gòu)(class or struct)中的各字段在內(nèi)存中進行排列時,會按照一個設(shè)定的裝箱長度進行字節(jié)對齊,例如:

      struct MyStruct {

      int one;

      short two;

      int three;

      bool four;

      }

      假設(shè)在我們的平臺上,sizeof(int)=4, sizeof(short)=2, sizeof(bool)=1, 如果問你sizeof(MyStruct)=?,你可能會馬上做個加法得到答案,但是答案不一定對。It depends! 假設(shè)我們是按照4個字節(jié)對齊,這上面的結(jié)構(gòu)體在內(nèi)存中實際排列如下圖:

      了解這個對于我們編碼有兩個意義:

      1、通過合理排列字段聲明順序來優(yōu)化存儲效率,內(nèi)存布局中不留空洞;

      2、MarshalAsAttribute支持Layout.Explicit來進行絕對定位,懂得了字節(jié)對齊可以配合Unmanaged側(cè)的內(nèi)存排列規(guī)則以保證字段長度映射正確,不然同樣會發(fā)生字段長度不一致帶來的困擾。

      坑三:如何避免Double Free

      Standard Marshalling Service/Interop marshaller總是試圖釋放Unmanaged側(cè)代碼分配的內(nèi)存9,這會帶來Double Free的問題,如果碰到這種問題,程序就會直接崩潰。

      引用資料中舉了以下例子:

      BSTR MethodOne (BSTR b) {

      return b;

      }

      如果這段代碼直接從Unmanaged側(cè)DLL中直接執(zhí)行,不會發(fā)生任何額外的內(nèi)存釋放;但是當(dāng)你從Managed側(cè)調(diào)用這個方法時,b會被釋放兩次。

      而更讓人抓狂的是,并沒有相應(yīng)的信息提示究竟是哪個指針,哪個字段被Double Free了,你唯一能做的就是一點點加代碼來驗證自己猜測。所以,嚴(yán)格來說,并沒有一個萬無一失的方案來避免Double Free,你唯一能做的就是通過測試來驗證結(jié)果(有點盲擰魔方的味道了)。

      有兩個基本的方法來解決Double Free的問題:

      1、按照官方文檔建議,在Unmanaged側(cè)通過使用CoTaskMemAlloc來分配內(nèi)存,通過此種方法分配的內(nèi)存,除非顯式調(diào)用了CoTaskMemFree方法(在Unmanaged側(cè)或者Managed側(cè)均可以調(diào)用),Interop Marshaller會嚴(yán)格保證不去釋放該內(nèi)存。使用這種方法可以靈活的在任意一側(cè)分配內(nèi)存,并在合適的時候在另一側(cè)釋放內(nèi)存。

      2、但上面這種方法貌似僅適用于Windows平臺,在macOS下沒有辦法使用(需要引用win32base.dll相關(guān)實現(xiàn))。在macOS下僅能通過在Mananged側(cè)調(diào)用Marshal.AllocCoTaskMem()方法分配內(nèi)存,并通過Marshal.FreeCoTaskMem()來在同一側(cè)進行釋放(按照此方法分配的內(nèi)存指針傳入Unmanaged側(cè)后,不要進行任何釋放即可)。另外有一個不太可靠的workaround是:在Unmanaged一側(cè)創(chuàng)建的內(nèi)存指針盡量通過IntPtr傳遞,并在可能的時候?qū)ο笾幸恍┲羔橆愋偷膶傩灾抵每,以避免Double Free的發(fā)生。

      坑四:virtual函數(shù)帶來的內(nèi)存布局變化

      vptr和vtable是C++的一個概念:當(dāng)你定義的類型中有虛函數(shù)存在時,內(nèi)存對象的第一個位置會存放一個vptr指針,該指針指向vtable(虛函數(shù)表)。因此當(dāng)你開始創(chuàng)建的自定義類型一開始沒有虛函數(shù)時(包括虛析構(gòu)函數(shù)virtual ~MyClass()),一切運行正常。有一天你重構(gòu)此類型,增加了一些虛函數(shù):DUANG,一切都崩塌了!原因就在于Unmanaged側(cè)內(nèi)存對象的排列規(guī)則變了,原有的對象字段都被新加入的vptr往后面移位了。此時可能你唯一能做的就是通過Layout.Explicit來手工對齊每一個字段新的位置。

      其它坑

      坑一:針對M1芯片編譯

      對于M1芯片的macOS系統(tǒng),編譯環(huán)信IM Unity SDK時候需要注意幾個問題:

      1、XCode編譯時需要Excluded Architecture中排除arm64架構(gòu)(很奇葩的設(shè)置,不是應(yīng)該排除x86嗎?)

      2、類庫的依賴解決:通過otool -L命令來確認(rèn)相應(yīng)的plugin依賴的類庫位置都正確(文件路徑下文件確實存在),如果相應(yīng)文件不存在要手工拷貝文件到指定目錄:而新的macOS安全架構(gòu)限制了往系統(tǒng)目錄下(如/usr/lib)進行任何改動,一個臨時的解決方法是通過install_name_tool工具主動修改類庫依賴路徑到另一個可以放置新文件的位置(如home目錄)。

      坑二:Delegate的正確使用姿勢

      如果Managed側(cè)的編程語言是C#,則Delegate是實現(xiàn)回調(diào)的重要手段。在Unmanaged側(cè)完成期望工作時回調(diào)一個FunctionPtr即可實現(xiàn)通用的回調(diào)模式,而此FunctionPtr正是對應(yīng)到Managed側(cè)的Delegate。當(dāng)你的Delegate綁定到一個類對象上時,你有兩種選擇:

      namespace ChatSDK {

      //delegate definition

      public void delegate OnMessageReceived(EMMessage message);

      public class MyDelegate {

      //Option 1: field

      public OnMessageReceived MyMessageReceived;

      //Option 2: instance method

      public void OnMessageReceived(EMMessage message)

      {

      ...

      }

      }

      //send delegate method to unmanaged side

      MyDelegate md = new();

      NativeMethods.SetOnMessageReceivedCallback(md.MyMessageReceived); //option 1

      NativeMethods.SetOnMessageReceivedCallback(md.OnMessageReceived); //option 2

      }

      看起來兩個方式都沒有問題,并且第二個方式看起來更順眼。但是這里隱藏著一個很深的坑,就是你選擇第二個方式的時候,如果你在回調(diào)方法實現(xiàn)中采用this.xxx方式引用時,你會發(fā)現(xiàn)this = null!這是因為當(dāng)你使用這種方式傳遞一個對象的方法作為回調(diào)方法指針時,其實已經(jīng)丟失了Delegate.Target(也就是this)屬性。而通過第一種方式傳遞的是一個對象的屬性/字段,它和對象本身的綁定是不會在傳遞過程中丟失的。

      至于該Delegate字段的定義可以在此類的構(gòu)造函數(shù)中通過以下方式實現(xiàn):

      ...

      public MyDelegate() {

      MyMessageReceived = (EMMessage message) => { ... }

      }

      ...

      參考資料

      1、List of Unity Games: https://en.wikipedia.org/wiki/List_of_Unity_games

      2、Unity and .NET: https://docs.unity3d.com/Manual/overview-of-dot-net-in-unity.html

      3、Unity Scripting-Plugins: https://docs.unity3d.com/Manual/Plugins.html

      4、COM Interop: https://docs.microsoft.com/en-us/dotnet/standard/native-interop/cominterop

      5、Platform Invoke: https://docs.microsoft.com/en-us/dotnet/standard/native-interop/pinvoke

      6、如何調(diào)用Unmanaged DLL Functions:https://docs.microsoft.com/en-us/dotnet/framework/interop/consuming-unmanaged-dll-functions

      7、Interop Marshalling:https://docs.microsoft.com/en-us/dotnet/framework/interop/interop-marshaling

      8、Blittable Types: https://docs.microsoft.com/en-us/dotnet/framework/interop/blittable-and-non-blittable-types

      9、Double Free: https://docs.microsoft.com/en-us/dotnet/framework/interop/default-marshaling-behavior

      文章內(nèi)容僅供閱讀,不構(gòu)成投資建議,請謹(jǐn)慎對待。投資者據(jù)此操作,風(fēng)險自擔(dān)。

    [No. X016-1]
    分享到微信

    即時

    新聞

    明火炊具市場:三季度健康屬性貫穿全類目

    奧維云網(wǎng)(AVC)推總數(shù)據(jù)顯示,2024年1-9月明火炊具線上零售額94.2億元,同比增加3.1%,其中抖音渠道表現(xiàn)優(yōu)異,同比有14%的漲幅,傳統(tǒng)電商略有下滑,同比降低2.3%。

    企業(yè)IT

    重慶創(chuàng)新公積金應(yīng)用,“區(qū)塊鏈+政務(wù)服務(wù)”顯成效

    “以前都要去窗口辦,一套流程下來都要半個月了,現(xiàn)在方便多了!”打開“重慶公積金”微信小程序,按照提示流程提交相關(guān)材料,僅幾秒鐘,重慶市民曾某的賬戶就打進了21600元。

    3C消費

    華碩ProArt創(chuàng)藝27 Pro PA279CRV顯示器,高能實力,創(chuàng)

    華碩ProArt創(chuàng)藝27 Pro PA279CRV顯示器,憑借其優(yōu)秀的性能配置和精準(zhǔn)的色彩呈現(xiàn)能力,為您的創(chuàng)作工作帶來實質(zhì)性的幫助,雙十一期間低至2799元,性價比很高,簡直是創(chuàng)作者們的首選。

    研究

    中國信通院羅松:深度解讀《工業(yè)互聯(lián)網(wǎng)標(biāo)識解析體系

    9月14日,2024全球工業(yè)互聯(lián)網(wǎng)大會——工業(yè)互聯(lián)網(wǎng)標(biāo)識解析專題論壇在沈陽成功舉辦。