1. 程式人生 > 實用技巧 >將模組外掛化以及在工程中的控制

將模組外掛化以及在工程中的控制

  模組化不管是對工程管理還是開發來說, 都是百利而無一害的, 從開發層面來看, 它強行讓開發人員在開發的時候要考慮到跟其它模組的解耦, 考慮在其它環境下的泛用性和複用性, 直接就能提高開發水平, 並且在開新專案或者移植的時候, 能夠拿來就用, 或者單獨使用, 或者拼湊使用這些模組, 要什麼功能就下哪個外掛, 這就是模組化的好處, 並且輸入輸出介面能夠穩定的話, 其它呼叫到這些模組的人員也會輕鬆很多.

  然而現在我們的工程也是一鍋粥, 在前面的開發中也沒有想過這些...

  現在如果進行模組化, 不但需要進行前期的程式碼解耦, 中期的程式碼剝離和提供大量外部注入, 到後期的管理工具都需要做起來, 才能完成一個正常的模組化過程, 現在用的 Unity3D 它官方提供的外掛下載 / 更新 / 管理方案就跟我想的差不多, 想要什麼就下載即可, 所有下載來的外掛都是能夠不依賴外部環境執行的, 這就非常方便了, 我還記得以前魔獸世界外掛, 很多外掛會依賴其它庫, 比如 ACE 函式庫, 你下了外掛沒有庫結果沒有用, 它不是一個自恰的...

  這兩天試了一下, 感覺還是直接通過 SVN 進行版本控制比較方便, 在 Repositories 下建立不同的工程目錄, 每個工程就是一個模組的程式碼庫, 通過 Unity 開啟工程後編輯修改從開發工程中提取出來的程式碼, 修改成一個能夠自恰的工程, 這些模組就能獨立運作了.

  然後是模組管理工具, 我的想法是也建立一個SVN倉庫, 在一個工程的 CheckOut 中再進行管理工具的 CehckOut, 而管理工具提供視覺化的選項, 可以選擇相應的模組進行下載和更新, 這樣每個模組只要加個文件讓別人知道需要初始化的東西然後就能使用就行了.

