纪录在学习GameFramework过程中的疑问以及思考过程
初见代码
首先拿到源代码的时候,我们可以看下整个工程文件的目录结构。
整个框架系统都是由GameEntry启动,现在我们就要进入里面去寻宝。GameEntry由两个类组成
他们分别有各自的职责,GameEntry.Builtin类是负责加载系统组件的配置,GameEntry.Custom是负责加载用户自定义组件的配置。我们回到主程序可以看到真面目,系统初次启动的时候会获取组件配置。
那么他是如何找到的呢,进入源码里面就可以看到,他是获取GameFrameworkComponent类型的组件,没猜错的话,GameFramework的系统组件也是此类型。
果然没错。GameEntry.Custom加载用户自己的配置也是如此。
GameFrameworkEntry拥有超能力的药水
当我在想着游戏组件是如何运作的时候,我注意到一个有趣的问题┗( ▔, ▔ )┛,我战战兢兢的点开FsmComponent的代码,看到了一个IFsmManager接口,
难道状态机面板的所有功能都是由这个接口完成的┗( ▔, ▔ )┛喵喵喵???随着我们继续深入我们就能看到一个很神奇的东西,是这个东西让IFsmManager接口有了超能力,他在Awake里面已经被运行了。
我们找到GetModule方法,里面其实是根据传入的接口,实例化了一个对应Manager,然后接口调用的所有功能其实都是对应Manager里面的功能。可以周到FsmManager,看到之前IFsmManager调用的方法CreateFsm实现,这样就实现了接口和管理器的一一对应,作者这样写是有原因的,依我看来,使用接口来实现功能,对调用者来说可以不用关注底层实现的细节,也不可以对功能进行修改,方便调用者使用。
下面我们将通过一个例子来看GameFrameworkEntry的实现过程,我们模拟一个简易的Fsm创造过程,记得创建自己的命名空间,创建一个Test脚本,代码如下:
namespace SGF
{
public interface IFsmManager
{
void Start();
void End();
}
internal sealed class FsmManager : GameFrameworkModule, IFsmManager
{
public void End()
{
}
public void Start()
{
Debug.Log("你好!");
}
internal override void Shutdown()
{
}
internal override void Update(float elapseSeconds, float realElapseSeconds)
{
}
}
}
如何使用呢,看下面代码:
public class Test : MonoBehaviour
{
IFsmManager test;
// Start is called before the first frame update
void Start()
{
test = GameFrameworkEntry.GetModule<IFsmManager>();
test.Start();
}
// Update is called once per frame
void Update()
{
}
}
知识小贴士,请自助食用
Internal关键字 其他程序集无法访问本程序集
内部访问的一个常见用途是基于组件的开发,因为它使一组组件能够以私有方式进行协作,而不会暴露给其他应用程序代码。例如,用于构建图形用户界面的框架可以通过使用具有内部访问权限的成员来提供Control和Form合作的类。由于这些成员是内部成员,因此它们不会暴露给使用该框架的代码。
引用具有内部访问权限的类型或成员在组件定义之外是错误的。
[ThreadStatic]程序集
static标记为ThreadStaticAttribute的字段不在线程之间共享。每个执行线程都有一个单独的字段实例,并独立设置和获取该字段的值。如果在另一个线程上访问该字段,则它将包含不同的值。
Sealed 密封类
当对一个类应用 sealed 修饰符时,此修饰符会阻止其他类从该类继承。在下面的示例中,类 B 从类 A 继承,但是任何类都不能从类 B 继承。
1 class A {}
2 sealed class B : A {}