基于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模式,后来发展了很多版本,它们之间无非就是这三者关系的变化,具体可以看看相关的文章和论文。

基于NGUI的unity界面管理的讨论_第1张图片
clipboard.png

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

基于NGUI的unity界面管理的讨论_第2张图片
clipboard.png

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

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

界面之间传值问题

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

界面穿插和界面层级管理

影响渲染顺序的因素:

基于NGUI的unity界面管理的讨论_第3张图片
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框架的脚本有两种方式:

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

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

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

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

UI框架部分

整体的类图

基于NGUI的unity界面管理的讨论_第4张图片
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,它接受一个泛型,用来把IView和它联系起来,并实现了一些函数。

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

public abstract class Presenter : 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();
        _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的生命周期:

基于NGUI的unity界面管理的讨论_第5张图片
clipboard.png

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

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

    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.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();
            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
{
    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();
        //UILabel label = _view.transform.Find("").GetComponent();
        //Transform test = _view.transform.Find("");
    }
}

总结:

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

写在最后:

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

你可能感兴趣的:(基于NGUI的unity界面管理的讨论)