关于U3D客户端热更框架设计的一些思路

今天为了研究热更，抽空把xlua-framework的文档研究了下。当然自己的项目中也用到了x_lua，所以做些笔记。

先记录一些关于lua设计的知识点，这个后期可能会用上：

1. Table作为表时可以当做数组（Array），也可以当做哈希表（hashtable）（注意：实际上Lua语言对Table的实现，在底层会同时存在线性部分的数组和散列部分的哈希表，在某些情况下才是二者挑一）
2. 类和类实例：Lua中只有表的概念，其实类和类实例都是一张表，对于类来说，定义以后全局范围内只有一张表来标识这个类，类实例就是以这个类为基础创建的一张新表
3. 虚表：这里的实现模仿了C++里面向对象的设计方式，对于每个类使用了一张虚表来存放成员和方法。但是，需要注意的是这里与C++数据成员的内存布局是不一样的，C++中的虚表只存放成员函数，而这里也同时存放了数据成员
4. lua里面可以做到脚本级别的成员保护，分为：私有成员、共有成员。私有成员就是在脚本全局范围内定义的局部变量，而对于表来说，所有成员都是公有的。
5. 一般情况下，不建议随便使用全局变量来污染全局空间，而且还有一点，全局变量必须显示删除（赋值nil），否则永远不会被回收。

UI框架总体设计

基于MVC设计模式，其中Model层为UI界面数据，是游戏逻辑数据的子集，此外，还可以带窗口的控制数据，如果一个窗口不需要这些数据，不需要写Model层脚本；Ctrl层为窗口控制侧，窗口界面的控制直接写到View层，这里说的控制意思是把窗口当做一个输入接口，对游戏逻辑执行的控制，同样，不需要控制层的窗口不写就好；View层为窗口视图逻辑，负责界面刷新逻辑。

工作流程：

当请求UI管理器打开窗口时，UI管理器会根据UI配置找到MVC各层脚本文件并实例化对象，生成一个UIWindow的数据结构标识一个窗口。立刻调度Model层OnEnable（首次打开先调用OnCreate），如果有传入参数，需要在此处保存下来；随后等待UI资源异步加载完毕，加载完毕后调度View层OnEnable（同样首次打开先调用OnCreate），View层随后实现类似Mono脚本的调度流程，View层可以随时读取Model层数据，但是写Model层数据需要经过Ctrl层；Ctrl层无状态，如果需要状态，写Model层就好。

脚本调度顺序：

OnCreate->OnEnable->Update->LateUpdate->OnDisable->OnDestroy

注意：Update相关函数添加上就会被调度，尽量不用，节省性能。界面逻辑书写流程和写Mono脚本大概一致。

数据流：

1. 打开窗口时传入数据：OnEnable中传入Model层保存
2. Model层在OnEnable中从其他管理类或者数据类取数据并处理
3. View层可存放自身控制数据，直接读、间接写Model层数据
4. 模块与模块之间数据交换使用消息系统

层级管理：

所有UI挂载在UIRoot下面，UI划分的渲染层级是UI层，现在针对游戏一共预设了5个层级：Default、Map、Scene、Character、UI。目前UI排在最顶层，如果各个层级管理不出现问题，那么高层级的对象总是会盖住低层级的对象。

UI层级下的所有窗口根据OderInLayer的值来前后排布，为了避免层级混乱，这里进行统一管理，划分了一个子层级的概念，专供UI使用：

目前一共划分了6个子层级，第一个LuanchLayer只在启动界面使用；其余的子层级从上到下，展示时依次从背面到前面。

1. SceneLayer：用于场景UI
2. BackgroudLayer：背景UI
3. NormalLayer：普通一级、二级、三级UI
4. InfoLayer：信息UI
5. TipLayer：提示UI
6. TopLayer：顶层UI

归属于下一个子层级的UI窗口总是会盖住上一个子层级的UI窗口，不管打开顺序如何；而归属于同一个子层级的多个UI，其层级关系由打开的先后顺序决定，后打开的UI总是会盖住先打开的UI。

每两个相连子层级之间的OrderInLayer相间1000，而相同子层级的相连窗口OrderInLayer相间10，意思是说每个子层级最多可以同时打开100个窗口；而窗口内部还可以各自划分10个层级来使用，用于各个UI组件之间的层次关系（这些数值都可以根据具体情况调整配置）。在UGUI中，同属于同一个OrderInLayer的UI组件也可以排布先后，这种先后关系通过Hierarchy中的上下次序来决定，所以建议优先通过这种方式来排布先后，如果不能满足需求，再来使用不同的OrderInLayer来排布（会增加drawcall）。

补充记录

一般的UI框架都会把数据与显示分离，如果更详细的话，也可以将控制的逻辑单独提炼出来。

层级划分根据自己项目需要，名字和作用不一定要与文档一直

可以使用观察者模式，用代码回调的方法来刷新界面，尽量避免显示对于update更新函数的占用。

今天就先到这儿，基本思路和之前设计区别不大。我的项目中用的是自己的框架，所以就不再追叙。接下来的资源管理模块涉及到热更，是研究的热点，等明天再研究。

----------------------2020.9.28----------------------

资源管理模块

~~~~~~~~~2022.12.9~~~~~~~~~~~~~

最近策划提了个比较无理的要求，核心矛盾点在于，需要动态删除APP打进包体的资源。

我们得出的结论是不可以这么做，如果能做到的话，实际上离破解也就不远了。