開場(chǎng)很多 Unity 開發(fā)者在性能調(diào)優(yōu)時(shí)都會(huì)遇到一個(gè)疑問：調(diào)用Transform.Translate這種高頻 API 時(shí)，是不是每次都要穿越 C# 與 C++ 的邊界？答案是肯定的，而且開銷遠(yuǎn)比你想象的小。當(dāng)你在 C# 腳本里寫下transform.Translate(1, 0, 0)，這個(gè)方法并沒有托管實(shí)現(xiàn)——它會(huì)直接跳轉(zhuǎn)到引擎底層的 C++ 函數(shù)。這個(gè)跨語言跳轉(zhuǎn)對(duì)開發(fā)者幾乎透明，背后靠的是一套啟動(dòng)期建立的注冊(cè)與查找機(jī)制：ICall（Internal Call）。理解這套機(jī)制有三個(gè)實(shí)際收益：一是能正確評(píng)估"托管/原生邊界"的真實(shí)開銷，不再憑直覺誤判性能熱點(diǎn)；二是能讀懂 Unity 托管層源碼（UnityCsReference）里大量沒有方法體的extern聲明；三是寫自定義原生插件時(shí)，知道哪條路是官方支持的、哪條是內(nèi)部通道。一、核心概念：一張啟動(dòng)期建好的映射表ICall 是 Mono/IL2CPP 運(yùn)行時(shí)提供的"托管調(diào)原生"通道。它的本質(zhì)是一張哈希映射表：鍵是 C# 方法的完整簽名（含命名空間），值是 C++ 函數(shù)指針。這張表在引擎啟動(dòng)早期一次性建好，之后每次跨語言調(diào)用就是一次 O(1) 查表加一次直接的函數(shù)調(diào)用。1.1 托管側(cè)：只有聲明，沒有方法體C# 側(cè)被原生實(shí)現(xiàn)的方法有兩個(gè)標(biāo)志：extern關(guān)鍵字，以及[MethodImpl(MethodImplOptions.InternalCall)]特性。開發(fā)者只寫聲明——因?yàn)閷?shí)現(xiàn)根本不在托管