学习笔记

前言 最近看到腾讯又出了个游戏脚本的热更方案，相对lua有以下的优势。 JavaScript生态有众多的库和工具链，结合专业商业引擎的渲染能力，快速打造游戏 相比游戏领域常用的lua脚本，TypeScript的静态类型检查有助于编写更健壮，可维护性更好的程序 安装 安装PuerTS | PUER Typescript 安装包到Unity，在合适的地方接入JSEnv 自定义加载器 PuerTS自带一个加载器，通过Resource加载JS代码，但是实际开发的时候推荐的是TypeScript，需要转译到JS再执行。 编辑器中推荐使用TS-Loader，编辑器中直接使用TS进行开发，没有其他需要关注的地方。 提供一个PuerTS的Loader，使你在Editor下，可以直接读取TS。 无需研究tsconfig、无需研究ESM、CommonJS，无需自行编译ts，无需理会和调试相关的debugpath/sourceMap/控制台跳转。 https://github.com/zombieyang/puerts-ts-loader 编辑器中直接使用TS开发，在发布时还需要编译成JS，参考ts-loader中的TSReleaser-Resources.cs函数，在发布资源前编译成JS。 编译好的JS要支持热更，所以使用默认的加载器，自己定义一个加载器，传入的参数是JS的路径，返回的是JS的代码内容，结合项目的资源加载返回即可，我的Demo使用了YooAssets框架。 调试 用类似NodeJs的方式调试即可。 VSCode Debug 指引 | PUER Typescript TS学习 TS拥有静态类型检测，能编写更具有健壮性的代码，也有更多现有的资源。 深入理解 TypeScript | 深入理解 TypeScript Handbook - The TypeScript Handbook TypeScript 入门教程 ES6 入门教程 前言 | TypeScript手册

前言 上一篇文章简述了YooAsset资源管理框架运行时的框架的使用，接下来通过代码分析其内部原理。 概览 YooAsset框架的编辑器部分包含了四个部分。 收集：通过过滤规则，资源包名，定位地址，划分打包资源。 构建：根据收集到的资源，同时收集其依赖资源，打包成Bundle包。 Reporter：打包后的资源报告。 Debugger：运行时的资源加载情况。 收集 收集器主要通过过滤规则，资源包名，定位地址来划分资源，具体的用法在使用文档有详细介绍，本系列的第一篇也有介绍。 构建 资源构建也是和运行时的设计相似，按步骤构建，流程如下图所示。 构建管线分为内置管线，可编程管线，原生管线，内置管线和可编程管线的构建步骤基本一致，调用的API有不同。原生管线就是直接复制文件，不构建Bundle。 总结 编辑器的框架就是如此，先收集再按步骤构建，再配套Reporter和Debugger进行排查分析。 本系列教程到此结束，感谢阅读。 参考 https://github.com/tuyoogame/YooAsset

前言 上一篇文章简述了YooAsset资源管理框架的使用，接下来通过代码分析其内部原理。 整体框架 YooAsset框架主要分为运行时和编辑器部分，运行时实现了资源包加载，Bunlde加载，缓存，下载，从上到下的结构。编辑器部分实现了资源收集，资源构建。这篇文章主要分析运行时的机制，结构如下。 加载流程 运行时加载流程主要如下，加载开始以后，每一层的模块基本都是轮询实现。 简单的例子就是调用加载，从上到下，上层等待下层完成自己的步骤，如果完成，再轮询到下个阶段。 每一层根据加载模式和资源类型的不同派生到不同的对象负责轮询，下面的示例是远程加载AssetBundle的示意流程。 根据运行模式初始化包 外部调用加载 调用默认包的加载 Provider轮询，等待Bundle加载完成，再从Bundle中加载具体资源 Loader轮询，等待Bundle加载完成 Downloader轮询，等待下载完成 Requeseter轮询，等待请求完成 资源包（ResourcePackage） 资源包是一个比较上层的概念，在游戏初始化时要初始化包和其加载模式。具体的加载模式可以参照上一篇文章。 定义加载模式 维护版本 维护资源清单 资源管理器（ResourceManager） 资源管理器负责加载具体的资源，根据不同的加载模式和资源类型分成不同的Provider和Loader，并返回对应的Handle。 Provider功能：从加载好的Bundle中加载具体的资源 Loader功能：加载Bundle。 下载系统（DownloadSystem） 下载系统由上层的Loader持有，加载Bundle时，如果还没下载，调用下载系统进行下载。 下载器根据不同的加载模式和资源类型区分，分类普通文件和Web文件，区别在于Web文件不进行缓存。 下载功能由Requester承担，分为普通请求和断点续传。 缓存系统（CacheSystem） 缓存系统是在加载资源时，下载过就不需要再次下载了，直接在本地沙盒目录中读取。 缓存系统由下载系统调用，当下载完成以后，保存本地文件，并记录到缓存系统。 如果已有文件，则进行校验再进行记录。 另一个调用是在资源包初始化后，把已经下载的文件验证一遍，记录到缓存系统中。 后记 运行的框架就是如此，虽然功能很多，但结构清晰，使用了分层处理的思想。 下一篇将介绍编辑器的逻辑，敬请期待。 参考 https://github.com/tuyoogame/YooAsset

