U3D里UI相关逻辑和文件的组织关系的各种形式的比较

代码和资源的组织关系

 

我觉得，做UI逻辑的时候，
在IDE里将脚本挂载到对象是个错误的方式。
因为不利于UI制作人员和程序员的工作分离。
不断的import和export package,会让程序员的代码遭遇版本问题

如果程序使用了particle class 特性，也会让UI制作人员那边运行不起来

 

解决方案：

本质是使用AddComponent，在运行期组织对象和脚本的关联关系。

 

具体形式为:

 

在UI的root对象上挂载一个入口脚本

 

脚本类容形式如下:

 

class StartScript : MonoBehaviour

{

    string [] scriptList =

        {

           "mainLogic.cs",

           "UIMail_List.cs",

            "UIMail_Write.cs",

        };

 

      void Awake()

      {

         GameObject owner = transform.gameObject;

         foreach(string scriptName in scriptList)

         {

               owner.AddComponent(scriptName);

         }

      }

}

 

注意 ：

AddComponent 的时候会触发脚本组件的Awake函数调用。

Awake里不能引用其他脚本内的实例对象和函数，因为和AddComponent的顺序有关，这样是为了避免引入顺序问题。

Start的时候就可以随便引用了。

 

策划先搭大概，导出
程序导入
再将入口脚本补进去，顺便检查下层级结构什么的。导出给策划，同时进行功能开发。
策划再导出，调整，给程序
程序再导入进来，功能也做完了，发布
只要入口脚本写完了，就可以随时导入导出了。双方不受影响

 

我这个实现里，入口脚本里还有一个文件列表。这个关联都不应该在其中的
可以写一个静态类，在那里包含，这样可以进一步避免交换包的时候导致的代码版本问题。 

比如:

// 入口脚本文件，挂载到场景的根对象上。

class StartScript : MonoBehaviour

{

      void Awake()

      {

         GameObject owner = transform.gameObject;

          ScriptList.Init(owner);

      }

}

 

// 逻辑脚本文件，不挂载到任何对象。程序自己控制

static class  ScriptList

{

    static string [] list =

    {

           "mainLogic.cs",

           "UIMail_List.cs",

            "UIMail_Write.cs",

    };

    public static void Init( GameObject owner)

    {

         foreach(string scriptName in scriptList)

         {

               owner.AddComponent(scriptName);

         }

    }

}

 

这样和策划的交集就只有一句话了：

ScriptList.Init(owner);
而这个是只要写成就不需要变动的。正好适合和包走.

 

定位控件的方式: 

1、使用public定位控件

2、使用pathName定位控件

方式2明显优于方式1，而且方式2还可以配合上面说的解耦方案。