前言
一个完全依赖ILRuntime的框架，集成好了ILRuntime和AB资源热更，想用ILRuntime的可以很方便使用。
对着作者的文档JEngine看看框架功能都是怎么实现的。
看下文档中提到的功能如下
JEngine框架核心
热更资源工具
AssetMgr，框架集成了BuddleMaster来管理AB包，这是对BuddleMaster功能的封装
对象绑定工具
与xlua中的绑定脚本方式和功能类似
扩展方法工具
这名字很形象，就是一些扩展方法
内存加密方案
说过了，看这个：【反外挂】内存加密与监视
队列任务方案
JAction，挺不错的，不过要依赖ETTask和生面周期方案
生命周期方案
LifeCycleMgr
这个是实现了一个LifeCycleMgr，该脚本继承MonoBehaviour。
管理需要在生命周期调用的Item
可以自己看一下Update的实现方法就知道了，在Update中遍历上图中_updateItem里的Item，执行他们的action回调。
代码逻辑不复杂自己看一下就知道了。
LifeCycleItem
如果想让这个脚本管理生命周期，就实现LifeCycleItem，结构也很简单，主要是一个回调方法。
JBehaviour
所有继承该类的都加入JBehavioursList里
在静态构造中把loop加入到生命周期管理
其中UpdateCheck 是遍历JBehavioursList，检查挂在此脚本物体的状态，对JBahaviour做出相应的增删处理
JBehavioursLoop 是调用jb的Loop注册事件。
这个Loom是Unity工程里的，就是事件队列的常见使用方式，作用一个就是对事件的下一帧处理，另一个就是处理需要主线程处理的事件。
如果看看Loom代码就知道这里只会调用一次JBehavioursLoop 函数，我就一直纳闷这到底是怎么实现循环调用的呢？？？
一直以为是Loom或者JBehaviour在其他地方有注册，漏看了什么逻辑，看了好一会儿才发现原来JBehavioursLoop 这函数是个死循环…JBehavioursLoop 里可以控制Loop的间隔
事件派发方案
就是事件系统，不过这个实现的事件系统和常见的不太一样
常见的都是事件中心模式，一个事件绑定对应的Action，触发了就调用所有Action。
作者也说了是借鉴EventBus的方式，和传统方法的区别就是，传统方法是观察者模式，这个方法是发布-订阅者模式
订阅者(Subscriber)把自己想订阅的事件(Event)注册(register)到调度中心(EventBus)，当发布者(Publisher)发布该事件到调度中心时，也就是该事件触发时，由调度中心统一调度订阅者注册到调度中心的处理代码(onEvent())。(发布/订阅者模式与观察者模式并不完全一样)
参考：EventBus 实战（一、使用详解篇）
这个要理解订阅着，发布者和数据，以JEngine中的实现为例（例子看EventDemo.cs）
JEvent.defaultEvent 是一个发布者，LoginSuccessData是数据，订阅者是打上Subscribe标签的类和方法。
一个订阅者可以订阅多个发布者，一个发作者可以给多个订阅者发布事件，事件在这里就是数据。
发布之后自动调用订阅者中参数为这个数据的函数。
和传统的观察者模式实现的事件系统的区别是，观察者模式是注册事件对应的响应方法。
订阅发布模式的是订阅者里主动注册。（JEngine这个Demo写的不太好，应该在各个类里面自己调用JEvent.defaultEvent.Register）订阅发布模式用事件来称呼不太好理解，用总线（Bus）就好理解了，订阅者订阅需要的n个Bus，发布者往Bus里发数据，谁订阅了谁就能收到。这里订阅者不只是一个方法，可能是一个类里的多个方法。
这么一看实际上两者区别也不大，个人感觉传统的观察者模式更简单直观些。
可绑定数据方案
BindableProperty，这个功能在QFramework中见过，基本一模一样，作者说是他原创的，可能是QFramework借鉴这个的吧，对这个不深究 o.O
之前写QFramework时讲过，就是对值变化这种情况加了个响应事件，比如ui显示，值变化了就改变ui。
预制体管理方案
自实现JPrefab，代码没多少，实际上是对GameObject包了一层，实现了个异步加载。用List统一管理该预制体物体。
感觉这个功能可以合并到对象池里。
验证器校验方案
对字符串的常用校验方式进行了封装，通过string类型的condition来指定校验方式
不错的工具
序列化助手方案
这个没什么说的，只是对json库和protobuf库又包了一层
对象池解决方案
就是普通对象池功能，而且写的太简单了，没有回收功能，目测使用的时候要自己通过gameObject.SetActive(false)来回收。
从池中取的时候在一个List里找没激活的返回。
不推荐使用，如果要用对象池，就应该由池来管理spawn和respawn，不然用这用这就迷了。
多语言解决方案
实际就是读表，存一个map<语种，map<key, value>>类型，切换语言时就用不同语种的map
需要统一管理文本，所以所有需要文本的地方都需要挂在一个LocalizedText 脚本，切换语种的时候所以文本更新一遍
突然发现个问题，这种方式如果文本销毁了，没有删除这个引用。
不是很推荐用这个，因为每个Text都要挂脚本，强依赖这个脚本，等Text多的时候就很乱。
如果是通过读表实现的话，实际上还是动态读表比较好，就是需要设置文本的地方，通过读表的方式获得具体文本。
长联网解决方案
自实现的一套网络socket管理方案，没什么可说的
总结
总结一下比较有特色的，可以借鉴学习的模块：脚本绑定，事件队列JAction，生命周期管理，内存加密方案。
其他都是一些小功能。
如果想用ILRuntime热更，这个框架集成好了，还集成好了BuddleMaster资源热更，比自己去集成省事，BindClass功能也挺方便。其他功能自己可以根据需求做增删。
不过ILRuntime我感觉还是挺麻烦的，还有各种限制（关于热更使用Mono，使用接口等），坑比xlua还多，没有大佬带着的话还是不自己折腾了，如果要折腾不如去看现在比较火的HybirdCLR。
目前也看了好几个框架了，
QFramwork最精简，只有核心的mvc层级控制，业务逻辑功能全部要自己写。
GameFramework最重，功能很全，但是得按照框架指定的方式写，特别是UI，用起来有点儿不舒服。
公司的框架，c# 与xlua实现的MVC模式。
xlua-framwork，想用纯lua开发的框架，但是呢，lua还是适合写一下ui和简单代码吧，这个框架自定义了类和UIComponent控制，用lua实现了事件系统等，熟悉了也能用，但问题就是不想去熟悉，而且作者貌似不维护了。
JEngine，没有游戏逻辑层框架，都是提供一些工具，话说可以和QFramwork结合使用。
