XLua架構搭建——玩轉xLua的熱更新檔

關于熱更新檔這塊，轉載一篇xlua作者的文章，文章原連結玩轉xLua的熱更新檔

xlua架構這塊算是告一段落，如果有這方面的交流可以加QQ群：517539056

xLua熱更新檔特性上線一年多，已經得到廣泛的應用，其中不乏一些千萬級DAU、億級使用者量的大遊戲，回報良好。然而同時也有些初接觸的童鞋會有不少誤區，這篇主要談談這些誤區。誤區規避了，自然容易玩轉。

誤區1：我哪裡預測得到哪些地方有bug，進而打标簽呢？

其實不用預測哪些地方有bug，更多時候我們是把大多數類都囊括在内，然後把一些有把握不出bug（或者出了bug也不好解決，比如還沒讀懂代碼的第三方庫）排除在外。典型的打開方式是上線前把幾乎所有類型都配置上，然後随着後續疊代把一些穩定的子產品排除在外。

誤區2：打标簽太繁瑣了，操作性不強。

打标簽确實繁瑣，但是早在去年1月份就可以不打标簽，通過配置來配了，以至後來文檔明确說了直接在類上打标簽是不建議。xLua支援的動态配置結合linq，批量配置大量類也就幾行代碼的事情。

例如我們要對某名字空間下所有類配置到Hotfix清單，可以這樣：

public static class HotfixCfg
｛
    [Hotfix]
    public static List<Type> by_property
    ｛
        get
        ｛
            return (from type in Assembly.Load("Assembly-CSharp").GetTypes()
                    where type.Namespace == "XXXX"
                    select type).ToList();
        ｝
    ｝
｝
           

如果你沒規劃名字空間，可以考慮全注入+排除某些類的方式。還可以考慮放到一個目錄，然後正則處理後生成一個類的靜态清單（xLua的另外一種配置方式）。

誤區3：Hotfix清單裡頭的類型都加到LuaCallCSharp清單。

這樣操作會大大增加代碼大小。其實沒必要加，業務代碼是不加都能調用到的。引擎、系統、dll形式的第三方庫如果你更新檔代碼調用了個新的api會因為代碼剪裁而調用不到。你可以考慮禁止代碼剪裁或者加上ReflectionUse。

誤區4：希望用lua函數做callback，但對應的委托沒加到CSharpCallLua。

這個有個通用的解決辦法：CSharpCallLua也支援動态配置，可以反射結合linq，傳回所有字段，所有函數的參數和傳回值涉及到的委托類型。

誤區5：lua打完更新檔，lua更新檔怎麼維護？

額，lua更新檔其實隻是緊急情況下（影響面大的bug）緊急處理方案，正常情況下更新檔就修目前線上版本的bug而已，後續不需要維護。

誤區6：C#的object參數接口調用，有時需要指定确定類型。

c#的類型遠遠比lua要豐富，怎麼轉換，依賴于你所調用的函數的參數類型資訊，比如一個lua整數，你的參數是short，xlua就轉short，參數是int，就轉int。如果沒任何類型資訊（object），xlua隻能選一個不丢失精度的，lua53的整數是原生64位整數，對應C#的long。

這時你可以定義一個RawObject，可以參考下配套的例子：11_RawObject，該例子示範了怎麼指明以int類型傳遞到object參數。

如果你有這方面的需求（StrangeIOC就用到這類object參數接口），建議加上各種基本類型的RawObject。

誤區7：重載含糊的函數調用不了

用xlua.tofunction可以解決這問題，參加FAQ相應條目。

誤區8：以aop稱呼熱更新檔

首先這是不影響使用的，隻是個人聽起來不太習慣，想ps一下。

aop是一種程式設計思想，“代碼注入”隻是其中一種aop的實作方式，還有各種各樣的其它實作方式：早期有通過java的動态代理實作aop的；而aspectj則是加入了新的文法，在編譯器層面實作aop，等等等等。早在aop提出之前，“代碼注入”就應用于軟體的更新檔方面，特别是沒有源碼的軟體修複。

好吧，先說那麼多，最新的xLua新加入對應C# base關鍵字的支援，請看最新的release。