欢迎访问循迹研究室，这是一个专注于游戏开发的技术站点。我在Github上的开源项目：github.com/hxhb及项目介绍。
博客内的文章，有C++系列，UnrealEngine的热更新、插件和工具开发、资源管理系列，以及循迹研究系列等。
在工作之余研究和开发的技术方案与成果预览：展示柜，如果您对其中某些项目感兴趣可以发邮件到imzlp@foxmail.com。
除本站外，我还创建了一个由社区驱动的虚幻引擎中文知识库站点https://ue5wiki.com/，托管在Github Pages上。欢迎投稿技术内容，为建设虚幻中文技术社区添砖加瓦！投稿规则请看：Wiki内容编写格式与规则。
在游戏开发过程中，热更新是非常重要的能力，它能够让我们在不换包的情况下更新功能、修复BUG。但是哪些东西可以热更，哪些不能热更，哪些存在风险、目前没有很详细地文章进行介绍。
本篇文章我会介绍我在开发HotPatcher及项目热更实践过程中，对热更能力和热更安全的一些思考。确保项目上线时，热更的能力和稳定性是有保障的，并且在热更迭代阶段，也能够清晰地知道哪些是可以热更的，这样也能很好地评估更新风险。
以及通过周边能力建设，提前进行风险排查，把热更新流程变成自动化的，只需要版本PM来控制补丁构建和发布时机，完全不需要程序参与到热更流程。
在我们开发插件时，当插件功能逐渐复杂，通常需要提供一些扩展性的支持，实现自定义的扩展功能来丰富插件的功能，也可以方便用户在不修改程序本体的情况下实现项目的定制需求。
在之前的文章（HotPatcher 的模块化改造和开发规划）中，介绍了HotPatcher与扩展模块的支持与如何基于HotPatcher开发一个新的模块，本篇文章主要介绍在UE内的具体实现方式。
简单地说，就是需要在UE本身的插件系统之上，构建自己的扩展系统。本篇文章会介绍我在提高插件扩展性方面的一些思考了技巧，如何方便地让这些扩展功能与插件本体解耦，方便维护和管理。
在我们开发UE插件时，为了灵活控制，通常会提供大量的配置化参数，用于控制插件具体的执行逻辑和行为。
本文是我UE插件开发系列文章的第八篇，将介绍我在开发插件的过程中，对于插件配置化能力的思考和实现，在项目配置、任务配置、动态参数替换等方面的实践，使插件的配置流程尽可能地足够灵活易用。
在游戏项目中，当我们在打包各个平台时，总希望每个平台的包能够最小化便于分发，而且上架某些平台还有明确的大小要求。
对于UE而言，它包含了巨量代码以及大量的插件，Build阶段还将生成反射的胶水代码，在编译时产生了大量的代码段。以Android平台为例，将导致libUE4.so的大小急剧增长，对于包体和运行时内存都造成了压力。
再加上一些引擎必要和额外带入的资源也能占据上百M，空APK的大小很容易达到数百M的规模！不仅仅为了符合上架平台的要求，从包体和内存优化的角度，也有必要对UE包的大小进行裁剪。
本篇文章会以Android为例，从各个方面介绍UE包中的可裁剪部分的优化思路与实践，同时优化APK大小和Native库的运行时内存占用，其中的策略也可以复用在其他平台。
近期遇到了一个极为诡异的bug，分别有两张地图，其中一张地图A的PAK放在引擎自动挂载路径下可以进入，但是在热更目录不行，另一张地图B则完全相反，在自动挂载目录异常，但是在热更目录正常。
乍一看这个问题完全难以捉摸，两个互斥的行为出现在同一个表现逻辑中。而且热更挂载与自动挂载只是时机不同，优先级不同而已，按理说应该不会出现这个问题。
虽然最终这个问题可以在业务侧逻辑解决，但是这个表现也牵扯到了引擎中另一个极为隐蔽的路径，搞懂为什么以及它的原理是十分必要的。所以，我根据这种表现分析了引擎的代码，并得出了合理的结论，并制定一种检测和规避这种问题的方法。
本篇文章默认读者具有一些UE热更新的基础知识，如有疑问可查阅本博客中热更新系列的其他文章。
对于个人知识管理，我非常热衷于搞一套自己的local-first和开源的self-host的服务，这样就能不依赖任何平台、数据完全自主可控、服务可随时迁移。不管是Obsidian、Hexo博客、以及本篇文章介绍的memos，都是这个选择标准。
本文的主角，memos是一个开源的轻量级笔记的服务，可以像发微博的方式记笔记，支持TAG标记和引用。具有账号系统和权限管理，网页访问随时登录，笔记可以公开或私有，非常灵活。我选择它是因为可以跟Obsidian互为补充，Obsidian还是太重了，在PC上好用但移动端体验不佳。所以我需要一个轻量级、随时可用的一种笔记服务。
本篇文章会介绍，如何在VPS上用Docker部署一个Memos服务，并结合Nginx绑定域名、Certbot签发以及自动更新SSL证书和定时备份memos数据库，还有我为该服务做的一些配置优化。
在之前的文章中，主要在介绍HotPatcher如何应用在热更新流程里。但是HotPatcher并不只是能实现热更的需求，更是一个灵活的资源打包框架。
当项目开发进行到一定阶段，海量的资源需要进包，等待一次完整出包的时间会很久。如果真机出现问题，修复->打包->验证，这个串行流程就会变动极为冗长。经常会遇到脚本、数据或者某些的资源错误，导致包的异常。
这种情况下，再完整出一个包就等待数个小时的时间，导致测试无法进行冒烟跑测。就算重新出包也难保一定没有其他遗漏的问题，否则又要重来一遍。
基于这种痛点，我们迫切地需要一种在开发阶段能够快速地修复包内资源问题，进行快速验证的方法。而HotPatcher提供了这样的功能，如果能充分利用起来，就不必等待完整出包。
本篇文章会介绍，如何利用HotPatcher提供的编辑器功能，来快速打包预设配置和特定资源。加速资源在真机上的验证流程，大幅提升测试效率。
距离HotPatcher的上次版本发布，已经过去了大半年的时间，对UE4的支持较好，但对UE5的支持欠缺，群里也频繁有人询问适配情况。
HotPatcher的上个Release版本是20230604发布的v81.0，只兼容了UE5.1.0，并且不支持WP和Nanite，后续Epic又推出了UE5.2和5.3，但插件并未适配。虽然可以自己修改编译错误，但功能支持在UE5里算是半成品状态。
趁着清明假期爆肝了几天，我对HotPatcher做了全面优化与适配支持，可以兼容UE4.21~UE5的最新版本，并且发布了一个新的Release版本：v82.0。本篇文章的后半部分会介绍HotPatcher在UE5中的适配情况、注意事项、以及更新日志。
另外，在2020年我曾经写过一篇文字：对开源的一些思考与想法，而过去这两年间，我对于维护开源项目的又有些新的想法，一起做个总结。
集成UE到原生Xcode iOS工程
基于字典的Shader压缩方案
Pak的运行时重组热更方案
UE中多阶段的自动化资源检查方案
精确灵活的基础包拆分方案
UE中人体姿态追踪