基于NGUI的unity界面管理的讨论

写在前面

刚刚做的项目，由于界面管理做的不太好，所以在开发的过程中出现了很多奇怪或难缠的bug，搞得我们几个写UI逻辑的越写越觉得没意思，想方设法的到处打补丁，后来也就是在这样的情况下，一直在总结开发中关于界面上遇到的坑，写了一年多的UI逻辑，针对那些由于界面架构上导致的问题，自己琢磨了一个简易的UI框架，只是简单的跑了一下没什么问题。

好了正式开始吧。

关于界面的问题（我开发时遇到的）

这个可是太多，总结了几个重要的点
1、界面的管理
2、界面生命周期
3、界面的显示和隐藏
4、界面逻辑的管理
5、逻辑代码和view分离
6、界面之间传值问题
7、界面穿插和界面层级管理
8、引用关系
9、脚本该不该挂在gameobject上

那么下面我就围绕以上几点写了。

界面管理

界面的资源全部都是打在AssetBundle中，然后通过底层函数把prefab load起来，给它挂上一个脚本，这个脚本就包含着该界面的逻辑，有一个WindowManager来管理这些window，每个window之间有父子引用关系，在WindowManager中还维护了一个栈来管理，每次界面打开或关闭都与该界面的父或子有关系。

例如，当打开一个新界面时，会把父界面的gameobject传进去，把界面显示出来，把父界面隐藏，关闭界面的时候，把当前界面隐藏，父界面显示，这样会出现一个问题，当两个界面同时在最上面时，当它们无论关闭时都会下面的界面显示出来，有时候就会出现穿插。

正常情况下，在同一时刻应该只允许一个界面是可操作的。

又是维持父子关系，一方面又用栈来保存，这样让我真的不知道应该怎么获取父界面，因为有可能在界面中父的引用不是栈里面的“父”。

界面生命周期

界面的生命周期可说是个比较重要的问题，提醒一下！！！
千万不要把两个不同的生命周期顺序写在一起，如果真要写一起，请一定一定注意它们之间的顺序。

自己的界面生命周期函数的调用时机一定要很清楚。

说说我们项目，挂在界面上的那个脚本里面就存在两套生命周期函数，一个是Mono的那一套，另一个是底层框架维护的一套。这东西当开始的时候没什么问题，越往后写越改就发现很多时候的bug，都是由于生命周期顺序造成的。例如：NGUI里面很多东西都是在Start做的，所以只要用NGUI，所有设置界面显示都最好是在Start之后去调用，不然可能会出现ScrollView的Item错位的情况。

我们界面几个状态，可见、可操作、不可见。转圈的进度条也被用界面来管理了，所以当时每次转圈完了之后，就会调用一次“可操作”的周期函数，有时候遇到断线重连，就会不停的转圈，当然也会不停的调用函数。

界面的显示和隐藏

有很多种方法
1、gameObject.SetActive(true or false)
2、把界面移到UI摄像机外面
3、改变界面的Layer到UI相机不照的层
4、设置为透明
5、用不透明的背景遮挡
6、每个界面都放在不同位置上，这样移动UI相机到相应界面也实现显示隐藏了。
7、也可采用多相机的方式

其中1、4两种方法对于NGUI并不好，因为那样操作会导致panel的所有“顶点重建”，重新生成drawcall。这也是NGUI消耗性能的地方，过段时间我会整理一下对NGUI的分析。
其中5，要看具体需求（自己脑补）
其中2、3、6、7都是可取的，但具体细节还得认真考虑，我用了改变Layer的方式。

界面逻辑的管理

我们直接在上挂了一个脚本，刚开始做unity的时候，把界面的逻辑全部写在这个脚本里面。一般简单界面还好，但遇到复杂界面就完蛋了，有时候这一个脚本就得上千行，可读写性很差，过一段时间修改原代码很费劲，而且很多逻辑状态放在一起非常容易出现bug，有一段时间bug特别多。

遇到了一个状态非常多的界面，脚本里面放了很多状态变量，有些变量是互斥的，有些可以共存的，然后就这样没有规划的写了，结果这个界面很乱，都不敢做太大改动，出了bug改好了又引发其他的bug。所以后来就用有限状态机来管理这些，把每个状态和状态对应的逻辑拆分，这样每个脚本行数变少了，逻辑得到很大的改善，后来改bug都不费脑子了，呵呵。（后来在知乎上看到一个人说用行为树。。。后面再尝试吧）

逻辑代码和view分离

