Unity3d--跨平台（一）
轉自：https://www.cnblogs.com/murongxiaopifu/p/4211964.html
前言：
其實小匹夫在U3D的開發中一直對U3D的跨平臺能力很好奇。到底是什么原理使得U3D可以跨平臺呢？后來發現了Mono的作用，并進一步了解到了CIL的存在。所以，作為一個對Unity3D跨平臺能力感興趣的U3D程序猿，小匹夫如何能不關注CIL這個話題呢？那么下面各位看官就拾起語文老師教導我們的作文口訣（Why，What，How），和小匹夫一起走進CIL的世界吧~
Why?
回到本文的題目，U3D或者說Mono的跨平臺是如何做到的？
如果換做小匹夫或者看官你來做，應該怎么實現一套代碼對應多種平臺呢？
其實原理想想也簡單，生活中也有很多可以參考的例子，比如下圖（誰讓小匹夫是做移動端開發的呢，只能物盡其用從自己身邊找例子了T.T）：
像這樣一根線，管你是安卓還是ios都能充電。所以從這個意義上，這貨也實現了跨平臺。那么我們能從它身上學到什么呢？對的，那就是從一樣的能源（電）到不同的平臺（ios，安卓）之間需要一個中間層過度轉換一下。
那么來到U3D為何能跨平臺，簡而言之，其實現原理在于使用了叫CIL（Common Intermediate Language通用中間語言，也叫做MSIL微軟中間語言）的一種代碼指令集，CIL可以在任何支持CLI（Common Language Infrastructure，通用語言基礎結構）的環境中運行，就像.NET是微軟對這一標準的實現，Mono則是對CLI的又一實現。由于CIL能運行在所有支持CLI的環境中，例如剛剛提到的.NET運行時以及Mono運行時，也就是說和具體的平臺或者CPU無關。這樣就無需根據平臺的不同而部署不同的內容了。所以到這里，各位也應該恍然大了。代碼的編譯只需要分為兩部分就好了嘛：
What？
上文也說了CIL是指令集，但是不是還是太模糊了呢？所以語文老師教導我們，描述一個東西時肯定要先從外貌寫起。遵循老師的教導，我們不妨先通過工具來看看CIL到底長什么樣。
工具就是ildasm了。下面小匹夫寫一個簡單的.cs看看生成的CIL代碼長什么樣。
C#代碼：
class Class1 {public static void Main(string[] args){System.Console.WriteLine("hi");} }CIL代碼：
.class private auto ansi beforefieldinit Class1extends [mscorlib]System.Object {.method public hidebysig static void Main(string[] args) cil managed{.entrypoint// 代碼大小 13 (0xd).maxstack 8IL_0000: nopIL_0001: ldstr "hi"IL_0006: call void [mscorlib]System.Console::WriteLine(string)IL_000b: nopIL_000c: ret} // end of method Class1::Main .method public hidebysig specialname rtspecialname instance void .ctor() cil managed{// 代碼大小 7 (0x7).maxstack 8IL_0000: ldarg.0IL_0001: call instance void [mscorlib]System.Object::.ctor()IL_0006: ret} // end of method Class1::.ctor } // end of class Class1好啦。代碼雖然簡單，但是也能說明足夠多的問題。那么和CIL的第一次親密接觸，能給我們留下什么直觀的印象呢？
直觀的印象有了，但是離我們的短期目標，說清楚（或者說介紹個大概）CIL是What，甚至是終極目標，搞明白Uniyt3D為何能跨平臺還有2萬4千9百里的距離。
好啦，話不多說，繼續亂侃。
參照附錄中的操作碼表，對照可以總結出一份更易讀的表格。那就是如下的表啦。
| 主要操作 | 操作數范圍/條件 | 操作數類型 | 操作數 | |||||||||
| 縮寫 | 全稱 | 含義 | 縮寫 | 全稱 | 含義 | 縮寫 | 全稱 | 含義 | 縮寫 | 全稱 | 含義 | |
| ld | load | 將操作數壓到堆棧當中，相當于： push ax | arg | argument | 參數 | ? | ? | 操作數中的數值 | .0 | ? | 第零個參數? | |
| .1 | ? | 第一個參數 | ||||||||||
| .2 | ? | 第二個參數 | ||||||||||
| .3 | ? | 第三個參數 | ||||||||||
| .s xx | (short) | 參數xx | ||||||||||
| a | address | 操作數的地址 | 只有 .s xx，參見ldarg.s | |||||||||
| loc | local | 局部變量 | 參見ldarg | |||||||||
| fld | field | 字段（類的全局變量） | 參見ldarg | xx | ? | xx字段，eg: ldfld xx | ||||||
| c | const | 常量 | .i4 | int 4 bytes | C#里面的int，其他的類型例如short需要通過conv轉換 | .m1 | minus 1 | -1 | ||||
| .0 | ? | 0 | ||||||||||
| .1 | ? | 1 | ||||||||||
| …… | ||||||||||||
| .8 | ? | 8 | ||||||||||
| .s | (short) | 后面跟一個字節以內的整型數值（有符號的） | ||||||||||
| ? | ? | 后面跟四個字節的整型數值 | ||||||||||
| .i8 | int 8 bytes | C#里面的long | ? | ? | 后面跟八個字節的整型數值 | |||||||
| .r4 | real 4 bytes | C#里面的float | ? | ? | 后面跟四個字節的浮點數值 | |||||||
| .r8 | real 8 bytes | C#里面的double | ? | ? | 后面跟八個字節的浮點數值 | |||||||
| null | null | 空值（也就是0） | ? | ? | ? | ? | ? | ? | ||||
| st | store | 計算堆棧的頂部彈出當前值，相當于： pop ax | 參見ld? | |||||||||
| conv | convert | 數值類型轉換，僅僅用純粹的數值類型間的轉換，例如int/float等 | ? | ? | ? | .i1 | int 1 bytes | C#里面的sbyte | ? | ? | ? | |
| .i2 | int 2 bytes | C#里面的short | ||||||||||
| .i4 | int 4 bytes | C#里面的int | ||||||||||
| .i8 | int 8 bytes | C#里面的long | ||||||||||
| .r4 | real 4 bytes | C#里面的float | ||||||||||
| .r8 | real 8 bytes | C#里面的double | ||||||||||
| .u4 | uint 4 bytes | C#里面的uint | ||||||||||
| .u8 | uint 8 bytes | C#里面的ulong | ||||||||||
| b/br | branch | 條件和無條件跳轉，相當于： jmp/jxx label_jump | br | ? | ? | 無條件跳轉 | ? | ? | ? | ? | ? | 后面跟四個字節的偏移量（有符號） |
| .s | (short) | 后面跟一個字節的偏移量（有符號） | ||||||||||
| false | false | 值為零的時候跳轉 | ? | ? | ? | 參見br | ||||||
| true | true | 值不為零的時候跳轉 | ? | ? | ? | |||||||
| b | eq | equal to | 相等 | ? | ? | ? | ||||||
| ne | not equal to | 不相等 | un | unsigned or unordered | 無氟好的（對于整數）或者無序的（對于浮點） | |||||||
| gt | greater than | 大于 | ||||||||||
| lt | less than | 小于 | ||||||||||
| ge | greater than or equal to | 大于等于 | ||||||||||
| le | less than or equal to | 小于等于 | ||||||||||
| call | call | 調用 | ? | ? | ? | ? | ? | （非虛函數） | ? | |||
| ? | ? | ? | virt | virtual | 虛函數 | |||||||
在此，小匹夫想請各位認真讀表，然后心中默數3個數，最后看看都能發現些什么。
基于堆棧
如果是小匹夫的話，第一感覺就是基本每一條描述中都包含一個”棧“。不錯,CIL是基于堆棧的，也就是說CIL的VM（mono運行時）是一個棧式機。這就意味著數據是推入堆棧，通過堆棧來操作的，而非通過CPU的寄存器來操作，這更加驗證了其和具體的CPU架構沒有關系。為了說明這一點，小匹夫舉個例子好啦。
大學時候學單片機（大概是8086，記不清了）的時候記得做加法大概是這樣的：
add eax,-2其中的eax是啥？寄存器。所以如果CIL處理數據要通過cpu的寄存器的話，那也就不可能和cpu的架構無關了。
當然，CIL之所以是基于堆棧而非CPU的另一個原因是相比較于cpu的寄存器，操作堆棧實在太簡單了。回到剛才小匹夫說的大學時候曾經學過的單片機那門課程上，當時記得各種寄存器，各種標志位，各種。。。，而堆棧只需要簡單的壓棧和彈出，因此對于虛擬機的實現來說是再合適不過了。所以想要更具體的了解CIL基于堆棧這一點，各位可以去看一下堆棧方面的內容。這里小匹夫就不拓展了。
面向對象
那么第二感覺呢？貌似附錄的表中有new對象的語句呀。嗯，的確，CIL同樣是面向對象的。
這意味著什么呢？那就是在CIL中你可以創建對象，調用對象的方法，訪問對象的成員。而這里需要注意的就是對方法的調用。
回到上表中的右上角。對，就是對參數的操作部分。靜態方法和實例方法是不同的哦~
舉個例子：假設你有一個類Murong中有一個靜態方法Add(int32 a, int32 b)，實現的內容就如同它的名字一樣使兩個數相加，所以需要2個參數。和一個實例方法TellName(string name)，這個方法會告訴你傳入的名字。
class Murong {public void TellName(string name){System.Console.WriteLine(name);}public static int Add(int a, int b){return a + b;} }靜態方法的處理：
那么其中的靜態方法Add的CIL代碼如下：
//小匹夫注釋一下。 .method public hidebysig static int32 Add(int32 a,int32 b) cil managed {// 代碼大小 9 (0x9).maxstack 2.locals init ([0] int32 CS$1$0000) //初始化局部變量列表。因為我們只返回了一個int型。所以這里聲明了一個int32類型。索引為0IL_0000: nopIL_0001: ldarg.0 //將索引為 0 的參數加載到計算堆棧上。IL_0002: ldarg.1 //將索引為 1 的參數加載到計算堆棧上。IL_0003: add //計算IL_0004: stloc.0 //從計算堆棧的頂部彈出當前值并將其存儲到索引 0 處的局部變量列表中。 IL_0005: br.s IL_0007IL_0007: ldloc.0 //將索引 0 處的局部變量加載到計算堆棧上。IL_0008: ret //返回該值 } // end of method Murong::Add那么我們調用這個靜態函數應該就是這樣咯。
Murong.Add(1, 2);對應的CIL代碼為：
IL_0001: ldc.i4.1 //將整數1壓入棧中IL_0002: ldc.i4.2 //將整數2壓入棧中IL_0003: call int32 Murong::Add(int32,int32) //調用靜態方法可見CIL直接call了Murong的Add方法，而不需要一個Murong的實例。
實例方法的處理：
Murong類中的實例方法TellName()的CIL代碼如下：
.method public hidebysig instance void TellName(string name) cil managed {// 代碼大小 9 (0x9).maxstack 8IL_0000: nopIL_0001: ldarg.1 //看到和靜態方法的區別了嗎？IL_0002: call void [mscorlib]System.Console::WriteLine(string)IL_0007: nopIL_0008: ret } // end of method Murong::TellName看到和靜態方法的區別了嗎？對，第一個參數對應的是ldarg.1中的參數1，而不是靜態方法中的0。因為此時參數0相當于this，this是不用參與參數傳遞的。
那么我們再看看調用實例方法的C#代碼和對應的CIL代碼是如何的。
//C#Murong murong = new Murong(); murong.TellName("chenjiadong");
CIL：
.locals init ([0] class Murong murong) //因為C#代碼中定義了一個Murong類型的變量，所以局部變量列表的索引0為該類型的引用。 //.... IL_0009: newobj instance void Murong::.ctor() //相比上面的靜態方法的調用，此處new一個新對象，出現了instance方法。 IL_000e: stloc.0 IL_000f: ldloc.0 IL_0010: ldstr "chenjiadong" //小匹夫的名字入棧 IL_0015: callvirt instance void Murong::TellName(string) //實例方法的調用也有instance到此，受制于篇幅所限（小匹夫不想寫那么多字啊啊啊！）CIL是What的問題大致介紹一下。當然沒有再拓展，以后小匹夫可能會再詳細寫一下這塊。
How？
記得語文老師說過，寫作文最重要的一點是要首尾呼應。既然咱們開篇就提出了U3D為何能跨平臺的問題，那么接近文章的結尾咱們就再來
提問：
Q:上面的Why部分，咱們知道了U3D能跨平臺是因為存在著一個能通吃的中間語言CIL，這也是所謂跨平臺的前提，但是為啥CIL能通吃各大平臺呢？當然可以說CIL基于堆棧，跟你CPU怎么架構的沒啥關系，但是感覺過于理論化、學術化，那還有沒有通俗化、工程化的說法呢？
A:原因就是前面小匹夫提到過的，.Net運行時和Mono運行時。也就是說CIL語言其實是運行在虛擬機中的，具體到咱們的U3D也就是mono的運行時了，換言之mono運行的其實CIL語言，CIL也并非真正的在本地運行，而是在mono運行時中運行的，運行在本地的是被編譯后生成的原生代碼。當然看官博的文章，他們似乎也在開發自己的“mono”，也就是被稱為腳本的未來的IL2Cpp，這種類似運行時的功能是將IL再編譯成c++，再由c++編譯成原生代碼，據說效率提升很可觀，小匹夫也是蠻期待的。
這里為了“實現跨平臺式的演示”，小匹夫用mac給各位做個測試好啦：
從C#到CIL
新建一個cs文件，然后使用mono來運行。這個cs文件內容如下：
然后咱們直接在命令行中運行這個cs文件試試~
說的很清楚，文件沒有包含一個CIL映像。可見mono是不能直接運行cs文件的。假如我們把它編譯成CIL呢？那么我們用mono帶的mcs來編譯小匹夫的Test.cs文件。
mcs Test.cs生成了什么呢？如圖：
好像沒見有叫.IL的文件生成啊？反而好像多了一個.exe文件？可是沒聽說Mac能運行exe文件呀？可為啥又生成了.exe呢？各位看官可能要說，小匹夫你是不是拿windows截圖P的啊？嘿嘿，小匹夫可不敢。辣么真相其實就是這個exe并不是讓Mac來運行的，而是留給mono運行時來運行的，換言之這個文件的可執行代碼形式是CIL的位元碼形態。到此，我們完成了從C#到CIL的過程。接下來就讓我們運行下剛剛的成果好啦。
| 1 | mono Test.exe |
?
結果是輸出了一個大大的“Hi”。這里，就引出了下一個部分。
從CIL到Native Code
這個“HI”可是在小匹夫的MAC終端上出現的呀，那么就證明這個C#寫的代碼在MAC上運行的還挺“嗨”。
為啥呢？為啥C#寫的代碼能跑在MAC上呢？這就不得不提從CIL如何到本機原生代碼的過程了。Mono提供了兩種編譯方式，就是我們經常能看到的：JIT（Just-in-Time compilation，即時編譯）和AOT（Ahead-of-Time，提前編譯或靜態編譯）。這兩種方式都是將CIL進一步編譯成平臺的原生代碼。這也是實現跨平臺的最后一步。下面就分頭介紹一下。
JIT即時編譯：
從名字就能看的出來，即時編譯，或者稱之為動態編譯，是在程序執行時才編譯代碼，解釋一條語句執行一條語句，即將一條中間的托管的語句翻譯成一條機器語句，然后執行這條機器語句。但同時也會將編譯過的代碼進行緩存，而不是每一次都進行編譯。所以可以說它是靜態編譯和解釋器的結合體。不過你想想機器既要處理代碼的邏輯，同時還要進行編譯的工作，所以其運行時的效率肯定是受到影響的。因此，Mono會有一部分代碼通過AOT靜態編譯，以降低在程序運行時JIT動態編譯在效率上的問題。
不過一向嚴苛的IOS平臺是不允許這種動態的編譯方式的，這也是U3D官方無法給出熱更新方案的一個原因。而Android平臺恰恰相反，Dalvik虛擬機使用的就是JIT方案。
AOT靜態編譯：
其實Mono的AOT靜態編譯和JIT并非對立的。AOT同樣使用了JIT來進行編譯，只不過是被AOT編譯的代碼在程序運行之前就已經編譯好了。當然還有一部分代碼會通過JIT來進行動態編譯。下面小匹夫就手動操作一下mono，讓它進行一次AOT編譯。
//在命令行輸入 mono --aot Test.exe結果：
從圖中可以看到JIT time： 39 ms,也就是說Mono的AOT模式其實會使用到JIT，同時我們看到了生成了一個適應小匹夫的MAC的動態庫Test.exe.dylib，而在Linux生成就是.so（共享庫）。
AOT編譯出來的庫，除了包括我們的代碼之外，還有被緩存的元數據信息。所以我們甚至可以只編譯元數據信息而不變異代碼。例如這樣：
//只包含元數據的信息 mono --aot=metadata-only Test.exe可見代碼沒有被包括進來。
那么簡單總結一下AOT的過程：
Full AOT
當然上文也說了，IOS平臺是禁止使用JIT的，可看樣子Mono的AOT模式仍然會保留一部分代碼會在程序運行時動態編譯。所以為了破解這個問題，Mono提供了一個被稱為Full AOT的模式。即預先對程序集中的所有CIL代碼進行AOT編譯生成一個本地代碼映像，然后在運行時直接加載這個映像而不再使用JIT引擎。目前由于技術或實現上的原因在使用Full AOT時有一些限制，不過這里不再多說了。以后也還會更細的分析下AOT。
?
總結：
好啦，寫到現在也已經到了凌晨3：04分了。感覺寫的內容也差不多了。那么對本文的主題U3D為何能跨平臺以及CIL做個最終的總結陳詞：
總結
以上是生活随笔為你收集整理的Unity3d--跨平台（一）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： java中同步锁的原理和实现
- 下一篇： set 用法