轉載請標明出處：http://www.cnblogs.com/zblade/
1、概述
整理遇到的一些較難處理的bug，總結相關經驗html
2、主要問題
2.1 material類型的依賴修改
對於material類型的asset，若是修改了其shader，對應的texture也修改了，並不會馬上刷新，從而致使之前的依賴的texture也會被打入到當前的ab依賴關係中。解決辦法，對於material類型，則經過EditorUtility.CollectDependencies 來剔除這種冗餘的依賴，具體代碼示例：python
if(isMat) { dependencies = AssetDatabase.GetDependencies(asset, false); UnityEngine.Object[] colDep = EditorUtility.CollectDependencies(new UnityEngine.Object[] { AssetDatabase.LoadAssetAtPath(asset, typeof(Material)) }); HashSet<string> filterd = new HashSet<string>(); foreach (var item in dependencies) { foreach (var item1 in colDep) { if (item.Contains(item1.name)) { filterd.Add(item); break; } } } dependencies = filterd.ToArray(); }
2.2 gitlab向jenkins推送的webhook，如何判斷其來自哪一個分支
對於gitlab推送的webhook，須要判斷其來自哪一個分支，從而切換打包機到指定的分支進行相關工做。在mac的環境下，能夠經過特殊的操做獲取其推送的分支信息：
在每次gitlab推送信息到mac打包機的時候，當前mac的環境變量中有一個關鍵環境變量: gitlabTargetBranch，經過獲取該關鍵環境變量，能夠獲得對應的分支信息git
--python 獲取方式 git_branch = os.getenv('gitlabTargetBranch')
2.3 lua虛擬機的重啓
在熱更新機制中，若是在熱更新完成後，須要重啓lua虛擬機，在xlua的機制下，須要注意，重啓lua虛擬機的操做，不能來自於lua端，只能是來自於c#端，也就是lua不能本身調用本身的重啓。web
2.4 同步加載bundle和異步加載bundle的處理
在遊戲中，啓動異步加載某個bundle的時候，若是後續有同步加載該bundle的操做觸發，須要打斷異步加載操做，能夠經過異步加載操做直接獲取bundle的方式打斷異步，具體的示例代碼:c#
AssetBundleCreateRequest abRequest = AssetBundle.LoadFromFileAsync(path);
//這步操做，會直接獲取bundle,從而打斷異步加載操做 AssetBundle ab = abRequest.assetBundle; if (ab == null) { ab = AssetBundle.LoadFromFile(path); var assets = ab.LoadAllAssets(); foreach (var item in assets) { Debug.Log(item.name); } } else { var assets = ab.LoadAllAssets(); foreach(var item in assets) { Debug.Log(item.name); } }
2.5 場景bundle丟失lightmap(光照貼圖)的問題
在某些場景bundle中，已經將相關的lightmap打入bundle中，可是對應的實際運行時並無將相關的lightmap加載進來，用AssetStudio發現bundle中實際是有的。可能緣由是bundle有，可是並無關聯。這時候須要修改unity的相關設置：
在Edit->Project Setting -> Graphics，找到 Shader Stripping, 將Lightmap modes從Automatic改爲Custom, 勾選Baked Non-Directional，而後從新打bundle，編譯後的bundle就不會出現lightmap丟失的問題了架構
2.6 XLua基類拓展方法的坑
在xlua中，對基類拓展的實現：
首先，在c#端加上拓展實現：異步
namespace UnityEngine
{
[XLua.LuaCallCSharp]
public static class ExtMethodLua
{
public static void SetActive( this Component c, bool value)
{
c.gameObject.SetActive(value);
}
}
}
有哪些坑？
1）對於拓展的基類和其拓展類，均須要添加[XLua.LuaCallCSharp]的標籤
問題解決：在生成代碼的時候，若是對某個類型進行了拓展，也須要將該類型打上對應的標籤，不能只單獨給拓展類打標籤。
若是隻給拓展類打標籤，則只會生成拓展類的wrap文件，不會生成基類的wrap文件，那麼基類中就不會包含這個拓展方法，因此會出現找不到該方法的報錯。gitlab
2）不執行生成代碼，不帶標籤，反射不會執行拓展方法
在XLua中，lua和c#的交互，有兩種方式，一種是以wrap文件的方式，執行lazy加載，在交互的時候調用。
一種是反射的方式，那麼爲何沒有wrap的時候，啓動反射的方式，會查找不到拓展類的拓展方法？
XLua自身在執行反射的時候，是修改了反射中對方法的獲取方式，須要標記爲LuaCallCSharp/ ReflectionUse，才能被獲取到this
2.7 健全的處理同步和異步的機制
因爲遊戲中既有同步加載操做，又有異步加載操做，異步加載操做又多是多個同時觸發，須要進行粒度的控制，這就須要較爲健全的處理同步和異步的機制。首先設定同步優先級更高，每當有同步操做到來的時候，若是有一樣的異步操做，須要打斷異步操做，直接執行同步操做。
此外多個異步操做排隊，形成第一個異步操做和最後一個異步操做的間隔較大，可能輪詢到最後一個異步操做的時候，最開始的環境已經變換，相關的依賴判斷須要再次判斷，不然會帶來隱藏bug.lua
2.8 局內戰鬥相關問題
如何設計一個高效，易拓展，健全，魯棒性高的戰鬥系統，是一個持續開發的過程。最佳的實現思路，是首先肯定須要什麼樣的表現效果，基於效果反推操做模式，基於操做模式，肯定技能流程，從而確立總體的流程。
程序在實現的過程當中，應該以表現方案爲基準，進而設計相關的代碼架構，同時兼容拓展性，便於後期的需求變動。
若是要作邏輯和表現分離類型遊戲，必定要嚴格把控邏輯與表現的耦合。邏輯端要作到徹底自運行，不依賴任何表現端的數據，邏輯端只負責發送相關指令/調用API給表現層便可。
固然，實際的執行時候，表現端總會來干擾邏輯端的自運行，這時候就須要雙方作溝通，保持邏輯端的自封閉的基準下，解除耦合，讓表現端儘可能自運行。
今天先寫到這兒，後續再更新
原文出處：https://www.cnblogs.com/zblade/p/10337366.html