为什么？
1、当业务代码越复杂时，修改代码就成了费脑的事情。
2、当时间越来越久，理解代码就非常困难。
3、同一个逻辑不能复用，在很多地方复制粘贴，如果出现错误就会修改很多地方。
4、测试变得非常麻烦，没都要整体测一次才能确保一切完好。

怎么做？
使用MVC或MVP等架构模式，使代码达到低耦合、高复用、易测试、好维护、易扩展。

记得刚刚学习网站开发的时候，MVC是首先接触到的设计思想，应该滚瓜烂熟的东西。有一段时间我研究了一下MVC，发现和之前的认识不一样，比如View需要观察Model，MVC实际是UI框架的一种模式，可并不是整个系统。下面就看看那些模式：

MVC
是一种使用Model View Controller设计创建web应用程序的程序。它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。最典型的MVC就是jsp + servlet + javabean的模式。

Model - 表示应用的程序的核心，提供数据和数据相关的逻辑，通知View数据变化
View - 显示数据，观察Model变化，可以从Model取得数据进行显示
Controller - 处理输入，调用model处理业务逻辑，逻辑处理完之后，修改Model，并选择View显示结果
注意：这里所说的是经典MVC模式，后来发展了很多版本，它们之间无非就是这三者关系的变化，具体可以看看相关的文章和论文。

clipboard.png

MVP
它是从MVC演变而来，其中Presenter处理业务逻辑，Model提供数据和数据的逻辑，View负责显示。
作为一种新模式，和MVC的重大区别就是在MVP中View不直接使用Model，它们之间通过Presenter来进行的，所有交互发生在Presenter内部，Presenter代替了Controller的角色，在处理业务逻辑的基础上还要负责帮View从Model中取数据。而在MVC中，View会直接从Model中读取数据。

clipboard.png

ＭＶＶＭ
对ＭＶＶＭ不了解，也没有使用过，看了一些网上的文章，最重要的概念应该就是：数据绑定。把Presenter换成了ViewModel，换汤不换药，最终发生改变就是三者之间的关系和三者所负责的事情。了解更多就去网上搜一搜。

以上对一些模式的简介，总结起来，虽然有这些模式的存在，但需求是万变的，没有哪个模式能适用于一切情况，所以一切都要以实际项目、实际需求为主，吸收那些模式的思想，应用于各个开发场景。一句话就是，怎样让开发简单、代码好看、易于维护就怎么做喽。

界面之间传值问题

不管是使用哪种开发模式。在实际开发中应该都会遇到一个问题，对于界面管理，界面之间的传值是一个重要的问题。
在Ａndroid中，两个Activity之间传值使用了一个叫Intent的组件，Activity持有Intent的引用。
在unity开发中，需要注意传值的时机，在界面逻辑脚本中用成员变量保存该值。

界面穿插和界面层级管理

影响渲染顺序的因素：

clipboard.png

在NGUI中，panel之间的层级，weight之间的层级都是用depth属性控制的。虽然有以上几个方面都可以控制渲染顺序，但还是建议使用depth吧，毕竟这是NGUI提供的最正规的方式。

注意，panel和weight的depth是不交叉的，先是panel和panel深度排序，然后再是同一个panel下的weight进行深度排序。而且即使panel在hierarchy视图中有层次关系，也不会影响depth的排序。

当然关于层级关系还有一个重要的方面：3D模型和粒子特效的裁剪问题，有些游戏有这样的需求，比如在界面上显示一个英雄的模型，有些界面需要在模型上面，有些则在模型下面。我现在的做法是用多个相机，一个界面对应一个相机，模型相机也是分开，利用相机的depth达到效果。

引用关系

取决于具体开发的框架了，建议使用MVC或MVP，各个层次的引用关系就是这些模式所描述的，能使代码结构清晰，减少bug的出现，利于后期维护。

脚本该不该挂在gameobject上

关于这个问题就看项目的框架了，有些框架是把界面的脚本直接挂在gameObject上，有些则是通过脚本内持有gameObject引用关联的。

经过上面的讨论，已经把遇到过关于界面比较重要一些地方了解了，然后自己写了一个简单的UI框架。

在Unity开发中，客户端UI框架的脚本有两种方式：

１、如果每个界面都有单独处理业务逻辑的脚本挂在自己身上，这种是通过Unity自身来驱动界面，把两个生命周期放在一个脚本中。

首先需要知道，写逻辑的脚本不能静态绑定的，因为网络游戏都需要资源热更新，所以我们要把几乎所有的美术资源打成AssetBundle的形式（这是Unity美术资源的一种存在形式），unity中资源结构的组织及管理通过.meta文件完成的，unity会为工程中每个文件和文件夹创建一个.meta文件，里面记录着一个GUID，每个电脑生成的GUID不一样，而且资源只要变化了就会重新生成GUID，在开发时要不停往这些脚本中写代码，脚本变化对应的GUID也会变化，这会导致已经打好的AssetBundle里通过记录的GUID找不到挂的脚本，也就是脚本丢失。