--------------------- 開工的分界線 -----------------------

  於是就開始嘗試看看吧, 先找兩個比較典型的模組來製作 :

  1. 資源打包載入模組 [ ResourceModule ]

  2. UI 模組 [ UIModule ]

  顯然資源打包是一個對其它東西沒有依賴的模組, 只需要提供介面即可, 比較簡單, 而 UI 模組很依賴於資源載入, 我們就需要給它提供注入載入資源的方法才能執行的模組.

  在 SVN 上先建立它們的目錄, 大致如下 :

  這裡額外的一個 BasicProject 就是管理工具的工程, 它作為起點來提供模組下載控制.

  資源載入模組沒什麼好說的, 本身就是獨立的, UI 模組只需要使用外部提供的載入過程即可, 看看有改動的地方 :

    public sealed class UIManager : MonoSingleton<UIManager>
    {
        private static System.Func<string, string, GameObject> ms_loadModule = null;
        
        // set load method
        public static void ImplementLoadModule(System.Func<string, string, GameObject> loadModule)
        {
            ms_loadModule = loadModule;
        }
        
        public T LoadUI<T>(string prefabLoadPath) where T : UIBase
        {
            if(ms_loadModule == null)
            {
                throw new System.NotImplementedException("Resource Load Module Not Implement !!!");    // Tips
            }
            T ui = null;
            var go = ms_loadModule.Invoke(prefabLoadPath, UIPoolName);
            if(go)
            {
                ui = go.GetComponent<T>();
                // ...
            }
            return ui;
        }
    }

  這裡可以通過靜態設定讀取方式, 新增錯誤提示的話, 使用起來基本不會出錯了.

  當然其它模組肯定沒這麼給你面子, 肯定到處呼叫其它模組的程式碼, 這就需要後續再看了, 至少基礎的底層程式碼是可以做到的.

  然後是控制工具, BasicProject 其實就是一個編輯器工具, 它提供圖形介面的話就可以方便控制了, 於是寫到一個 EditorWindow 裡面, 它的邏輯意外的很簡單, 首先在裡面用程式碼寫死一些模組名稱和相應的 SVN 地址, 來表示模組下載地址, 然後通過查詢遠端版本和本地版本, 來決定是否需要下載或是更新, 當然是由使用者自己選擇了, 結構大致如下 :

        public class ModuleStatus
        {
            public string remotePath;
            public int remoteVersion;

            public string localPath;
            public int localVersion;
        }

        public static readonly Dictionary<string, string> Modules = new Dictionary<string, string>()
        {
            { "BasicProject", "https://XXXX/svn/BasicProject/Assets/BasicProject" },
            { "ResourceModule", "https://XXXX/svn/ResourceModule/Assets/ResourceModule" },
            { "UIModule", "https://XXXX/svn/UIModule/Assets/UIModule" },
        };

  因為它把自己的工程 BasicProject 也加入到外掛列表中了, 它就能更新它自己了, 所以這個列表等於是可以正常被更新的, 並非寫死的了. 它的初始化邏輯如下 :

    private Dictionary<string, ModuleStatus> m_existsModules = new Dictionary<string, ModuleStatus>();
    private HashSet<string> m_noExistsModules = new HashSet<string>();
    private volatile bool _inited = false;
    private volatile int _initCount = 0;
    private volatile int _initedCount = 0;
    
    private void OnEnable()
    {
        Load();
    }
    
    private void Load()
    {
        UnitySVN.StopAllThreads();
        _inited = false;
        _initCount = 0;
        _initedCount = 0;

        m_existsModules.Clear();
        m_noExistsModules.Clear();
        m_noExistsModules.UnionWith(Modules.Keys);

        var folders = Directory.GetDirectories(Application.dataPath, "*.*", SearchOption.AllDirectories);
        foreach(var folder in folders)
        {
            var module = Path.GetFileName(folder);
            if(Modules.ContainsKey(module))
            {
                _initCount++;
                UnitySVN.IsVersioned(folder, (_versioned) =>
                {
                    if(_versioned)
                    {
                        var status = new ModuleStatus()
                        {
                            localPath = CommonEditorUtils.LeftSlash(folder),
                            remotePath = Modules[module],
                        };

                        UnitySVN.GetVersionNumber(@status.remotePath, (_ver) => { status.remoteVersion = _ver; });
                        UnitySVN.GetVersionNumber(@status.localPath, (_ver) => { status.localVersion = _ver; });

                        lock(m_existsModules)
                        {
                            m_existsModules[module] = status;
                        }
                        lock(m_noExistsModules)
                        {
                            m_noExistsModules.Remove(module);
                        }
                    }

                    _initedCount++;
                    if(_initedCount >= _initCount)
                    {
                        _inited = true;
                    }
                });
            }
        }
    }

  SVN 相關的後面再說, 初始化首選去找模組相應的名稱的資料夾, 然後查詢是否在版本控制之下, 如果沒有就加入到 m_noExistsModules 列表中, 顯示為可下載. 如果存在就加入到 m_existsModules 中, 這裡麵包含了相關資訊, 包括遠端 SVN 地址, 遠端版本號, 本地地址, 本地版本號等, 如果版本對不上, 顯示為可更新 :

  顯示 ResourceModule 和 UIModule 都處於可下載狀態, 如果點選下載, 會得到下面的圖 :

  顯示的 Version 是本地版本號, 然後我們在其它工程中對 ResourceModule 進行更新, 使它提升版本號, 然後再打開面板看 :

  顯示可更新, 點選後工程就更新到相應版本了 :

  把模組都下載下來之後, 就可以進行UI載入了, 看看要怎樣初始化 :

因為有了UI模組, 可以繼承一個 UIBase :

public class MainUI : UIModule.UIBase
{
    
}

載入之前只要初始化讀取模組給 UIManager 就行了

using UnityEngine;

using ResourceModule;
using UIModule;

public class Test : MonoBehaviour
{
    private void Awake()
    {
        UIManager.ImplementLoadModule(PrefabLoader.Instance.Spawn);
    }
    // Use this for initialization
    void Start()
    {
        UIManager.Instance.Get<MainUI>("MainUI");
    }
}

  因為舊工程中的載入UI和這裡一樣, 區別只是需要對 UIManager 設定一個 LoadModule 的函式, 之前就是直接嵌入 PrefabLoader 的, 沒有太大區別.

  經過這些改動, 就能獲得一個解耦的模組程式碼了, 並且能隨用隨下, 其實對於複雜工程來說反而是好事, 提高了開發人員的程式設計能力, 減少耦合...

------------------- SVN -----------------

  之前的