1.使用 Gitea + Git Hook 实现 Hexo 博客源码托管与持续集成
2.一文看懂ECS架构
3.一次NPM前端项目的码分CI-Build速度优化
4.UE4.26(5.0)后的Sequence系统
5.2分钟自动化部署2048小游戏到ECS

使用 Gitea + Git Hook 实现 Hexo 博客源码托管与持续集成

       本文将介绍如何在2核4G的阿里云ECS上，利用Gitea和Git Hook来搭建Hexo博客的码分源码托管与持续集成。Gitea作为轻量级的码分开源Git服务，替代了性能占用较大的码分GitLab，以降低服务器负担。码分

       在开始之前，码分android httpserve 源码确保你具备以下基础:

       熟悉此前文章中的码分相关知识

       1. 安装与配置

       1.1 安装前置依赖

       1.2 创建工作用户

       1.3 下载并设置Gitea权限

       1.4 初始化Gitea服务

       1.5 配置Nginx反向代理

       1.6 为数据安全添加Nginx登录验证

       1.7 导入本地仓库

       2. 安装Node.js与Hexo

       2.1 安装Node.js和创建软链接

       2.2 安装Hexo并创建可执行脚本

       3. 创建Hexo仓库与Git Hook

       3.1 创建仓库并配置忽略文件

       3.2 配置Git Hook脚本

       总结

       通过这些步骤，你实现了Hexo博客源码的码分自动管理和远程部署，本地专注于创作，码分线上自动构建。码分在实践过程中，码分记得根据服务器安全策略限制对端口的码分访问，以确保整体安全。码分

一文看懂ECS架构

       在游戏开发中，码分ECS架构是码分一种解决实际问题的高效方式。其核心思想是通过组合和数据打包优化性能，而非传统的继承结构。以下是ECS架构的三个关键部分的概述。

       实体（Entity）：每个实体仅包含一个唯一的ID，代表其身份。

       组件（Component）：组件是相关功能数据的集合，如Transform组件包含位置和旋转信息。每个组件类型对应一个独一无二的ID，用于跟踪和匹配。随机语录源码

       签名（Signature）：通过std::bitset表示实体拥有的组件集合，每个组件类型在位图中对应一个位置。系统通过比较其关心的组件签名和实体签名，确保所需组件的匹配。

       实体管理器（EntityManager）：负责ID的分配与回收，使用队列管理可用ID，保证高效创建和销毁操作。

       组件数组（Component Array）：存储同类型组件的数据，通过映射保持数据紧凑，避免无效数据影响性能。当实体被销毁，数据需重新组织以保持数组连续性。

       系统（System）：关注特定组件签名的实体列表，通过std::set保持高效查找，处理相关组件的逻辑。

       系统管理器（System Manager）：维护已注册系统及其签名，确保与Component Manager和EntityManager的协调。

       协调器（Coordinator）：整合所有Manager，提供跨Manager操作的接口，简化代码结构。

       通过一个实例，比如,立方体受重力影响的场景，ECS架构展示出其在性能上的mip网址源码优势。但也要注意，ECS不适用于所有场景，通常在对性能要求高的部分，如物理模拟，采用ECS。

       学习ECS架构的深入资料可以参考Austin Morlan的"A Simple Entity Component System (ECS) [C++]"，源代码和详细解释可在相关链接中获取。

一次NPM前端项目的CI-Build速度优化

       基础设施部分，项目部署在中国的亚马逊云，使用了 AWS 的容器服务（ECS）、容器注册表（ECR）、对象存储（S3）与弹性计算（EC2）。源码管理采用 Atlassian 的 Bitbucket，一个基于 Git 的代码仓库。CI/CD 通过 Jenkins 实现，使用插件 pipline 进行维护。项目使用 Node.js 语言进行开发，代号为 salmon。项目打包与发布采用 NPM 和 Docker。

       流程分为标准发布流程。在收到同事 A 和 B 的反馈后，对 CI/CD 过程进行了深入分析。主要分为三个关键步骤：编译代码（stage{ 'Build'}）、博客建站源码推送到仓库（stage{ 'Publish'}）和运行服务（stage{ 'Deploy'}）。在分析“编译”步骤时，发现 npm run build 占用了最多时间，约为 9 分钟。进一步分析发现，容器化 CI 流程的基础设施为纯净、无状态的环境，这与传统基础设施存在差异，可能是速度差异的关键。

       为复现非容器化构建流程，使用 EC2（2 核 8GB）进行测试。结果显示，已 build 过的项目目录进行后续 build 耗时显著减少，原因可能是生成了编译缓存文件。对比发现，删除 .next 目录后，项目容量减少 MB，定位到编译后的 node_modules/ 目录下存在 .cache 文件夹，经过多次调试验证，build 前后差异 MB 文件的确位于 .cache 目录中。将 .cache 内容应用到已执行 npm install 未 build 的目录，构建速度得到提升。

       为优化缓存，源码后门代码考虑维护线上缓存池，使用 AWS S3 服务进行目录同步。在 EC2 测试机上运行结果良好。对 Dockerfile 进行改造，添加了 AWS CLI 工具以操作 S3。验证优化效果后，Jenkins blue-ocean 统计显示，提速效果明显。实施线上缓存池后，对其他项目进行了评估，发现无法广泛应用此优化策略。虽然工具相对简单，但在优化过程中取得的工程逻辑与解决问题的方法论，对项目和读者都具有启发意义。