那么逻辑脚本也就只能动态的挂上去了：
TestScript test = gameObject.AddComponent<TestScript>();
test.SetParams(param); //传值
test.Init(); //初始化
这段代码是很多时候是这样的，但需要注意，此时的TestScript只执行了Awake，还没有执行Start就调用了初始化，如果界面是NGUI的，那么NGUI很多初始化工作都在Start中完成，也就是说UI本身都还没有初始化完成，就开始执行显示逻辑了，这是不对的。所以Init里面不能写让UI显示数据的代码，只能写在TestScript 的Start中，这样才能保证所有UI控件已经初始化完成了。

2、如果整个框架是有某个脚本来驱动的，也就是界面的逻辑不直接挂在gameObject上的，而是通过代码中存在的引用关联的，这样脚本中没有mono相关的生命周期，只有自己底层维护的周期了，所有脚本都完全自己把控。但还是得注意，自己的周期也一定要合理，NGUI中一定要保证UI全部初始化完成了才能执行显示逻辑。

UI框架部分

整体的类图

clipboard.png

我直接在gameObject上挂脚本，但是挂的一个通用的脚本：Window，这个类继承自MonoBehaviour，用来驱动我的逻辑。

Window.cs

using System;
using System.Collections.Generic;
using UnityEngine;

public class Window : MonoBehaviour
{
    private IPresenter _presenter = null;
    private bool _isStart = false;

    void Start()
    {
        _isStart = true;
        gameObject.layer = UnityLayer.ShowUILayer;
        _presenter.OnStart();
        this.Show();
    }

    void OnDestroy()
    {
        _presenter.OnDestroy();
    }

    public void AddPresenter(IPresenter presenter)
    {
        this._presenter = presenter;
    }

    public void Show()
    {
        if (_isStart)
        {
            _presenter.OnEnter();
        }
    }

    public void Hide()
    {
        _presenter.OnLeave();
    }

    public void OnStop()
    {
        _presenter.OnStop();
    }

    //重用界面时调用

    public void ReStart(IIntent intent)
    {
        _presenter.SetIntent(intent);
        _presenter.OnStart();
        this.Show();
    }
}

IPresenter是定义的处理界面逻辑的接口

public interface IPresenter
{
    void OnStart();
    void OnEnter();
    void OnLeave();
    void OnStop();
    void OnDestroy();

    void BindView(GameObject go); //这就是绑定gameObject到逻辑
    void SetIntent(IIntent intent); //传递界面参数
}

IView是定义的界面接口

public interface IView
{
    void Init(GameObject view); //在Presenter中会把传递的界面gameObject绑定到View上，Presenter持有View的引用，而不直接持有gameObject
}

IIntent是参数传递的接口

public interface IIntent { }

结构可以理解为一个界面对一个IPresenter，对应一个IView。IPresenter中负责业务逻辑、设置界面，IView中负责写界面设置函数和事件监听，这样把UI和逻辑分开了。

接着看看实现IPresenter的一个基础类：Presenter<T>，它接受一个泛型，用来把IView和它联系起来，并实现了一些函数。

using System;
using System.Collections.Generic;
using UnityEngine;

public abstract class Presenter<T> : IPresenter where T : IView
{
    protected FSM _fsm = null;
    protected IIntent _intent = null;
    protected T _view = default(T);

    public void SetIntent(IIntent intent)
    {
        this._intent = intent;
    }

    //每次压栈都会调用
    public abstract void OnEnter();
    //{
    //    //_view.Show();
    //}

    //每次退栈都会调用
    public abstract void OnLeave();
    //{
    //    //_view.Hide();
    //}

    //在mono start和时调用
    public virtual void OnStart() { }

    public virtual void OnStop() { }

    public virtual void OnDestroy() { }

    public void BindView(GameObject view)
    {
        _view = Activator.CreateInstance<T>();
        _view.Init(view);
    }
}

当然IView也有基本实现：View

public abstract class View : IView
{
    protected GameObject _view = null;

    public virtual void Init(GameObject view)
    {
        this._view = view;
    }

    public void Show()
    {
        _view.layer = UnityLayer.ShowUILayer;
    }

    public void Hide()
    {
        _view.layer = UnityLayer.HideUILayer;
    }
}

其中UnityLayer是定义的通过UnityEditor创建的Layer，之前也说过，我是通过改变layer来显示和隐藏界面的。

