將模塊插件化以及在工程中的控制

  模塊化不論是對工程管理仍是開發來講, 都是百利而無一害的, 從開發層面來看, 它強行讓開發人員在開發的時候要考慮到跟其它模塊的解耦, 考慮在其它環境下的泛用性和複用性, 直接就能提升開發水平, 而且在開新項目或者移植的時候, 可以拿來就用, 或者單獨使用, 或者拼湊使用這些模塊, 要什麼功能就下哪一個插件, 這就是模塊化的好處, 而且輸入輸出接口可以穩定的話, 其它調用到這些模塊的人員也會輕鬆不少.編輯器

  然而如今咱們的工程也是一鍋粥, 在前面的開發中也沒有想過這些...模塊化

  如今若是進行模塊化, 不但須要進行前期的代碼解耦, 中期的代碼剝離和提供大量外部注入, 到後期的管理工具都須要作起來, 才能完成一個正常的模塊化過程, 如今用的 Unity3D 它官方提供的插件下載 / 更新 / 管理方案就跟我想的差很少, 想要什麼就下載便可, 全部下載來的插件都是可以不依賴外部環境運行的, 這就很是方便了, 我還記得之前魔獸世界插件, 不少插件會依賴其它庫, 好比 ACE 函數庫, 你下了插件沒有庫結果沒有用, 它不是一個自恰的...svn

  這兩天試了一下, 感受仍是直接經過 SVN 進行版本控制比較方便, 在 Repositories 下建立不一樣的工程目錄, 每一個工程就是一個模塊的代碼庫, 經過 Unity 打開工程後編輯修改從開發工程中提取出來的代碼, 修改爲一個可以自恰的工程, 這些模塊就能獨立運做了.函數

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

 

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

  因而就開始嘗試看看吧, 先找兩個比較典型的模塊來製做 : this

  1. 資源打包加載模塊 [ ResourceModule ]spa

  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 -----------------

  以前的各類邏輯直接調用的 TortoiseSVN 的擴展命令 /c , 爲了泛用性修改成直接調用 svn 的命令行的方式了, 只有一個須要注意的地方, 命令行一個命令的長度爲8192長度, 經過一些方法能夠加大到32KB, 但是很麻煩也沒有根本解決問題, 由於通常使用絕對路徑來傳輸, 像下面這樣 : 

svn add E:\XXXX\OOOO\Assets\Test.cs.meta E:\XXXX\OOOO\Assets\Test.cs

  文件多了確定完蛋, 寫一個循環上傳的過程就好了.

相關文章
相關標籤/搜索