UE4.(5.0)后的Sequence系统

       在虚幻引擎4.版本后，Sequence系统的计算方式进行了调整，具体详情可参考《大规模内容的性能保障：虚幻引擎4.中的Sequencer》一文。阅读后，您能大致理解ECS（Entity Component System）在源码层面的实现方式。本文使用的原生引擎版本为5.0.3，相较于4.版本，UE5中接入了更多Section，系统得到了补充，但本文不介绍具体系统功能。

       要了解ECS的入口点，可以创建LevelSequence资产，添加任意Actor及轨道，然后在求值或ImportEntityImpl函数中设置断点，观察堆栈内容。在MovieSceneEntitySystemRunner中，可以看到UE实现的入口点注释。对照官方介绍，Sequence的四个更新阶段均在GameThread_...Phase形式的类中记载，这些类包含代码Linker->SystemGraph.ExecutePhase(ESystemPhase, Linker, AllTasks)，这是各系统执行的入口。

       为了详细介绍流程，需要了解类的持有关系和简单功能。主要围绕以下结构展开：Linker及其初始化过程、Linker相关的类型关系、Entity的引入、System图构造及使用、System执行以及实际执行。

       在初始化阶段，首先打开LevelSequence资产，FSequencer作为默认编辑器，调用InitSequencer方法进行初始化，创建全局UMovieSceneCompiledDataManager并持有RootEvaluationTemplateSequence。这个类在ECS过程中主要用于将整个Sequence划分为多个求值区间。RootEvaluationTemplateSequence用于整体调度工作成员，并为外部提供数据访问接口。初始化过程中，创建Linker与Runner，并将其互相绑定。Linker的位置可以根据IMovieScenePlayer的指定或直接在临时包下创建。Linker的全局变量GComponentRegistry持有FComponentRegistry类型，EntityManager提供其指针。新的FInstanceRegistry被创建，并记录RootSequence信息。Sequence实例化参数可用于获取全部Sequence信息，委托指示此Sequence绑定丢失时标记Guid。在Invalidate函数内，由CompiledDataManager进行区间划分并掌握轨道与段落信息，为SequenceUpdater赋值。

       初始化完成后，后续将在FSequencer::Tick或UMovieScenePlayer::Play中执行。此时Runner将调用Linker各个阶段的系统执行。从Runner::GameThread_SpawnPhase开始介绍Linker相关的类型结构。

       Linker主要执行了链接系统与执行系统的工作。在GameThread_SpawnPhase阶段，通过全局变量GlobalDependencyGraph获取保存的Class ID，这些ID是在Init阶段通过UMovieSceneEntitySystem构造函数保存的。GlobalDependencyGraph在系统初始化时保存了所有系统的依赖关系，随后Linker->LinkRelevantSystems遍历整个GlobalDependencyGraphClass数组，如果系统通过relevant判断则执行Linker->LinkSystem。在此过程中，系统被分配至执行数组并安排好执行顺序，通过DFS检测依赖关系是否构成环。

       在执行System阶段，通过FMovieSceneEntitySystemGraph::ExecutePhase，系统按照顺序装入列表并依次调用其OnRun方法执行每个System。System执行的流程涉及Component类型匹配、执行逻辑得出结果并写入目标位置。具体实现细节包括Builder构建任务、匹配Entity、执行操作等。System类型多样，本文仅介绍System与Entity的交互，而非特定功能实现。

       系统实际执行时，组件与系统交互关系复杂，特别是对于具体轨道如平移Actor等操作。理解这部分需要详细了解组件和系统之间的交互。

       本文仅浮于表面，深入理解需要参考官方文档。写此文的目的是记录对虚幻引擎Sequencer系统学习的感悟。如果有空，可能会继续挖掘更多相关内容。

2分钟自动化部署小游戏到ECS

       上传源码：首先，登录云效代码管理Codeup，进入代码库页面添加库，选择URL导入代码库，输入源代码库地址，等待导入成功。

       创建自动部署流水线：随后，前往云效流水线Flow，在我的流水线页面创建流水线，选择新建流水线，利用小游戏部署模板，完成创建。

       配置流水线的代码源：上传代码至云效Codeup后，选择代码仓库spring-boot-，确认默认分支为master，点击下一步。在流程配置页面，单击主机部署。选择默认构建的制品，新建主机组，然后选择免费体验主机。

       创建ECS主机：前往阿里云体验实验室，按照指引创建免费的ECS主机，复制AK ID等信息，填入编辑面板并保存。成功导入主机后，确认默认的部署脚本和部署策略无需改动，保存并运行。

       触发流水线运行：在编辑面板中输入ECS_IP地址，点击运行。经过1-2分钟，流水线自动完成构建和部署。部署成功后，点击访问站点或扫描二维码，即可查看到小游戏。