public class UnityLayer
{
    public const int HideUILayer = 8;
    public const int ShowUILayer = 5;
}

还有一个类负责管理界面：WindowManager，它维护了一个栈的结构（虽然我是用List装的），每次打开界面的时候 - 进栈，每次关闭界面的时候 - 出栈。

界面IPresenter的生命周期：

clipboard.png

WindowManager 对外提供两个函数，一个打开一个关闭，并且还对无用的界面做了缓存，限制cache容器的大小，并用一个定时器定期去检查cache，超过限制就把前面的释放掉，满足先进先出的规则。

public class WindowManager
{
    private List<Window> win = new List<Window>();
    private List<Window> cache = new List<Window>();

    private static WindowManager ins = null;

    private WindowManager()
    {
        //运行检查缓存的定时器
    }

    public static WindowManager GetInstance()
    {
        if (ins == null)
        {
            ins = new WindowManager();
        }

        return ins;
    }

    public void OpenWin(string name, IIntent intent)
    {
        List<Window>.Enumerator etor = cache.GetEnumerator();
        Window old = null;
        while (etor.MoveNext())
        {
            if (etor.Current.gameObject.name.Equals(name))
            {
                old = etor.Current;
            }
        }

        if (old != null)
        {
            cache.Remove(old);
            win.Add(old);
            //手动调用，表示重用
            old.ReStart(intent);
        }
        else
        {
            //为了简单，所以这里就直接使用Resources加载了
            UnityEngine.Object obj = Resources.Load(name);
            GameObject go = GameObject.Instantiate(obj) as GameObject;

            //通过配置，关联界面和Presenter
            Type type = PresenterCfg.pconfig[name];
            IPresenter p = Activator.CreateInstance(type) as IPresenter;

            Window w = go.AddComponent<Window>();
            w.AddPresenter(p);

            if (win.Count > 0)
            {
                win[win.Count - 1].Hide();
            }
            win.Add(w);

            p.SetIntent(intent);
            p.BindView(go);
        }
    }

    public void CloseWin(GameObject go)
    {
        int i = 0;
        for (i = 0; i < win.Count; ++i)
        {
            if (win[i].gameObject == go)
            {
                //把当前最上面的窗口hide
                win[win.Count - 1].Hide();
                break;
            }
        }

        //没有找到相应的窗口
        if (i >= win.Count)
        {
            return;
        }

        for (int j = win.Count - 1; j >= i; --j)
        {
            win[j].OnStop();
            //缓存界面
            cache.Add(win[j]);
        }

        //弹出栈之后，需要销毁资源
        win.RemoveRange(i, win.Count);

        if (win.Count > 0)
        {
            win[win.Count - 1].Show();
        }
    }

    //检查并清理缓存
    private void _Examine()
    {
        if(cache.Count > 0)
        {
            //先进先出
            Window w = cache[0];
            cache.Remove(w);

            //释放资源
        }
    }
}

至此，一个简单的界面框架就完成了，那么在开发的时候只需要写一个Presenter和一个View：

public class ViewPresenter : Presenter<MainView>
{
    public override void OnStart()
    {
        //listen click
        Debug.Log("view presenter start");

        //get model data
        //set view data

    }

    public override void OnEnter()
    {
        Debug.Log("view presenter enter");

        _view.Show();

        //set attr
        //set icon
        //set name
        //set level
        //set quality
        //set ...
    }

    public override void OnLeave()
    {
        Debug.Log("view presenter leave");
        _view.Hide();
    }

    public override void OnStop()
    {
        Debug.Log("view presenter stop");
        //unlisten
    }

    public override void OnDestroy() { Debug.Log("view presenter destroy"); }

    //some
}

public class MainView : View
{
    //private event EventHandler Clicked;

    public override void Init(GameObject view)
    {
        base.Init(view);

        //UISprite sp = _view.transform.Find("").GetComponent<UISprite>();
        //UILabel label = _view.transform.Find("").GetComponent<UILabel>();
        //Transform test = _view.transform.Find("");
    }
}

总结：

在做项目的时候就一直琢磨，要自己写一个UI框架，不然对不起自己写了这么久界面。最近终于完成了第一版，里面还存在很多问题，比如多个界面的层次关系怎么管理、有两处代码使用了反射可以想办法改进，当然还有没有考虑到的问题，所以后续还要陆续修改。

写在最后：

花了一周时间整理了这些东西，整理自己的思路，这次一定印象深刻，可能写的不太好，有什么问题请直接指出，一起讨论，不断总结，不断学习，不断提升。