前言 这本书忘记从哪里下载了，和别的技术书籍不太一样，大多的内容都比较贴合项目开发，所以有一定的参考价值。 里面有几个章节觉得有收获的，主要是框架的设计，以及一些解决问题的思路，大致做了笔记或者摘录。 一、基础内容交流 代码规范 可读代码：由于动态语言的类型灵活性，可以在变量前加上变量类型简称 正确使用断言与返回 注意什么时候可以为空，不要盲目返回 可拓展接口使用 多参数，下面演示了三种写法，最终应该在保留必要参数的情况下，可选参数做成table addModulePower(nModuleId, nPower); addModulePower(nModuleId,nPower,bSyncMsg,bSendEvent, bOnlyBoss) if( tOption && tOption.bSyncMsg){ //做这个参数该干的事情 } 调试的思维与逻辑 正向和逆向思维，逆向更快 不易复现的bug，埋下日志，下次使用 培养敏锐的异常反应 注意生命周期的创建与销毁 代码修改与重构 我们在项目中秉持一个原则，如果有个接口让你不舒服，比如说多传了几个参数，那么我们一定要提出来，那一定是接口的设计不够简单或者没有提供更简单的接口形式。 优雅的使用外部代码 我们的一个原则就是要尽可能少去直接和引擎进行交互，而是更多的进行局部缓存，把战场拉回到更加通用的逻辑里面。 修改后的代码为： let levelSlider = Core.createBitmapByName("slider_png"); let nSliderX = 0; if(XXX){ nSliderX += 6; } if(XXX){ nSliderX += 8; } if(XXX){ nSliderX -= 2; } levelSlider.x -= nSliderX; 选择简单的接口/参数以及尽量少的使用/调用底层接口就是我们所谓的正确的代码使用方式。 代码审查 取出一个管理器对象。然后直接访问了它的成员函数，这是非常不应该行为。第一个是这个成员不应该是公有的，而应该是私有的，它的公有性质破坏了类的封装。 从面试的角度看面试 基础能力，逻辑能力，硬核能力 如何应对代码错误 作为项目的主程，还需要统一思想。这个过程包括要求大家遵循统一的代码命名等，这也是规避错误的一个重要手段。越是相似的代码风格，代码的阅读速度就会越快。 二、逻辑设计模式式讨论 分层设计 事件的派发遵循从下往上：比如M驱动V 依赖性越强的越靠下层 变化的放上层，底层可以互相依赖，逻辑层不允许相互依赖 主动和被动 被动模式，依赖事件，及时，性能消耗少，当被动模式不在能支持复杂逻辑时，可以考虑主动模式 主动模式，依赖轮询，有点像ESC的系统层监听实体层的感觉了。优点在于可以监听多种条件 阻塞和非阻塞 主要用于资源加载，阻塞速度快 统一与非统一 效率没有打到一定程度的影响时，推荐考虑统一性 三、框架设计初步 基类 存活状态，唯一ID 框架代码结构 子类关注的基类接口一定是个空的实现，意味着子类不需要考虑去调用父类同名的接口。 框架设计 配置化编程：消除重复代码，如协议监听，按钮监听等等 自动化平衡处理：如果没有销毁，帮忙擦下屁股 机制有助于实现全局性的功能，尤其处理大规模需要重复代码的东西 框架拓展的思路 基础能力，封装类，继承到框架中 四、逻辑设计原理 缓存的设计 缓存存放的东西有限，不能所有的东西都放缓存。 缓存应该具备清理功能。 缓存系统应该具备一定的匹配能力。 缓存具备最小保留数量以及预先创建的能力 分线漫谈 分线，是将玩家划分到不同的频道中，不同频道的玩家互不可见，且不会互相同步消息。分线在程序方面主要用于减少网络包，在策划层面会有一些其他的应用。分线是基于场景的，我们的可见性，以及消息同步默认以场景为单位。 ...