Unity3D邏輯熱更新，第二代舒爽解決方案，L#使用簡介

熱更新

天下武功，無堅不破，惟快不破

熱更新就是爲了更快的把內容推到用戶手中。

以前，我設計了C#Light，通過半年多的持續修補，勉強可用，磕磕絆絆。
感謝那些，試過，罵過，用過的朋友，在大家的陪伴下一路走來，也讓我更堅決了要把這件事作好的決心。因而就有了C#Light的2.0，L#。

爲何叫L#呢？
由於此次是直接加載解析DLL執行，Load，有一個L
由於直接執行的東西叫作IL，有一個L
由於模擬CLR的工做，有一個L
因而，就有了L#

https://github.com/lightszero/LSharp

歡迎加QQ羣223823428探討：

L#爲何舒爽

上一篇已經解釋了工做模式
你能夠看到這一次變C#Light的"巧妙"利用VS、mono作語法檢查變成真的使用vs、mono來編譯
完全的解決了C#Light語法支持不完整的問題
C#Light設計之初就肯定了是c#的語法子集
編寫起來，限制諸多，到處掣肘，只保留了C#的形
這一次，L#，形神兼備。並且不止是c#，L#支持C# vb.net unityscript f# boo,只要能編譯成dotnet dll就能夠

 

上一篇見這裏http://www.cnblogs.com/crazylights/p/4216913.html

上一篇發佈以後，L#的接口又作出了一些調整

Github 上有最新的源碼https://github.com/lightszero/LSharp
其中有一個ForUnity目錄，就是爲Unity準備的
已經測試經過了IOS和WP8這兩個極端環境

L#在C#Light基礎上作出的改進

1.C#light的Context設計不明確

不少人都在疑惑什麼時候該new，爲什麼要new
L#完全把這個設計修改成ThreadContext，腳本中的線程管理對象，在一個線程上只須要new一次，並且隨時ThreadContext.active 就可獲取。
之前C#Light 從回調中調用，就只能看到回調一部分腳本堆棧了。
L#修改了這個設計，一個線程上的腳本堆棧全是一體的，即便通過回調也徹底可見，通過回調排錯再也不困難

2.改動了接口結構

更像反射，方便在反射和L#腳本中快速切換
L#的接口結構和反射一致，並且能夠直接使用L#的調用方式調用反射。
更添加了快速切換反射和L#腳本的模式，發生難以判斷的bug時，能夠切到反射模式排查。
在支持反射的平臺上，也能夠切換到反射模式加速
快速切換的例子，有一個獨立測試程序，Test01

3.註冊改成可選

C#Light採用了先註冊再調用的模式，不少人抱怨不便。
這實際上是C#Light設計上的先天困難。
而IL解析DLL執行，DLL中的信息很完整，因此IL默承認以自動完成全部的類型註冊
也依然保留手工註冊的接口。

4.L#的神器CrossBind

L#設計了一個CrossBind方式，容許腳本直接繼承程序中的接口

好比在程序中設計一個

Interface IState

{

void Abc();

}

腳本能夠繼承此接口，並返回兼容IState的實例給程序

腳本中已經實現了關於迭代器的兩個CrossBind

也就是支持在腳本中使用yield語句。

L#的優化空間

不少人都關心L#的性能問題，L#的工做還沒推動到那個階段。

如今在Alpha階段，歡迎小白鼠加入，一塊兒踩踩坑。

根據目前的少許用戶試用反饋，其Bug是比C#Light Alpha階段少了不少的。

可是L#存在很大的優化空間

1. 還有不少階段有填Cache的空間
2. 既然咱們是模擬CLR的工做，對IL語句，天然也能夠作出相似JIT的優化。

   好比a.nop語句徹底是浪費時間能夠移除

   b.stloc ldloc 這種兩條連續，參數一致的語句，他的意義是保存變量並加載變量，咱們就能夠設計一條優化指令，stlocandstayinstack，保存變量而且保留在棧上。

c.不少算術運算都是ld到棧，計算，再存回，只要設計優化的自增運算指令，就能夠三條變一條

3．能夠考慮 unsafe 或者本地代碼的引入