核心代码:
for (var i = 0; i < 10; i++) { LevelPrototype.Instantiate() // var BtnLevel = GameObject.Instantiate(LevelPrototype) .Parent(LevelsContainer) // BtnLevel.transform.SetParent(LevelsContainer) .LocalScaleIdentity() // BtnLevel.localScale = Vector3.one .LocalPositionIdentity() // BtnLevel.localPosition = Vector3.zero .Show() // BtnLevel.gameObject.SetActive(true) .ApplySelfTo(btnLevel=> // 这里就是为了捕获上边的 BtnLevel 然后进行一些操作 { var levelIndex = i + 1; btnLevel.onClick.AddListener(() => { CloseSelf(); UIMgr.OpenPanel<UIGamePanel>(uiData: new UIGamePanelData() { LevelIndex = levelIndex }); }); }) .transform.Find("Text").GetComponent<Text>().text = "第" + (i + 1) + "关"; }请仔细月底以上注释部分。
总之，注释部分则是对链式支持的解释。不是本文重点。
重点是:
UIMgr.OpenPanel<UIGamePanel>(uiData: new UIGamePanelData() { LevelIndex = levelIndex });打开 UIGamePanel 的时候，可以传入一个 Data 进去。而这个 Data 就是 UIGamePanel 中 InitUI 接收到的 uiData。非常简单。
运行结果如下:
功能完成。
UIPanel 之间的数据传递由上一小节介绍的从 UILevelPanel 传数据到 UIGamePanel 这种传递数据的方式有什么好处呢?
首先在笔者的框架里，推荐将 UI 界面当做只是进行数据展示的工具。是一个 Input 和 Output 模块。输入数据，然后将数据展示到界面上。在笔者接触的很多项目中，在界面逻辑中添加了非常多数据访问相关的代码，各种 DataManager、ConfigManager 等等，这里是非常不推荐的。推荐所有要展示的初始数据，都是通过 uiData 传入进来，这要每个界面或模块都可以进行独立测试。
独立测试、团队成员之间互不干扰、并且可以自己写一些测试数据这仅仅是第一个好处，还不够。
第二个好处则是为了方便完成 UIPanelStack 功能，这个功能是主要完成一个 返回上一页这个功能。举个例子。
假如 UIGamePanel 可以从 UILevelPanel 打开，那么 UILevelPanel 打开的 UIGamePanel 返回上一页应该是 UILevelPanel。
同理，通过 UIOtherPanel 打开的 UIGamePanel 返回的上一个页面应该是 UIOtherPanel。
这个功能如果用一堆判断 + UIGamePanelData 来实现很容易，但是代码不是很优雅，假如 UIGamePanel 可以从十多个页面打开，那是不是要写十多个条件判断? 而且要在每个打开 UIGamePanel 的地方都要把 上一个页面信息记录到 UIGamePanelData 里。这样很麻烦。要完成这个最简单的还是一个 UIPanelStack，用一个堆栈来记录页面打开关闭的信息。
有了 UIPanelData 这个概念，那么很容易就可以完成这个功能。主要抽象出一个 UIPanelInfo 就好了，
namespace QFramework { public class UIPanelInfo { public IUIData UIData; public UILevel Level; public string AssetBundleName; public string PanelName; } }这是第二个好处了，有了 UIPanelData 这个基础就可以做更多的事情。UIPanelStack 功能不是本小节重点，在接下来会详细进行介绍。
总结下来好处就是两点:
独立测试、团队成员之间互不干扰、并且可以自己写一些测试数据。
更容易实现 UIPanelStack。
不过，这个 UIPanelData 的设计还有改进的空间，如果将 UIPanelData 做成可序列化的，并且 mData 是一个可赋值的话，那么做界面测试的时候就不用更改代码了，只在 prefab 上就可以进行测试数据的修改了。可以节省大量的代码编译时间。这个功能在笔者自己的项目进行过实验，是可以实现的，等稳定了会在 UI Kit 未来的版本集成。
UIMgr/UIManagerUIMgr 本身是个 Manager，之前在 ResKit 有介绍过，只要叫 XXXMgr 的本身就是一个容器，是一个对外提供容器元素一系列操作的容器。而 UIMgr 则是 UI 的容器，里边维护了一个字典，Dictionary <string,IUIPanel>。所有的 UIMgr.Open/Close/Get 等，都是先进行一次字典查询，再进行相应操作的。这个不难理解，大部分市面上的方案和 UI Kit 类似，都比较成熟了，这里不值得浪费篇幅。
UIPanelStack 管理